SIPVicious tools roadmap

I'm looking at improving SIPVicious and would appreciate your input for new features or any possible bug fixes. Send me an email with ideas, or simply leave a comment.

Check my current "to do" list here.

Password policies for PBX servers

Password policies form an important part of computer security. Unfortunately a large number of VoIP PBX servers do not apply any policies when it comes to authentication. Because of the lack of such security mechanisms, bruteforce attacks are a viable way to attack PBX servers. Svcrack, which is part of the SIPVicious tool suite, demonstrates this.

Of course, vendors and developers should be cautious when implementing features that can cause a denial of service. For example, the Account Lockout policy (available in Microsoft's AD and other systems) allows anyone to deny service to another user. This is not such a good idea especially in the case of something as "real time" as the phone service.

On the other hand, trotting or slowing down authentication might be a solution to limit the chance of attackers guessing the password in a reasonable time. Password complexity should also be enforced to hinder brute-force and dictionary attacks.

introduction to svcrack

The purpose of svcrack is very straightforward.This tool will launch a password guessing attack extensions on the SIP registrar. Attackers will be after your SIP passwords because such knowledge allows them to:

• Get free long distance calls
• Hijack and spoof phone calls
• Eat your spaghetti
  

The most obvious and damaging problem is toll fraud. Traditionally phone phreaks enjoyed free calls by abusing security flaws within the phone company's system as well as private companies' PABXs. By gaining access to an extension line which can make international calls, an attacker will be able to run large bills on the victim's account. On the other hand, the social engineering aspect should not be under estimated. Social engineering can be a very effective and reliable method that allows hackers to pull off some of the most interesting (sometimes amusing) attacks ever. From ordering free pizza as someone else, to hijacking the help desk's number and then asking for user's passwords, such attacks rely on human nature and can probably never be totally prevented.

This is how svcrack works:

1. It starts sending REGISTER requests to register a specific extension line
2. In the mean time the SIP server starts responding back asking for authentication.
3. The response also contains a nonce, which is a unique number or bit string that should only be used once. This nonce is used as the challenge in the challenge-response mechanism.
4. Svcrack uses the nonce and other properties to compute the challenge response then sends that back to the server

Svcrack will repeat the above procedure until the password gets cracked and an OK message is recieved, or until there are no more passwords to try.

During testing, we were able to run speeds up to 80 passwords per second - that is 6,912,000 passwords a day. These numbers are dependent on the SIP registrar and of course, on a real network, latency and other factors will seriously affect these results. Some registrars allow the attacker to reuse the nonce. This makes the registrar servers vulnerable to replay attacks. This feature is also useful during password cracking, since it can make the process faster. In fact, svcrack has an option which allows auditors to exploit this feature and possibly achieve faster speed.

introduction to svmap

Svmap is a network scanner for SIP. Similar to nmap - it will scan for devices on ports specified by passing the right command line options. Once svmap finds a device that supports SIP, it will extract information from the response and identify the type of device. Anyone running this tool will typically end up with a list of IP addresses of SIP devices and the names for those devices.

A penetration tester or security auditor will probably find this tool particularly useful especially during reconnaissance. With the IP address, device name and possibly version at hand, he or she can then target security weaknesses specific to that device. A security administrator or security analyst can also make use of svmap to list different active SIP user-agents on the network. Based on this information, the security administrator then has the ability to identify rogue and vulnerable devices which can cause a security concern.

Svmap is able to scan for SIP devices much faster than generic UDP port scanners. Typical port scanners such as nmap, scan UDP ports by sending a packet to each port and expecting an ICMP packet which indicates that the port is closed. If no ICMP error is received within a reasonable time, the port scanner assumes that the port is either open or else filtered. While this method has worked for years, it can never be considered efficient or neat, (at least) because of two reasons:

• The majority of UDP ports are closed - therefore having to wait for each ICMP error to confirm that the port is closed is not a good idea
• Nowadays a lot of devices are behind firewalls or NAT and will never reply with an ICMP error

Svmap works by sending a UDP packet containing a SIP request to a range of specified IP addresses, and listing those that send back a valid SIP response. Since UDP is a connectionless protocol, this method can be relatively fast. For example, during testing we were able to identify around 200 SIP devices on one particular network, out of a scan of IP addresses in less than 3 minutes. On the other hand when we scanned the same network with nmap version 4.20 (default options for sU scan on port 5060), it took longer than 20 minutes at which point we stopped the scan.

For examples on how to use svmap check out the wiki.
Download the whole SIPVicious tool suite from the project page.

SIPVicious version 0.2.1 released

Go get it from the usual place.

This is mostly a bug fix release but we still managed to squeeze in some minor features:

• Session state is now saved

• svmap supports sending INVITE to particular extensions

If you're on a system with subversion installed, you can simply run "svn update" to receive the latest version. Check out the Changelog to see what changed.

More on INVITEing phones to ring

This is a follow up on a previous post.

Apart from using a softphone, you can make use of svmap.py (part of SIPVicious tool suite) to reproduce the behavior:

./svmap.py -m INVITE 192.168.1.4 -p5061

Where 192.168.1.4 is the IP of the SIP phone and 5061 is the SIP port of the phone. For a ghost call effect, if you have a network with all SIP phones listening on port 5060, you can just run the following to get them to ring at the same time:

./svmap.py -m INVITE 192.168.1.1/24

Updated list of softphones tested and exhibiting this behavior:

• WengoPhone **
  
• X-lite release 1011b
• SJPhone 1.65.377a
• Ekiga 2.0.11 (beta)
• Yate
• SIP Communicator

Some VoIP phones (hardware) were also tested and exhibit this behavior as well:

• GrandStream GXP 2000
• Grandstream BT100
• Aastra 480i
• Aastra 9133i
• Polycom IP330
• Cisco CP7940G*
• Lancom VP 100*
• Linksys SPA 921*

* Requires a valid extension
** Requires valid extension or no extension

SIPVicious tools in the works

Been working on more features with regards to svmap. Some of these features find themselves in svwar and svcrack as well in the next release version. So what features of interest?

• Svmap is now session based. This allows us to have the following features:
• You may stop a current scan, go have a coffee and resume it later.
• If the power cuts, a natural disaster occurs or anything bad happens, you can resume your scan later because of the autosave feature, provided you survived the accident.
  
• Results are now stored in BSD database form. Svreport.py comes in quite handy .. more on this below.
• You can now pass various types of host ranges to svmap, depending on your (bad) taste and habits. Examples:
  
• 1.1.1.1-20 1.1.2-4.1-10
• 1.1.1.*
• 1.1.1.1-1.1.2.20
• sipvicious.org/22
• 10.0.0.1/24
• sipvicious.org
• Random scans. Two kinds of random scans:
• Internet random - you don't pass svmap any host/ip ranges. It scans the IPs randomly, avoiding those that belong to private networks or reserved address space
• Random targeted scan. You pass a range of hosts/ips and they are scanned randomly instead of sequentially.
• Output to an ASCII table when the scan is complete. If you need to see the results instantly, then the verbose option is your friend. Double verbose gives out a lot of debug information.
• Lots of bug fixes, optimizations and cleaning up ;)
  

Earlier I mentioned svreport.py which is a new script that will be soon added to the suite. It will grab previous sessions from SIPVicious tools and export them to the following formats:

• PDF - Portable Document Format
  
• XML - Extensible Markup Language
  
• CSV - Comma delimited files
  
• Text - Human friendly format
  

That's all for now. If you're curious check out the svn repository. Otherwise version 0.2 is on the way.

Security Analysis of Voice-over-IP Protocols

This paper talks about the state of security or lack of of the VoIP protocols. It talks a lot about encryption and introduces some attacks in that area. Of interest:

• replay attack on SDES key exchange causing SRTP to use the same keystream in multiple sessions. This means that the attacker removes encryption from SRTP-protected data streams.
• An attack on ZRTP involving unauthenticated uesr IDs. This allows bypassing / disabling of authentication or a DoS attack.
• A security issue related to randomness in MIKEY

How to turn a Grandstream SIP phone into a remote bug

The "Institut National de Recherche en Informatique" has done it again. They released details of their research regarding the Grandstream GXV-3000 SIP phone - specially on a bug that allows one to crash the phone, and set it off the hook without ringing. This last exploit effectively turns such phones into a spying device, allowing crooks and other evil entities to discretely listen on conversations in a room where the phone is installed.

Apparently, it is not just these Grandstream devices that are vulnerable to the same attack, but it affects "some SIP stack engines". The trick is to send a "183 Session Progress" SIP message to the phone following an INVITE request, which in turn makes it go all fuzzy and start sending RTP packets to the attacker. The full-disclosure post further illustrates this with a example code in perl.

Meanwhile, all this wouldn't have been possible for the Institute without using their SIP stateful fuzzer. The paper presenting this project can be found here. Least that I can say is that this is very cool stuff.