New beta of VIPER VAST released 2.76

And that includes all the latest goodness, including SIPVicious. This is a great tool for those needing an up to date VoIP hackin.. er penetration testing distro :-) Download it from here.

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. Feel free to contact me sandro@enablesecurity.com.

A crashcourse in pentesting VOIP networks at BruCON 2010

Joffrey CZARNY and myself (Sandro) will be hosting a crashcourse at BruCON 2010. This will be a two day workshop on the 22 & 23 September 2010. In a nutshell, we will be helping the attendees quickly get up to speed with VoIP networks and performing security assessments in that idea. More information about the training can be found at the official page.

If you would like to register for the training go straight to the BruCON training registration page. Hope to see you there!

As always, I'll be glad to answer any questions by email.

Getting root access on Cisco CallManager 7 and 8 Server, Athcon, updates in new tool tftptheft and the VoIP honeynet challenge

Lots going on right now. The following is a summary:

• Recurity Labs just published the jail-break for Cisco CallManager (CUCM) v7/8 which I had something to do with ;-)
• Will be presenting at Athcon on VoIP insecurities and cybercrime - drop me an email if you'll be there
• TFTPTheft has been updated to support template filenames

Will be posting more on TFTPTheft with use cases and examples. If you do have questions, drop me an email. 

Also, right now there's a VoIP honeynet challenge for anyone into that sort of thing :-)

(image taken from striatic)

New tool in the works: TFTPTheft

Most sysadmins just love the idea of switching on a box that just works automatically. In the case of IP phones that is typically possible by setting up the right DHCP config and a TFTP server hosting firmware and configuration.

My introduction to TFTP
The TFTP protocol typically runs over port 69, and the above image shows a rather insecure doll. The TFTP protocol is rather simple and lightweight:

• Runs on top of UDP
• Does not support authentication
• Only supports pulling and pushing (GET and PUT) of files (no directory listing)

New tools?

So to retrieve a file from a reachable tftp server, one only needs to know or guess the correct filename. There are a couple of tools which do this already including a Metasploit module. However what I wanted was more specific:

• A tool that's fast like SIPVicious
• Which allows me to brute-force ranges of Cisco phone filenames (say SEP[mac-address].cnf.xml)
• And one which just downloads the guessed files as the TFTP server is being scanned

Therefore I'm releasing a new set of tools called TFTPTheft which includes 2 new tools:

• thief.py, which does what I just described (guess filenames and download files)
• finder.py, which searches for TFTP servers on the network

To give it a try, the code is currently in a mercurial repo and you can pull it by:

hg clone https://tftptheft.googlecode.com/hg/ tftptheft

I am releasing this code so that you can send me feedback. So please go forth and give this a try, run it against your VoIP system (it's likely that the PBX / Call manager will have a TFTP server running). Then send me an email with your experience: sandro at enablesecurity.com

SIPVicious 0.2.5 out

Latest SIPVicious. It has been a while since I released an update to SIPVicious. It is mostly a bug-fix and "play nice" update. Download it from here.

Changelog:

v0.2.5 (20100519)

• Feature:  svwar.py has "scan for default / typical extensions" option. This option tries to guess numeric extensions which have certain patterns such as 1212 etc. Option is -D, --enabledefaults

• General:  svwar.py and svcrack.py now have a new option which allows you to see how long the tools will scan without receiving any response back. This allows us to prevent flooding the target. Some PBX servers now have built-in firewalls / intrusion prevention systems which will blacklist the IP address of anyone using svwar or svcrack. Therefore if the IP is blacklisted it makes sense to stop scanning the target. The default for this option is 10 seconds. Set this option by using --maximumtime [seconds]

• Removed:  svlearnfp.py is now discontinued. The tool is still included for historic reasons but disabled.

• Feature:  svmap.py now includes the following new features:

            --debug - shows messages as they are received (useful for developers)
            --first - scans the first X number of hosts, useful for random or large address pool scanning
            --inputtext - scans IP ranges taken from a text file
            --fromname - sets the from header to something specific useful for abusing other security issues or when svmap is used in a more flexible way then usual ;-)

• Feature:  svreport.py now has two new modes:

            - stats, which lists some statistics
            - search, allows you to search through logs looking for specific user agents

• Bug fix:  svwar.py now by default does not send ACK messages (was a buggy feature that did not follow the standard) 

• Bug fix:  svwar.py - the template passed through --template option is now checked sanity.

RTP Traffic to 1.1.1.1

I was reading RIPE Labs' very interesting post called Pollution in 1/8. The article talks about traffic being sent to the 1/8 address space, which has recently been temporarily allocated. One part of the article caught my eye:

"We found that almost 60% of the UDP packets are sent towards the IP address 1.1.1.1 on port 15206 which makes up the largest amount of packets seen by our RRC. Most of these packets start their data section with 0x80, continue with seemingly random data and are padded to 172 bytes with an (again seemingly random) 2 byte value. Some sources (http://www.proxyblind.org/trojan.shtml) list the port as being used by a trojan called "KiLo", however information about it seem sparse."

I think I have an answer to that. Its not a trojan. On the SIP front we've been seeing some INVITE scans which start an RTP stream to IP 1.1.1.1 and port 15206. In fact RTP streams start with 0x80. Enough talk, lets take a look at a sample SIP message from these INVITE scans:

INVITE sip:011442083327467@re.pl.ac.ed SIP/2.0
Via: SIP/2.0/UDP 83.142.202.195:3058;branch=ca4b60ae7ba821fREPLACEDjrgrg;rport
From: <sip:sip@83.142.202.195>;tag=Za4b60aeREPLACED
To: <sip:011442083327467@re.pl.ac.ed>
Contact: <sip:sip@83.142.202.195>
Call-ID: 213948958-00227506489-384748@83.142.202.195
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 503

v=0
o=sip 2147483647 1 IN IP4 1.1.1.1
s=sip
c=IN IP4 1.1.1.1
t=0 0
m=audio 15206 RTP/AVP 10 4 3 0 8 112 5 7 18 111 101
a=rtpmap:10 L16/8000
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:112 AAL2-G726-32/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:7 LPC/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:111 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

So what does this mean? According to the article, almost 60% of the traffic being sent to 1.1.1.1 consists of these RTP streams. The majority of the traffic is sent to 1.1.1.1 and is UDP traffic, meaning that the majority of Internet traffic being sent to the 1.1.1/24 is in fact RTP traffic generated by these scans.

The impression that I'm getting is that there's a lot of such INVITE scanning going on, and a large number of SIP entities on the Internet are responding to these scans by starting an RTP stream.

Sjur posted his analysis of this on his blog too.