SIPVicious

SIPVicious 0.2.7 released and rewrite coming up, looking for testers!

noreply@blogger.com (sandro) — Wed, 22 Feb 2012 16:01:00 +0000

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

noreply@blogger.com (sandro) — Mon, 02 Jan 2012 12:55:00 +0000

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

noreply@blogger.com (sandro) — Tue, 25 Jan 2011 17:27:00 +0000

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

noreply@blogger.com (sandro) — Tue, 14 Dec 2010 16:56:00 +0000

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

noreply@blogger.com (sandro) — Thu, 04 Nov 2010 17:49:00 +0000

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.

AstriCon roundup and vendors adding security features

noreply@blogger.com (sandro) — Fri, 29 Oct 2010 13:26:00 +0000

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?

Asterisk 1.8 has been released touting TLS support for SIP and SRTP support too, plus a framework to make auditing easier
3CX have released a major security update with features to make it easier to set proper passwords
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

noreply@blogger.com (sandro) — Tue, 07 Sep 2010 17:01:00 +0000

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:

Web application security flaws in Asterisk-based PBX servers
Attacking various services open in PBX servers, such as TFTP
How once you're on a PBX network, you can sometimes simply use your phone to spy on other phone calls
How to make use of hardware taps
Hardware phone features that can be abused
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 ;-)

BruCON Training: Module 3, Attacking the media

noreply@blogger.com (sandro) — Thu, 02 Sep 2010 17:39:00 +0000

This is part of the BruCON VoIP security crash course training intro. For more information about the course and to secure a place, check out the BruCON website.

We trust our phones with our sensitive data more than most other forms of communications. We may not trust sending our credit card number by email to the hotel. In the end we give it to them on the phone anyway, and it may not matter if the phone is a mobile phone or a VoIP phone.

Since VoIP phones look very much like traditional phones, most people are impressed to learn (the hard way) that they can be intercepted just like other devices and computers on the network. This is one of the topics covered in the third module. We will use readily available tools that will allow you to sniff phone calls over the network very easily. Tools include Wireshark, UCSniff and Cain and Abel.

These tools will handle RTP and codecs differently so we will see which ones are best for the job.

As a penetration tester, you will encounter setups that try to prevent ARP cache poisoning and other attacks that allow for media interception. During this training we will look at each of these solutions and look how they can be often defeated.

When it comes to media, interception is not the only concern. There are tools that perform RTP injection, i.e. modify the RTP stream on the fly, which can make an interesting demonstration. Then there's convert channels, where an insider embeds his/her data inside the RTP stream.

BruCON Training: Module 2, Attacking signaling protocols

noreply@blogger.com (sandro) — Wed, 01 Sep 2010 16:01:00 +0000

This is part of the BruCON VoIP security crash course training intro. For more information about the course and to secure a place, check out the BruCON website.

Most VoIP systems perform signaling using a protocol separate than the media transfer protocol. Signaling protocols allow VoIP systems to register, authenticate, and initiate phone calls and tends to carry a lot of intelligence with it. In this part of the training, Joffrey and myself will talk you through the following different signaling protocols and attacks that apply to these protocols:

SIP - an open standard
IAX2 - used by Asterisk PBX and compatible phones
SCCP (Skinny) - used by Cisco systems
MGCP - the media gateway control protocol, typically used between gateways and IVR systems
H.323 - found in gateways and older systems

The fun part? The exercises! We plan to use a hands-on approach rather than simply describe the protocols and attacks.

These are some of the practicals we have in store:

Sniffing SIP, in order to understand how it all works and also spy on the metadata or signal
Scanning SIP, to see how we can easily identify SIP devices very quickly using SIPVicious and other tools
SIP extension enumeration and online password cracking, to understand better how VoIP attackers are in fact making phone calls for free at the expense of their victims
Avoiding toll / fraudulent calls, featuring the main ways that attackers are abusing SIP PBX servers out there
INVITE floods, which is still an effective attack and bring down various SIP enabled devices
Fuzzing SIP, existent tools and their usage
Using John the ripper to crack SIP passwords, which also includes capturing the SIP authentication messages and patching John the ripper to crack the hash
Online and offline password cracking in IAX2, the tools and their usage
Scanning IAX2 which allows us to find Asterisk servers
MiTM attacks using SCCP proxy, which is a fun way of playing with the phones and can allow us to turn Cisco phones into remote spy bugs
Capture FAC (Forced Authorization Codes) code, which is a restriction usually used in Cisco VoIP environments to allow / block international calls
Call fraud with MGCP, since MGCP has little or no security
DoS on MGCP, or how to cause your VoIP Gateway to go down
RTP redirection, which can allow all sorts of fun (and sometimes profit)
Callmanager hijack (details later ;-))

With all these exercises we expect all the attendees to get really busy and gain useful experience with the signaling protocols.

BruCON Training: Module 1, An Introduction to ...

noreply@blogger.com (sandro) — Tue, 31 Aug 2010 13:32:00 +0000

An Introduction to VoIP technology, security threats and solutions, module 1. This module allow us to set the stage for the rest of the training. We will introduce the players - Asterisk, Cisco unified communications and other products. We will introduce the protocols briefly - SIP, SCCP (Skinny), IAX2, H.323 and MGCP. We will also look at how VLANs and other solutions are used to provide security (and where they fail).

We will then focus on security in terms of confidentiality, integrity and availability without going into too much detail (just to wet your appetite ;-)).

Confidentiality
When it comes to VoIP, confidentiality ensures that the communications - phone calls and any signaling data - cannot be spied upon. Confidentiality is a major weakness in the case of many VoIP systems. One obvious security issue is when internal attackers spy on phone calls by sniffing the RTP stream. However this is not the only attack vector. We will give examples of tricks that can be pulled off by external attackers that allow them to compromise confidentiality remotely, without (layer 2) access to the network.

Integrity
Caller ID spoofing, toll fraud and modification of signal or media affects the integrity of the VoIP system. In this section we will look at these and various other security flaws that do not necessarily allow attackers to gain illegal access to confidential information. These security flaws however, may allow attackers to cause organizations to loose large sums of money.

Availability
This tends to be the security flaw that really affects organizations directly. When the phone system is down, many organizations suffer. This is especially true for call centers, which base their revenues on phone calls. With VoIP, attackers can abuse flaws at various levels to cause denial of service. In this section we will introduce some attacks that are specific to VoIP and others that affect systems in general.

BruCON Training: A crashcourse in pentesting VOIP networks (update)

noreply@blogger.com (sandro) — Mon, 30 Aug 2010 09:21:00 +0000

We just updated the outline of the 2 day crashcourse on the main BruCON training website! In the coming days I'll be highlighting the modules to explain what each consist of. Training registration is from this page, and for any questions get in contact with Sn0rky or myself.

This is what it looks like:

Module 1: Introduction to VoIP technology, security threats and solutions

Introduce the protocols
Mitigation technologies
How confidentiality / integrity / availability applies to VoIP
1. fraud
2. spying on phone calls
3. modification of phone data
4. denial of service

Module 2: Attacking signaling protocols

SIP
1. introduction to the protocol
2. scanning for SIP
3. attacking SIP
4. exercises include:
  1. sniffing SIP
  2. scanning SIP
  3. SIP extension enumeration and online password cracking
  4. Avoiding toll / fraudulent calls
  5. INVITE floods
  6. Fuzzing SIP
  7. Using John the ripper to crack SIP passwords
IAX2
1. introduction to the protocol
2. scanning for IAX2
3. attacks on IAX2
4. exercises include:
  1. online and offline password cracking
  2. scanning IAX2
SCCP
1. introduction to the protocol
2. scanning for Cisco PBX / SCCP
3. Attacks on SCCP
4. exercises include:
  1. MiTM attacks using SCCP proxy
  2. Capture FAC code
  3. Callmanager hijack
MGCP
1. introduction to the protocol
2. scanning for MGCP
3. attacks on MGCP
4. exercises include:
  1. Call fraud
  2. DoS on MGCP
  3. RTP redirection
H.323
1. introduction to the protocol
  1. H.225
  2. H.245
2. scanning for H323
3. attacks on H323
  1. Frames Injection
  2. DoS on H323

Module 3: Attacking the media

Wiretapping
1. Understanding the basics, ARP poisoning and other MiTM attacks
2. exercises include using various tools, including Wireshark, for tapping VoIP calls
RTP stream modification
1. how it works
Convert channels
1. how it works, concepts and reality

Module 4: Attacking Unified Communications

Trixbox / Elastix vulnerabilities
1. default passwords are common
2. TFTP abuse
3. Spying on phone calls using your phone
4. Privilege escalation
5. Exercises include:
  1. spying on phone calls
  2. abusing Trixbox features
  3. exploitation of weak permissions
Asterisk
1. Dialplan injection
2. Setting up a backdoor
Hardware information gathering
1. physical bridging
2. passive ethernet tap
3. bypassing lock / restrictions on the phone
4. exercises include:
  1. hardware for tapping
  2. hardware phone abuse
Cisco Unified Communications vulnerabilities
1. Extension mobility abuse
2. Webdialer
3. CCMuser SQL injection
4. Billing system
5. Jailbreaking CUCM
6. Exercises include:
7. Jailbreaking CUCM
8. Webdialer abuse

New beta of VIPER VAST released 2.76

noreply@blogger.com (sandro) — Wed, 21 Jul 2010 08:43:00 +0000

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

noreply@blogger.com (sandro) — Tue, 22 Jun 2010 13:28:00 +0000

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

noreply@blogger.com (sandro) — Tue, 08 Jun 2010 10:17:00 +0000

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

noreply@blogger.com (sandro) — Tue, 01 Jun 2010 10:36:00 +0000

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

noreply@blogger.com (sandro) — Fri, 28 May 2010 07:21:00 +0000

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

noreply@blogger.com (sandro) — Wed, 19 May 2010 17:01:00 +0000

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

noreply@blogger.com (sandro) — Thu, 04 Feb 2010 00:10:00 +0000

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.

On breaking phonecall encryption and publishing fake research

noreply@blogger.com (sandro) — Tue, 02 Feb 2010 00:23:00 +0000

Recently, some "not so anonymous" security researcher posted research on a website called InfoSecurityGuard. It showed how he had broken the encryption provided by various mobile phone security products. Ofcourse this caught the eyes of various journalists who wrote about this without much consideration. So what did this researcher find out?

The research focuses on the fact that once you get malicious software on a phone, you can listen on the phonecall even with encryption software in place, such as CellCrypt or Gold-Lock. The researcher says that this is a result of these products not having any man in the middle protection.

Well, guess what: the products on test do network encryption. Putting software on the same phone as the one doing the encryption/decryption does not constitute as man in the middle by most definitions. Such products do not typically protect your calls from being recorded if your phone is compromised.

This applies to most other applications, not just phonecall encryption. If your security solution is meant to provide network encryption, then it typically will not resist an attack on the endpoints. Some software (like PhoneCrypt) might try to do that, but in the end of the day, if the endpoint is compromised, then there's various attacks that the software cannot handle.

Think about replacing the firmware, or the hardware itself. These are real problems that apply when your phone is compromised, yet such products are not meant to handle these issues.

After this "fake" research came out, some people actually investigated to confirm the suspicions that they were published by a known vendor - in fact the only vendor that did well in the reviews - Securstar. Read more about that on infosecurity.ch and The Register.

Oh, and one word of advice for anyone replicating Securstar's efforts - do not put your Trixbox PBX with the FOP in the open.

ps. at the time of writing Securstar's site is inaccessible and showing some php errors:

Getting phonecalls during the middle of the night on your Asterisk server?

noreply@blogger.com (sandro) — Thu, 10 Dec 2009 15:33:00 +0000

You're not alone. People with malicious intentions are scanning for open SIP servers all the time. Aster1sk from Geekhut.org posted a useful video for those of you using a badly configured FreePBX + Asterisk. I'm sure this will be useful for someone..

VIPER VAST includes SIPVicious

noreply@blogger.com (sandro) — Mon, 05 Oct 2009 15:01:00 +0000

A quick post to refer to the live bootable CD from Viperlabs called VIPER VAST. It's a Linux distribution that includes a good number of tools that can help in a VoIP security assessment. I think I'll be giving this a try next time around. What makes this useful is if you want to quickly have a machine with all the right libraries, drivers and packages installed to be able to run tools such as UCsniff. As for SIPVicious, it doesn't really have many requirements, just python. One can just run SIPVicious on most out of the box Linux and OSX. On windows one would need a python installation such as Activestate's distribution. However I am pleased to see SIPVicious being included. Congratulations to the Viper labs team for this new distro!

VoIP security workshop at BruCON 2009

noreply@blogger.com (sandro) — Thu, 17 Sep 2009 10:03:00 +0000

I'm back in my little island after SEC-T (which had excellent content btw!) but already need to leave again. This time to Brussels for BruCON, and together with Joffrey Czarny, I'll be hosting a workshop solely dedicated to VoIP security auditing.

Joffrey will be focusing on Cisco and other vendors and I'm really looking forward to that! I, on the other hand, will be talking more about freely available software such as Asterisk, Trixbox and X-lite. Here's a small preview of what's to come:

How to use siplib.py and iax2lib.py (used in VOIPPACK) to build security tools
We'll build scanners and extension enumeration tools in both SIP and IAX2
Showing that INVITE flood is just 3 lines of code which can bring down popular VoIP software (and we get to build those 3 lines of code!)
Showing denial of service issues (patched) in Asterisk
Reproducing the SIP digest leakage in less than 50 lines of code
Demonstration of web related issues that affect PBX servers
Show of how IPS systems can actually be harmful in the world of UDP

Looking forward to this .. if you want to join register at this page. Just 5 seats left!

SEC-T in Sweden and SIPVicious update in svn

noreply@blogger.com (sandro) — Mon, 07 Sep 2009 13:02:00 +0000

Its been a while since I updated SIPVicious, mostly because I have been working on SIPVicious 2.0 (being used in VOIPSCANNER.com). However I decided to add a few new options for svmap and svreport to help me with the research for this new presentation I'll be giving on Friday at SEC-T in Stockholm, Sweden.
The presentation is called "Searching for phones on the Internet" and subtitled "Adventures with SIPVicious".

Will be posting more details on the presentation later on, but lets describe the new features in svmap.py:

-d, --debug , which prints SIP messages received, very handy when you need to watch what's happening in the background
-I scan1, --inputtext=scan1, allows you to specify a text file containing ranges of IP addresses just like you would on the command line; however instead of putting a space between each range, you should put each range in a separate line
--first=100, allows you to specify the number of SIP messages to send until svmap quits; this is useful when you have large ranges of IP addresses and you only want to scan the first few thousand addresses; works well with --randomize

Svreport was also updated to support 2 new options:

stats : allows you to extract some basic statistics from the session files (saved svmap output)
search : which simply searches through svmap's sessions

To update your copy of SIPVicious run:
hostname:sipviciousdir user$ svn update

Please send me any feedback to sandro@enablesecurity.com and let me know if you found these new options useful.

HARrrr - Hacking at random

noreply@blogger.com (sandro) — Thu, 13 Aug 2009 14:29:00 +0000

It's that time of the year, HAR is with us and lots of hackers and other deviants gather to camp (or simply drink with campers) and attend a couple of events. I put up my list of interesting (for me) presentations / events to visit today at the EnableSecurity blog. From the VoIP side, there doesn't seem to be any talks of interest but there's eventphone.de which offers a SIP and IAX2 interface, and some people (French ;-)) who did get involved into VoIP and Security somehow or another.

Lastly if you're around, send me an email.

How law enforcement sees VoIP

noreply@blogger.com (sandro) — Mon, 27 Jul 2009 07:46:00 +0000

While browsing Wikileaks, I came across a document titled "An Overview of VOIP for Law Enforcement, 23 Dec 2008". It reads as a "VoIP explained" document for law enforcement , explaining the basics and the restrictions that law enforcement agencies have when it comes to VoIP. Here's a summary:

The difference between a traditional phone call and a VoIP phone call is discussed (signals and circuits versus packets)
With VoIP various devices may be used: software (softphones) installed on a pc, VoIP gateways and IP Phones
Discussion of caller id spoofing, how it makes it harder for LE to tell if the call is from a VoIP provider or a real number or not (anonymous calls)
Vishing, the act of phishing by involving VoIP
Actively tracing VoIP calls is almost impossible
911 emergency calls or VoIP E911 is mentioned
There are 4 ways to identify VoIP usage: the Caller ID (which may be spoofed), Phone records (where tracing is similar to tracing the source of email), VoIP hardware (eg. phones connected to ethernet) and VoIP software
CALEA was updated in 2005 to cover VoIP providers so that LE to allow tapping, recording and tracing of phone calls
Due to the international nature of the Internet, if the provider is not US-based, then it does not have to comply with these laws or LE requests