Hiding Packets in VoIP Chat

holy_calamity writes "Two Polish researchers say they have developed a system to hide secret steganographic messages in the packets of a VOIP connection. It exploits the fact that VoIP uses UDP, not TCP; it is designed to tolerate some packets going missing -- so hijacking a few to transmit a hidden message is not a problem." You may also be interested in reading the original paper.

Comments

UDP Only...

[mchawi]

Based on the RFCs for VOIP they are supposed to support UDP and TCP per the new specs. Most companies are moving to support both so you can choose, but some of the large companies are going to TCP because this is what all of the 'Unified Communications' packages go with (such as Microsoft Office/Live/Communicator, etc).

One of the reasons they are leaning this way is security. Go figure.

Besides that, I don't really see the point. What does this solve that just encrypting sensitive data wouldn't?

Re:UDP Only...

[zappepcs]

Well, it might ensure that the NSA et al are not infecting your VoIP equipment with tracing software while you are talking, and those pesky terrorists might not be able to send text data about the next planes to hijack while having a bad conversation quality exchange about prayer times and how to find Mecca while in Chicago.

When a security hole is found, it needs to be plugged because the threats it poses are not always explicitly understood at first glance.

In fact, in computing in general, there are multiple ways to sneak a couple of packets through here and there if you're willing to be patient. I'd mention a few of them, but that would probably get me on a fucked up watch list. The fact remains that this is but one way to do so. Monitoring the network packet for packet won't uncover them all either, nor will it out any terrorists who don't want anyone watching their communications. Why, even my music on hold can contain data for transmission to the right person with the right audio equipment. Never mind a blog post, or email. In fact... woooootttt! I could use the NSA's website as the key for an encryption routine that they would never decode in several decades of trying. sigh, but that won't stop them from telling us that it's all for our protection.

Just encrypting it would not stop the possibility of rogue data if your application can withstand a few missing packets. VoIP is not the only protocol which is susceptible.

Re:Too late

[redxxx]

The first link would not work because they can't just add noise. They would have to inspect and remove packets from the data stream. It works totally differently and would not be applicable.

The second is just looking for out of band communication in data streams. It could be configured to look for it in Voip traffic, but most of it is encrypted. It wouldn't be easy, particularly doing it in something like real time, but not impossible.

Re:VoIP doesn't just use UDP

[profplump]

I know people are still confused by the magic of IPSec, but seriously, UDP over IPSec is a vastly superior way to secure RTP in any situation where packets might be dropped or re-ordered. SSL+TCP+RTP might work on a LAN with lots of bandwidth to spare, but it just doesn't work across the Internet.

I used to have an IPSec bridge to the office, with RTP running over UDP on that bridge. Everything worked great. Now my company has turned off end-user IPSec, and requires use of the Cisco SSL/TCP-based VPN client. I'm now forced to forward all calls to my cell, because phone calls over the new VPN stutter like nobody's business about 40% of the time.

Re:Well...

[h4ck7h3p14n37]

That reminds me of a neat story.

A few years ago at a tech conference I met someone who worked for the data storage division at Dell. Some of the technical manuals that the engineer needed for their work were classified as secret (product hadn't gone to market yet) and the engineer had to sign various NDAs with the company to get access to the documents.

Said engineer compared their copy of a manual with another engineer's copy and discovered that each manual had a different set of spelling errors. Apparently Dell was generating documents with unique sets of typos in order to be able to track down the identify of the person who leaked a document.

Patterns in the noise

[StreetStealth]

It does get one thinking, though... So many things on the internet appear to be governed purely by entropy; how many of them could conceivably be used for steganographic purposes?

Imagine a series of /. accounts set up for bots to automatically comment on stories, with an algorithm somewhere to scrape and concatenate certain characters based on a key consisting of times and offsets...

Come to think of it, there's no reason why this necessarily couldn't be the case with some of the vast volumes of blog comment spam out there. Spread out wide enough and with a resilient enough algorithm, there could be more than enough signal to cover for the noise of spam-killed comments...

Re:Isn't VOIP illegal where data-hiding is needed?

[sunderland56]

You can purchase a Vonage/etc. adapter in the USA, and then plug it in anywhere in the world. This works in a lot of places that VOIP is officially "not available" - exactly where depends on the settings of that country's firewall.

Serial numbers in ARP packets

[karl.auerbach]

There are sometimes other places to hide data:

I can't remember whether it was FTP Software of NetManage, but one of those used to hide the serial number of the software in the bits between the end of broadcast ARP requests and the end of the Ethernet frame.

That way they could check for duplicate license keys on the same net without bothering anybody. Only worked across the broadcast domain, but that was adequate for that purpose.

There's lots of other places too.

RTP packets have optional extension headers that can be used, DNS can hold extra information in parts of the query and response packets - I once encountered someone tunneling music feed via buggered DNS packets. (It became very visible when it caused a Cisco firewall to go haywire.)