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.

On breaking phonecall encryption and publishing fake research

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?

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

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

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

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

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.