Wednesday, February 3, 2010

RTP Traffic to

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 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 ( 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 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:

Via: SIP/2.0/UDP;branch=ca4b60ae7ba821fREPLACEDjrgrg;rport
From: <sip:sip@>;tag=Za4b60aeREPLACED
To: <>
Contact: <sip:sip@>
Call-ID: 213948958-00227506489-384748@
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Supported: replaces
Content-Type: application/sdp
Content-Length: 503

o=sip 2147483647 1 IN IP4
c=IN IP4
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 - - - -

So what does this mean? According to the article, almost 60% of the traffic being sent to consists of these RTP streams. The majority of the traffic is sent to 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.

Monday, February 1, 2010

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 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: