Tuesday, May 23, 2017

Fuzzing PJSIP and chan_skinny, vulnerability information and advisories

In the recent past, Alfred Farrugia and myself started looking at fuzzing OpenSource VoIP projects such as Asterisk, FreeSWITCH and Kamailio and their dependencies. Our internal Enable Security project was given the unimaginative name of rtcfuzz and, by now, we are making use of a combination of public tools like American Fuzzy Lop and Radamsa, together with our internal tools ...And is, of course, giving us some good results.



We reported three issues to Digium, two of which actually affect PJSIP and one of which affect chan_skinny. We're happy to say that they have now been fixed, at least in the latest versions of Asterisk.

The vulnerabilities affecting PJSIP will affect Asterisk users who use chan_pjsip instead of the legacy chan_sip. They will also affect those who use PJSIP in other products of course. These security issues appear to be major vulnerabilities and at least one of them looks very exploitable (i.e. leading to remote code execution). In both cases, they will definitely lead to a crash, i.e. Denial of Service. For the technical details, check out the advisories that we just released:
The security issue affecting chan_skinny is a memory exhaustion issue and can be abused to crash the Asterisk process. My personal view is that anyone using chan_skinny, with a vague understanding of security, should stop doing that and take a look at the code. Our advisory with the technical details on this was released too:

That's it for now!

Tuesday, May 24, 2016

New Mascot and Tshirts!! and .. Kamailio World 2016 - 9 Years Of Friendly Scanning And Vicious SIP

On the presentation

Last week I had the pleasure of presenting something new at Kamailio World 2016. Great community and excellent feedback!

The presentation went through the following:
  • How and why SIPVicious was originally written and published
  • Those strange emails and phone calls asking for special version ;-)
  • RIPE's 1.1.1.0/24 experiment and how it was interesting in terms of SIP security
  • Sality pushing modified versions of SIPVicious
  • Attackers making use of insecure Tandberg systems to install SIPVicious
  • SVCrash - why it was published and how it worked
  • Security updates from the VoIP and PBX industry
  • Rewriting SIPVicious (various fails)
  • What happened since then and what I've been using during VoIP pentests that involve SIP
  • 2016, yet another rewrite on the way
  • New features in this latest rewrite attempt and how they show some important security issues

Some parts were sped up due to the limited time that I had for my presentation, but I think the main points were delivered. If you missed the conference, you can watch the video on Youtube.


T-shirts, mugs, hoodies and fluffy pillows

Oh and about those t-shirts - just published the new SIPVicious mascot design, gave away some swag and they ran out within minutes. So I decided to make it available to anyone who needs to have the friendly-scanner punk all to him or herself! Check out the Spreadshirt shop here.

Note to Finanzamt and any related entities:
I have removed any commission so that I get no financial profit out of this. Zero. Nil. 





Friday, May 13, 2016

Time flies! A summary of updates for the past few years and Kamailio World!

I just realised that I have not updated this blog since ages even if we have done some really cool stuff with SIP during that time. Unfortunately, many of the specifics are (to a certain extent) behind non-disclosure agreements.



However, here is a list of stuff that happened that has to do with SIPVicious (or not):

  • There was a release back in 20121210, v0.2.8
  • Like everyone else, we moved to Github
  • There were a number of bug fixes that one can get by using the repository version (see the commits)
  • And .. no rewrite has been published yet! but a new one is being worked on and it should prove pretty useful (once available).
  • A number of new VoIP security tools have been made public, including:
    • Bluebox-ng (unmaintained)
    • Viproy (VoIP Penetration Testing and Exploitation Kit)
    • vsaudit (VOIP Security Audit Framework)
In other news, I'll be presenting at Kamailio World 2016 in Berlin, with the title: A look back at 9 years of friendly scanning and Vicious SIP

Monday, December 10, 2012

If SIPVicious gives you a ring...


Note: SIPVicious version 0.28 is out, go get it.

I like to keep an eye on the social media and Google alerts for SIPVicious and in the last few months I noticed a rise in mentions of the tools. Specifically, a number of Korean twitter users (who have their service with KT, a VoIP service provider) complaining about receiving a call from a caller-id showing ‘SIPVicious’.

After contacting a Korean friend, this led to an interview by a reporter for an article that was published on a Korean tech news site Boan News. The good news is that, according to the reporter, KT decided to release security update Nov. 7th for the vulnerable ip phones following the article. 

Since most of this blog’s audience is not Korean-speaking, I thought I’d publish the answers I gave to the reporter.

Questions and Answers

  1. Reporter: Did (sic: does) anybody try to commit a crime using your tool? How do they do?

    Me: Normally (i.e. by default) SIPVicious does not call any phones and does all the security tests silently. Since the tools have been abused by cyber-criminals, the PBX software vendors have updated their software to disallow such scans. What seems to have happened in this case is that someone discovered that if you configure SIPVicious to scan by sending a "call" command (an INVITE scan), then you can still attack some PBX software. Therefore this bypasses the protection implemented by the PBX software vendors. Someone (not me!) even made videos showing this off on Facebook.

    The reason why they would target PBX systems is to find phone lines on that PBX system which have a weak password. Then they would make "free" phonecalls through it to international numbers or premium numbers at the expense of the victim. Therefore that would make them money.

    In this case, however, things are a bit different. While launching an INVITE scan on a vulnerable PBX system can be useful for the hacker, doing the same thing on an IP Phone (or VoIP Phone) just makes it ring. While some phones will only ring when the correct number is called, others ring when any number (or rather, any SIP address) is specified in the INVITE message. So the attackers/hackers/cyber-criminals ended up getting phones to ring. I think this is a mistake that they were making, possibly because they are not differentiating between a phone and a PBX system.
  2. Reporter: Is it a kind of call fraud? I mean, should the person who receive the call pay the money? Is that what they want?

    Me: No I think the person receiving the call does not pay any money in this case as long as it is their IP Phone which is ringing.
  3. Reporter: How should we protect ourselves from it?

    Me: The service provider (i.e. the ISP or VoIP company) could probably prevent the attackers from reaching the phones. The phone vendor could also make the phone ring only when the correct number is called.

One Canadian person posted a picture of her phone showing this:


I wanted to expand a bit on possible mitigation for this. Security precautions that could be taken by different persons or organizations:

  • End users: put their VoIP devices behind a firewall (not necessarily NAT) and only allow it to be contacted by the provider.
  • Vendors (who control firmware): could configure the phones to only ring when the right number is called. Sometimes this has to be done through a firmware upgrade while sometimes this is a configurable option.
  • ITSP/VoIP provider: could configure the network to only allow SIP destined to the VoIP devices from their own gateways. Unfortunately this might prevent end users from making use of third-party SIP providers if not properly configured, so it may cause undesired side-effects in some cases. The VoIP devices might also be configurable to either disallow the phones from ringing on any number, or to only allow SIP messages from the provider itself (through firewall or matching of the SIP registrar IP address).
I also had other friends who reported receiving calls from SIPVicious when they had configured their Asterisk box to route all (unauthenticated) calls to their mobiles. This is probably the same sort of attack. This could lead to extra phone bill charges and the Asterisk installation should probably be configured to only allow authenticated / trusted calls to be routed through.

A reminder of the SIP digest leakage 

This attack is also known as "SIP digest authentication relay attack". Keep in mind that this same behavior (peer to peer calling) can often be abused to leak out the digest authentication response. With VOIPPACK I provide a tool that reproduces this security issue in a number of VoIP phones and ATA devices.

And a SIPVicious update

SIPVicious has supported the OPTIONS method for enumeration for while, which is often similar to sending an INVITE but without getting any phones to ring. This method can often be used to bypass Asterisk's protection against enumeration. I have now updated SIPVicious to officially support INVITE enumeration more gracefully (i.e. sending ACK to responses and BYE). And of course, I fixed yet a few more bugs.

Wednesday, February 22, 2012

SIPVicious 0.2.7 released and rewrite coming up, looking for testers!

Get it now! This is the last release in the 0.2 series which fixes a number of stability issues and bugs before moving on to a total rewrite.

Are you a SIPVicious user? Get in contact if you have a VoIP lab or simply want to test the rewrite of SIPVicious. The internal version already includes support for TCP, TLS and IPv6 ;-)

The changelog for this one:
  • Feature: svcrash.py has a new option -b which bruteforces the attacker's port 
  • Feature: svcrack.py now tries the extension as password by default, automatically 
  • Feature: svcrack.py and svwar.py now support setting of source port 
  • Feature: new parameter --domain can be passed to all tools which specifies a custom domain in the SIP uri instead of the destination IP 
  • Feature: new --debug switch which shows the messages recieved 
  • Bug fix: Sometimes nonces could not be extracted due to an incorrect regex 
  • Bug fix: Fixed an unhandled exception when decoding tags 
  • Bug fix: now using hashlib when available instead of md5 
  • Bug fix: removed the space after the SIP address in the From header which led to newer version of Asterisk to ignore the SIP messages 
  • Bug fix: dictionaries with new lines made svcrack.py stop without this fix 
  • Change: renamed everything to start with sv 
  • Bug fix: changed the way shelved files are opened by the fingerprinting module 
  • Change: fingerprinting disabled by default since it was giving too many problems and very little benefits
Download SIPVicious from http://code.google.com/p/sipvicious/

Monday, January 2, 2012

Asterisk forensics: the logs vs the attackers

Recently I had the opportunity to present on VoIP insecurity around various conferences this year, on my own and also with Joffrey Czarny. 

At Secure 2011 we had one day a workshop and one of the things we showed was the effect of a typical SIPVicious attack on an Asterisk box. The following videos (best seen in full screen and high quality) illustrate what happens.

1. When we run svmap.py, nothing usually shows up on the asterisk logs. 



2. Running svwar.py floods the logs with attempts for registrations for various extensions.



3. Running svcrack.py on a valid extension shows a large number of "Wrong password" errors. 



Enumeration and password cracking are not the only attacks being performed on target PBX systems on the Internet. Honeypots and victims are able to pick up a number of INVITE scans looking  for "open sip relays". This is a vulnerability that may affect SIP gateways without proper access control or badly configured dialplans that allow calls to pass through without authentication. 

The following video shows how this looks when done using X-lite (which is what some of the attackers are using) on an Asterisk box. You can see the log entries filling up. 




Hope someone finds this useful when looking at log files or studying attacks on SIP. Feedback is welcome as always

Tuesday, January 25, 2011

VOIPPACK updated to v1.4

Quick note, VOIPPACK now includes support for Cisco Call Manager and more tools to break that Asterisk PBX (FreePBX / Trixbox focus). The blog post on EnableSecurity includes more details.