TADSummit is a great event where people from different backgrounds that are somehow involved in communications, contribute in various ways. I, personally, always look forward to see what’s coming up in the next TADSummit event. At the moment, TADSummit Asia presentations are currently being released on a daily basis on the main site. And last week, the presentation that I prepared was published!
In the previous TADSummit, I had presented about why we need to bring an offensive approach to RTC security. In this one, I introduce our contributions to the space, i.e. SIPVicious OSS, SIPVicious PRO and the demo server.
Without further ado, here’s the video presentation:
The slides can be found here:
If you prefer to read instead of watching a video presentation, I’m providing my transcript.
Introduction
Welcome to my talk about tools for offensive RTC security, where I’ll be introducing SIPVicious PRO and the demo sever that we’ve been working on!
Before I get started, let me introduce myself. I’m Sandro Gauci, leading Enable Security. To this industry I’m mostly known for having developed the open source version of SIPVicious. These days, I lead Enable Security where we do things related to offensive RTC security such as research, penetration testing, consultancy and training. As part of that, we also develop the professional offensive security toolset for RTC, SIPVicious PRO!
There’s a number of ways how we contribute to open-source RTC security but I’m going to mention a recent event called OpenSIPIt. This was an event that happened recently where a number of SIP-based software project developers joined up to do Interoperability testing, focusing on new RFCs such as those which define the STIR/SHAKEN standards that to try to block caller-ID spoofing. From our part, we were there doing security testing of these new features and helping out with validation of the tests.
Previous TADSummit presentation
This is not my first talk at TAD Summit. In the previous one for TAD Summit EMEA and Americas, I had a talk about why I think that taking a purely defensive stance to security is not enough. I spoke about why we need to look at offensive security with regards to RTC security and came to the conclusion that this is often not done because of two reasons: 1. the lack of training opportunities in offensive RTC security 2. the lack of robust and available security testing tools
In this presentation, I’m not going to complain about the state of things. Instead, I’ll take a look at the tools and training opportunities available to you all, with demos sprinkled throughout my talk.
The offensive security testing tool landscape with regards to RTC
First let us take a quick peek at the landscape covering security testing tools.
We have compiled a list of such tools on a Github repository called awesome RTC hacking.
If I open the open-source tools section, we can see a number of such tools being available. Unfortunately many of them are no longer maintained, while others have not been receiving updates. This was also the case with SIPVicious OSS until a year or two ago. But I think now it is actually better maintained because we are putting some effort into that.
SIPVicious OSS
I’ll be talking first about SIPVicious OSS. I published this way back in 2007 since I wasn’t very happy with what was available out there at the time. It is based on python and consists of 3 main testing tools which I’ll show now. demo time
The first tool is called svmap which allows you to discover potential targets that speak SIP. It does this by pinging, sending an OPTIONS request and if anything responds, is shows that in the results. I’m showing this being run against the demo server first and we can see that the server is running Kamailio.
The svmap tool takes a number of parameters of course and is quite flexible. For example, we can specify the SIP extension to ping. In this case, we are specifying extension 1000.
And we can see that when we specified a valid SIP extension on the demo server, the server or user-agent header indicated that it is an Asterisk server instead of Kamailio.
The next tool in the SIPVicious OSS toolset is called svwar which enumerates SIP extensions. We’re running this against the demo server again, and we’re giving it a range of potential SIP extensions to scan for between 1000 and 2000.
Finally, the last tool in the toolset is called svcrack, which allows us to do a password cracking attack on known SIP extensions. Here we’re cracking the password for extension 1000, that we identified during enumeration, by trying numeric passwords between 1300 and 1600.
This is all well and good for basic tests but since 2007 things have changed. Personally, I have rewritten these tools in various languages simply because it couldn’t do certain things and had various limitations. So, long story short, we now have SIPVicious PRO.
SIPVicious PRO is quite different from SIPVicious OSS
SIPVicious PRO shares the same name as the open-source version but it is really completely new code with much more ambitious goals. We wrote this in Go but what matters is that we are now covering the entire RTC space not just SIP. Our goals this time are much ambitious because we’re aiming to create the most powerful offensive RTC security toolset.
SIPVicious PRO features and attack tools
So let’s show SIPVicious PRO a little bit. demo time
I will start with the SIP extension enumeration tool in SIPVicious PRO. We’re doing the same test as we did before with SIPVicious OSS, but this time we’ll test against SIP TLS on the demo server. We’re trying to guess SIP extensions between 1000 and 2000.
Next, we can use the SIP cracking tool against SIP extension 1000, giving it a range of potential passwords between 1300 and 1600 to guess from. This is similar to what we did with the open-source version of SIPVicious but this time using SIPVicious PRO and SIP TLS.
So in terms of features, we have a lot more tools in SIPVicious PRO. We support a number of denial of service tests. Some unique attacks such as RTP Bleed and Digest leak as well as fuzzing, which is a whole world on its own. And we support various different protocols for SIP, not only UDP but also TCP, TLS and secure WebSockets.
SIPVicious PRO used in a CI/CD pipeline
Something that is really cool is that we also support automation so that SIPVicious PRO can be used inside automated testing systems like CI/CD pipelines or GitHub actions.
Let me show you what I mean. The easiest way to do this is by using exit codes. Different exit codes mean different things. In this case, we’re interested in exit code 40 which means a security issue was detected. Let’s do a quick demo for this. demo time
So this time we’re running the digest leak exploit tool in SIPVicious PRO and we will get the exit code right after we run this test.
We can see that the attack actually worked and that the exit code is 40, security issue detected. This can be easily incorporated in any testing automation system and it’s actually really a simple yet powerful feature. We think this is ideal for when you want to automate some security tests whenever you make some changes to your RTC software.
SIPVicious PRO templating system
SIPVicious PRO also supports an extensive templating system. Let’s show a very simple example for this. demo time
So first I’m going to use the repeater tool to send a SIP OPTIONS message to the demo server to show a normal SIP message sent by SIPVicious PRO.
If we scroll up a bit, we can see the SIP message has no user-agent string. Let’s say we want to add that to the SIP message. If we don’t want to start from scratch, we can reuse the default templates within the toolset.
For that, I’m running the templates dump command which creates a new directory called svtemplates and puts all the templates in there.
Next I’m going to edit that file and add my user-agent header. I’ll add friendly scanner for old-time’s sake :)
And then, I’m going to use the repeater tool again, this time specifying the templates directory so that we can send the OPTIONS message with the user-agent header. And if we scroll up we can see that the user-agent header is there now. Of course the templating system is much more extensive and you can do much more, so this was a very basic test.
SIPVicious PRO features
So what else do we support? There’s RTP of course, and the tools are extremely fast. This is important for certain denial of service tests which require speed but also require us to be able to handle the relatively complex logic that comes with SIP and similar protocols. Finally, we comply to the RFCs unless the attack requires us not to do so.
The demo server, a training ground for RTC security attacks
This brings us to the demo server which is great for learning RTC offensive security by trying.
It is quite hard to find something that is vulnerable to all the security issues that we can test for in SIPVicious PRO. Therefore, we created what we call the demo server because we needed a way to reliably show the vulnerabilities that SIPVicious PRO could abuse.
This diagram is my attempt to explain how the demo server works. Excuse my skills! So we have a docker-compose file and of course various docker images. We have Kamailio and RTPEngine on the front, and behind that, an Asterisk server. Kamailio terminates SIP on UDP, TCP, TLS and WebSocket. There’s also an extra Asterisk server which we call the call generator. It generates a number of concurrent calls so that there’s RTP traffic that can be attacked. There is also a coturn image for the WebRTC part and Nginx to show the voicemail and also serve some pages.
So this machine is vulnerable to all the security issues that SIPVicious PRO can test for … and actually more because we did not yet add tests in SIPVicious PRO for the TURN proxy abuse vulnerability but this can be tested on the demo server currently.
In terms of protocols, we support SIP over TCP, TLS, UDP, WebSocket and Secure WebSocket thanks to Kamailio, as well as RTP and SRTP with SDES and DTLS thank to RTPEngine. And there’s a WebRTC interface that I can show right now.
This location is a bit hidden right now but it’s pretty cool. demo time
So, the menu might look familiar to some. I’m not going to start any war for now. Instead I’m just going to start the developer tools and perform a call just to show what’s happening here. We have some register messages as you can see and if I try to call 1200, you’ll see the INVITE messages being sent over WebSocket. This is great if you want to test any SIP and WebRTC related attacks.
This is ideal for when you want to test your skills at attacking a WebRTC system that relies on SIP as a signaling protocol but there are of course, all the other protocols being handled here such as TURN, SRTP, DTLS and so on and so forth.
Our future plans
In terms of future plans, we got plenty! We want to cover more and more protocols especially XMPP, STUN and TURN. These are natural starting points because we have already developed tools for so we have easily integrate that into SIPVicious PRO. And also, we’re especially interested in adding support for testing custom signaling protocols because of WebRTC of course. For SIPVicious OSS, we plan on keeping on supporting it because its a very reliable toolset for many people. In fact, we’re adding some useful new features right now to SIPVicious OSS. And finally, I think it makes total sense to open-source the demo server project. We didn’t do that yet because there’s a lot of cleaning up to be done but it seems to be useful to other people who want to learn about offensive RTC security. So do feel free to put some pressure on us to speed that up!
Thanks!
I’d like to thank Alfred Farrugia for his assistance with this presentation and developing SIPVicious PRO and the very cool web interface for calling over WebRTC. Pinaki for this work on SIPVicious OSS. And Alan Quayle for the invitation to present again at TAD Summit.
Keeping up to date
If you’d like to see what we’re up to, do check out our blog called Communication Breakdown, at rtcsec.com. That’s where we publish our stuff if you want to keep tabs on our latest publications. Or get in touch by email and our website of course. Thank you!
