Distributed SIP scanning during Halloween weekend

Nov 4, 2010

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:

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.