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/

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

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.

11 million Euro loss in VoIP fraud .. and my VoIP logs

And the attackers made over 1 million in profits.
This just emerged from a raid (and hearing apparently) in Romania and other countries. The two main persons being fingered are Catalin Zlate and Cristian Ciuvat. It seems that they were scanning for PBX servers with phone extensions that have weak passwords. Then they abused these accounts to make phone calls for "free", except that free has the price of 11 million EUR for the victims!


Apparently, originally they used these accounts for their own personal phone calls. However they got greedy and between October 2009 to February 2010, they made 23500 calls / 315000 minutes to premium numbers. Then (from what I understood), they got even more greedy and used Shadow Communication Company Ltd. This site is still available right now - whois shows the name of Cristian Ciuvat (thanks for someone on pointing this out). This site contains lists of prices for premium numbers, linking to another site Ivrstats.net. Using this they recruited other people to make  1,541,187 fraudulent calls or 11,094,167 minutes of talk time.

So right now there are 42 people in court with raids happening in London, Neamt, Brasov, Cluj and Maramures. This is all according to various sites in Romanian, translated automatically using Google translate.

One of the original articles on this can be found here.

Here's a screenshots from their site (in case it goes down):

Some thoughts

On our honeypots we have seen Zoiper messages from Romania and this could possibly be very related. I decided to check out my logs and sure enough found the sort of behavior described in the articles describing the illegal activities. The following IP addresses had Zoiper in their user-agent header when connecting to my simple VoIP honeypot:

• 89.42.156.102 - Romania
• 74.115.0.25 - US (San Jose)
• 68.194.64.146 - US - Brooklyn
• 74.115.0.24 - US (San Jose)
• 89.42.194.224 - Romania
• 79.117.27.97 - Romania
• 89.42.187.151 - Romania
• 64.9.175.89 - US (Austin)
• 95.76.211.188 - Romania 
• 109.99.35.113 - Romania
• 85.186.123.121 - Romania
• 95.22.116.11 - Spain

Here's an example SIP message that was sent from the 1st IP:

INVITE sip:0040767091012@X.X.X.X;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 89.42.156.102:5060;branch=z9hG4bK-d8754z-07cf25937cf90e2a-1---d8754z-
Max-Forwards: 70
Contact: <sip:1234@89.42.156.102:5060;transport=udp>
To: <sip:0040767091012@x.x.x.x;transport=udp>
From: "Unknown"<sip:1234@x.x.x.x;transport=udp>;tag=ce2e1a65
Call-ID: NmNhZTE5MGMwM2IyMDg3OTM5YWY1YTQ5OWYzZWYzNDE.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
User-Agent: Zoiper rev.6751
Content-Length: 329

v=0
o=Zoiper_user 0 0 IN IP4 89.42.156.102
s=Zoiper_session
c=IN IP4 89.42.156.102
t=0 0
m=audio 8000 RTP/AVP 3 0 8 110 98 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:110 speex/8000
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=30
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

The phone number that the Zoiper user tried calling was "0040767091012". Romanian numbers start with +40, so one can assume that this is some phone that the attacker was using to see if the call is terminated or not. This number is not a premium number. I have looked at other logs and some were probably premium numbers.


Note regarding Catalin Slate: is this the same person who was in 2005 caught with credit card fraud (reference here)?

I would be interested in hearing more about this case as it sheds some light on what's actually happening in the background.

Update:
Thanks goes to Stefan Tanase for pointing out the original article in Romanian. The also added the following:

As far as I understand, they were using other premium numbers affiliate networks at first and then, when they realized the potential, they set up a company in the UK - Shadow Communications Inc. - through which they were able to sign a  contract on their own with a premium rate number provider and offer their own affiliates service, basically taking their "business" to a whole new level.

Conclusion

All in all, it looks like these attackers were not so technically advanced after all, yet managed to hit the million euro mark. I wonder what more skilled and stealthy criminals are able to do!

Distributed SIP scanning during Halloween weekend

Over last weekend there were a number of reports of VoIP (especially Asterisk) servers that were "under heavy attack". I have looked at some packet traces and noticed how the SIP messages look very similar to the ones generated by SIPVicious especially svwar.py. In fact, I think this is a modified version of SIPVicious that is being distributed on a botnet.

Take a look at the following message generated by these new scans:

REGISTER sip:311@xx.xx.xx.xx SIP/2.0
Via: SIP/2.0/UDP xx.xx.xx.xx:5060;branch=88y8n2p4U3;rport
Content-Length: 0
From: "311"
Accept: application/sdp
User-Agent: Asterisk PBX
To: "311"
Contact: sip:311@xx.xx.xx.xx
CSeq: 1 REGISTER
Call-ID: 1728224566
Max-Forwards: 70

The following message would be generated by svwar.py for the same extension number (username):

REGISTER sip:311@xx.xx.xx.xx SIP/2.0
Via: SIP/2.0/UDP yy.yy.yy.yy:5060;branch=z9hG4bK-4059165492;rport
Content-Length: 0
From: "311"; tag=3331310133333331373232343735
Accept: application/sdp
User-Agent: friendly-scanner
To: "311"
Contact: sip:311@xx.xx.xx.xx
CSeq: 1 REGISTER
Call-ID: 3259315903
Max-Forwards: 70

Notice how the order of the headers is exactly the same and so on. However there are some obvious differences:

• the user agent is now "Asterisk PBX" instead of "friendly-scanner"
• the branch is totally random instead of starting with "z9hG4bK" as is standard in SIP/2.0

Additionally the To tag is apparently generated differently. In SIPVicious the code to generate the "To tag" is the following:

def createTag(data):
    from binascii import b2a_hex
    from random import getrandbits
    rnd = getrandbits(32)
    return b2a_hex(str(data)+'\x01'+str(rnd))

The data would typically contain the extension which is then concatenated to a random number and encoded. This would later be decoded when the target responds, which helps make the scanner stateless.

In the case of this new scanner, we cannot decode the extension number in the same way.
So clearly, these guys want to bypass intrusion detection/prevention systems such as fail2ban, snort-inline etc by doing the following:

• distributing the scans across different IP addresses
• changing the obvious SIPVicious signatures to something more common, such as "Asterisk PBX" since no one in their right mind would block that

Some more interesting things:

• the source ports for these scans appear to be high ports, indicating that the same host in the botnet is scanning many other hosts at the same time (if the port allocation code is the same as the original)
• each host scans for consecutive numbers for the extension
  

If I am correct, then the goals are obvious - enumeration of extensions and then password cracking to be able to make fraudulent phone calls.

Unfortunately, this scanning has been causing bandwidth problems for VoIP providers out there who need to expose their SIP servers on the 'net.

So what do we do about this?
It appears that botnets are now being used for distributed scanning. Therefore it might make sense to look at what others have done before when it comes to botnet borne attacks:

• Improved their IPS systems to protect against attack (I have some ideas on how to do this)
• Hid behind VPNs or just shifted to another protocol that is not yet being attacked as much (think SIP over TLS or IAX2 etc)
• In the case of DDoS attacks, financial companies and online-gambling companies just use expensive 3rd parties that should absorb all the network traffic
• Usage of blacklists for IP addresses that are known to be part of a botnet (check out the VoIP Blacklist Project)

Unfortunately none of these are real solutions and are rather simply mitigation techniques. In many cases, VoIP providers cannot make use of VPNs or other similar solutions.

The mailing lists had some interesting conversations about this:

• asterisk list
• voipsa
• voipops

And Stuart Sheldon and others blogged about this too.

Thanks to anyone (you know who you are :)) who sent me info already. If anyone has any more insight into this, mitigation, solutions, code or packet traces, please email me.

AstriCon roundup and vendors adding security features

So I've finally been to AstriCon and I noticed a great increased interest amongst the attendees with regards to security, fraud and "hacking". The slides for my presentation titled "Just how vulnerable is your phone system" can be downloaded from this location.

So what are the changes and additions from the software developer's side?

1. Asterisk 1.8 has been released touting TLS support for SIP and SRTP support too, plus a framework to make auditing easier
2. 3CX have released a major security update with features to make it easier to set proper passwords
3. I just received an email from Brekeke highlighting their security page on their wiki which was originally published on March 11, 2009

What accounts for these changes? From talking with the people at AstriCon I started understanding why the increased interest in security: organizations are really getting hurt with call fraud and this seems to be on the increase.

Plus the advise I heard again and again from developers for FreePBX-based systems was:
"Do not put your FreePBX / configuration available on the Internet, it is not designed for that!"

But if you do a simple scan for Asterisk boxes (using svmap.py for example), you'll notice many systems out there that do not heed this advice. Apart from that, as Blake Cornell showed in his presentation, there are many attacks on FreePBX-based systems that can be abused without direct access to the HTTP configuration interface.

BruCON Training: Module 4, Attacking Unified Communications

The final module in the upcoming pentesting VoIP crashcourse is the most exciting one. In this section we look at VoIP systems as a whole. Unified communications is one of those words that have been hyped up to include everything, from chat to video phone calls and SMS. What we will look at in this section is how to go about breaking into the following during a penetration test:

1. Web application security flaws in Asterisk-based PBX servers
2. Attacking various services open in PBX servers, such as TFTP
3. How once you're on a PBX network, you can sometimes simply use your phone to spy on other phone calls
4. How to make use of hardware taps 
5. Hardware phone features that can be abused
6. Abuse of various exposed features in Cisco call manager accessible on the HTTP server

This module will help familiarize the attendees with the target servers and system. Who knows, it may even give a kick-start to find some new 0-days in one of these Unified Communications solutions ;-)