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
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.
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.
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.
SIP Digest Leak from Sandro Gauci on Vimeo.
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.