Follow us on RSS or Twitter for the latest updates.

May 26, 2011

SIPVicious Tool Suite v0.2.6 – SIP/VoIP Security Auditing Tool


SIPVicious suite is a set of tools that can be used to audit SIP based VoIP systems. Why the name? Because the tools are not exactly the nicest thing on earth next to a SIP device. And the play on the sound seems to work. As an extra bonus, it rhymes with the name of Sex Pistol’s bass player.

It currently consists of five tools:
  • svmap – this is a sip scanner. Lists SIP devices found on an IP range
  • svwar – identifies active extensions on a PBX
  • svcrack – an online password cracker for SIP PBX
  • svreport – manages sessions and exports reports to various formats
  • svcrash – attempts to stop unauthorized svwar and svcrack scans
Requirements

Python – SIPVicious works on any system that supports python 2.4 or greater.

There’s a good blog post covering the new stuff here too, mainly svcrash:

How to crash SIPVicious – introducing svcrash.py

You can download SIPVicious v0.2.6 here:

sipvicious-0.2.6.zip

Or read more here.

Author: dfgdfg,

May 26, 2010

How to crash SIPVicious - introducing svcrash.py


A new tool has been added to SIPVicious - svcrash.py. As the name implies, it crashes something - svwar.py and svcrack.py. This tool is meant to be used by system administrators and organizations that are receiving unauthorized scans on their exposed IP PBX.

Quick links: Download the latest version :: Watch a short demo of svcrash.py

Since this is a little different from the usual, I'll provide a bit of background first.

Background

If you had been following the Asterisk or VoIP provider blogs and forums, you might have noticed people complaining about bandwidth saturation due to SIP scans. Some people had been using Amazon EC2 based servers to look for SIP servers such as Asterisk, which have weak passwords. As a result of these scans, organizations were getting a considerable amount of bandwidth used - leading to denial of service (DoS). Why did this happen?

  • The attackers were using huge lists of extensions / passwords in their scans, (apparently) sometimes using the --force option in svwar.py
  • Even if blacklisted, old versions of svwar.py and svcrack.py keep sending messages because they are stateless
  • Originally, Amazon's abuse team did not respond to these attacks in a timely fashion
  • The victim providers had less bandwidth than Amazon's cloud
This meant that just like other denial of service attacks, dropping the packets at the victim host (eg. using iptables) is not enough.

So what's new?

1 - Updated SIPVicious to care more...

A few weeks ago I released a new version of SIPVicious (v0.2.5) which has a timeout for svwar.py and svcrack.py. If either of these tools receives no response then it stops scanning. The reason why they receive no response could be that an intrusion prevention system blocked the scanning IP, thus making it useless to keep on scanning anyway.

I urge everyone to update to the latest version (v0.2.6).

2. Create a small basic tool that breaks the attack:

A more aggressive approach is to make use of svcrash.py. What this tool does is abuse an unhandled exception when decoding the information from the "To" tag. This causes both svwar and svcrack to crash, thus stopping an attack. This tool is included in v0.2.6, which also includes a fix for this bug.


How to run svcrash.py

Mode 1: python svcrash.py -d attackerip -p attackerport
This would send one message which causes the attack to stop. You would need to find out the IP address and the attacker port from your PBX log files or by taking a look at Wireshark or tcpdump during the attack.

Mode 2: sudo python svcrash.py --auto
This would make use of scapy (i.e. you need to have scapy v2 installed) to monitor the traffic and respond automatically every 2 seconds. This automates the whole thing so that one can leave it running to block the next attack.

Mode 3: sudo python svcrash.py --astlog=/var/log/asterisk/full
Makes use of the Asterisk log file as a source of information. This option is still experimental as it does quite a bit of guessing. Needs more testing. For production use, the --auto mode is probably safer.

If you have any questions about svcrash, check out the FAQ, and do not forget the SIPVicious FAQ too.

Author: dfgdfg,

Categories: ,