Researchers have demonstrated a new way to hide secret messages in internet traffic that can elude even vigilant network operators. The process is a network application of steganography, which is the ancient science and art of hiding messages in documents, pictures and other media in a way that can be easily detected by the …
or one of the other books chicken! mentions a transport layer encoding? the diamond age maybe?
Translation to plain english
"The technique has important implications for network security because it can be used by attackers to conceal the leakage of confidential information, the paper warns."
The technique has important implications for p2p traffic, because it will be used by file sharers to keep their p2p networks kicking while the RIAAs of the world have to figure it all out once again.
Raw sockets UDP within TCP stream
To use this type of steganography, you don't have to wait for the retransmission timeout. Just chuck out your packet right after the legitimate packet. It will be discarded at the other end as a duplicate and the stream won't be interrupted. Your channel can even have a complete TCP protocol based on duplicating the sent packets.
I'm not sure that firewalls check for retransmission timeouts, just packet sequences. If the firewall is a little more sophisticated, then a duplicate packet number/sequence with a different or wrong checksum or size could be discarded. That means that the steganographic channel is more difficult to use.
Too late at night
My brain has failed to grasp this one. If I'm running Wireshark, it shows retransmissions, so it seems to me that the technique isn't particularly secret, more relying on the fact that in normal use people wouldn't be comparing the retries with the original. It shouldn't be that difficult to hook up a monitor that held onto packets until it saw the ack, and if it saw a retransmission, it could compare the payload with the original.
This has been around for ages, Oasis
Take a video stream, blend subtle shadings in the shapes of text of secret msg, say but broken apart across 3 to 5 frames or more, then distrubute rest of msg similarly over different parts of the frame througout movie. That was pubic knowledge in 1994, spo0o00o0o00o0oks would have used it before then for sure...
"Where were you while we were getting h1gh."
Paris, cos I could easily secrete a packet in her communication channels.
Surely piracy is dead now the Pirate Bay founders are in jail!
Obvious once someone did it
Hiding patterns in the retransmitting is quite an obvious technique, once someone else mentioned it already :)
I would have expected the timing or time-differentials of sequential re-transmits to be even less conspicuous than changing the chunc on the second sending, but then, what do I know? Not enough to come up with this one, it seems.
However, the ones who use this had better limit the differences between original and re-sent packages to what can be ascribed to one-bit errors, or they are painting on themselfes a nice flashy target for our beloved man-in-the-middle-phormers :)
It can be detected..
Ok, at one level, this is pretty sneaky in that it is hard to detect. However, its not impossible to detect.
All one would have to do is to capture the network traffic from a given site and to then compare any resends against the initial transmitted packet. If the receiving site sends an acknowledged response then you can clear the packet from the cache. If a resent response is set, you can flag it to check the resent package.
Obviously there's more to this design, but it could be part of a corporate firewall or if you have the budget, something larger.
While the paper acknowledges that the more resent network traffic you have the more likelihood that you will be caught. Clearly you can identify this method fairly quickly.
It is detectable, but only if a firewall or network analyzer is looking for this sort of activity and secret data is being sent too rapidly. By dynamically monitoring the number of normally retransmitted packets, the rate of payload packets can be kept low enough to avoid suspicion. Even watching for differing resent data is not necessarily effective: a small percentage of packets are corrupted normally, so regular data will be blocked or clutter log files.
Of course, the secret transmission could be further encrypted to keep it from being understood even if it is detected. For example, xor'ing with the previous packet's data would make logging just the secret data useless.
A trickier use is to hide data in a packet stream between two unwitting systems that just happens to pass through the computers trying to communicate secretly. Neither endpoint notices anything but a slightly higher rate of dropped packets. Not as many computers can use this technique, but there may be fewer or no traffic monitors between them.
This, and steganography in general, is not practical for p2p traffic because it requires a much larger transmission to hide in. At an almost undetectable level, in a 200KBps connection it can transmit secret data at just 180Bps, and this is considered good compared to other steganographic methods. At the highest level they tested - resending 5% of packets - there's a substantial change in network traffic, so it's likely to be noticed, and you cut your bandwidth by a factor of 20. Want to try sharing a DVD at dialup speeds?
I nominate HICCUPS for the Worst Abuse of Acronyms award.
THE CUSTARD IS ON THE MAT
PURPLE PRUNES SPOKE THE QUEEN'S DANISH PROFFER
ALLO ALLO THIS IS NIGHT'AWK CALLING
ALL YOUR BASE ARE BELONG TO US
ALL MY COAT ARE BELONG TO ME
The easier solution...
...a CD ROM or DVD jammed packed with secret-nasty-bad stuff sent in the (paper) mail....
Slower yes, but it avoids the IT watchers......
Personally, I prefer the Post Office.
If this is the only TCP connection consistently re-transmitting it will stand out like a sore thumb.
The whole computer industry is founded on a re-transmission error.
Colossus was built to decode the Lorenz SZ40/42 messages. They'd only worked out how to decode them because the German operator had retransmitted a message and made a typo. They got on to it, since retransmissions were so easy to spot.
This method basically depends on noone knowing that you are using it
So basically security by obscurity (which is actually rather good security - right up to the point where it fails miserably)
But in combination with other methods of encryption, it can be used to add an extra layer of security.
Have anyone wondered whether the edless small variations to the same spam message reportedly being used for the purpose of cheating filters are actually steganographic messages? - Now there's a conspiracy theory for you right there.
Not new.... won't snort pick this up already?
This is so much like the years-old fragrouter technique that it wouldn't surprise me if it tripped snort's detection as is. Otherwise it's just a few trivial tweaks to the rules I'd guess.
Back in the real world?
Where are the examples of real use of steganography?
I've been warned of this one, of payloads on ICMP frames, of packing bits... but I never heard of decent, attested examples of their use by a genuine hostile. It's all very well to say "that just shows how effective it is" -- someone must have got caught, somewhere.
It's like spyware that is aware of proxy settings -- it seems reasonable, it ought to exist,
but you never come across it.
Wow. Win awards!
"....then a duplicate packet number/sequence with a different or wrong checksum or size could be discarded...."
Very clever. Now, for the case of a "real" packet retransmission, think of some of the possible reasons for said retransmission..........oops.
And I thought one could be sneaky by creating a variant of live Linux and hide the messages within a number of picture folders marked say Desktop real estate or some other innocuous name within the ISO itself so that when you boot it up it behaves like a normal like Knoppix or the even more common M$ Windows such as 98SE XXXXXXX variant but however if you decompress the ISO there they be run a picture extracting key text thus .
For after all what spy organization will bother downloading a p2p torrent for computer software they already have any way ?
RE: Obvious once someone did it
You are surely right. The job of security researchers is not to provide a new tool for "bad guys" or someone in need of hiding information as is this case, because most likely they have all the tools they need already.
It is to help improving security tools by pointing out where they may fall short. In this case the tools that potentially need improvements are IDS (or other TCP scanners and analyzers). If your IDS vendor was not aware of this technique, you might not have the right tool to detect it.
Much simpler way to hide small amounts of data...
Steganographic hiding is important, but the key to getting something past someone else is to make them not want to look at it in the process.
So if you setghide your data onto one or more images flogging dick enlargement drugs, you can send that stream to all the email addresses of the bloke that's supposed to be watching you. If any get through the spam filters, they're pretty much certain to be discarded without analysis...
> Wojciech Mazurczyk, Miłosz Smolarczyk, and Krzysztof Szczypiorski
Now from that muddle of letters find the real names of the cryptographic hackers!
Why wouldn't i just encrypt the data i wanted to secretly send and send that in normal packets? Why bother with stenography, what advantage does it offer me as someone trying to get data out of an organisation to elsewhere?
It's already defeated.
I hear that Waqui "on the fiddle" Jaqui is going to ban TCP, as it can be used by terrorists. Anyone caught, or suspected, or just a possibilty you may one day think of using it, will be thrown in prison for 10 years.
So were all safe from terrorists now.
No Joke icon, no joke.
What a load of turd.
"Researchers have demonstrated a new way to hide secret messages in internet traffic that can elude even vigilant network operators."
Maybe vigilant network operators who are sat manually watching packets. It wont cut it with firewalls very well though.
When a re-sent packet comes along with a completely different CRC from the first then it's quite obvious that something dodgy is up, particularly if it happens repeatedly. Any good firewall can deal with this. This "attack" is thus extremely trivial to prevent and is not even computationally expensive to deal with. It also relies on the idea that someone has a system within an organisation on which they have root access so their application can make use of raw sockets. It also assumes you have a system on the outside willing to drop the acknowledgement packets correctly too.
If you had that access you could probably just burn the data to DVD or memory stick or whatever instead. Even if physical security prevents that you'd have more success in just used obfuscated, encrypted datastream embedded into an allowed protocol such as HTTP sending to a customised HTTP server or simple web application on said server to accept that traffic and store it.
But really, again when dealing with a good firewall, I don't see what this achieves, you might as well just send the data you're trying to get out in the first place - it's not like the firewall is going to log and handle just the dropped packets and not the resends.
Really, is this all it takes to be a security researcher now? The only reason this hasn't been "discovered" before is because it's so utterly flawed and anyone with half a clue will see it's not worth "discovering" because it's both easily defeated and brings nothing to the proverbial security table.
I give this article and the paper an S, for Severe Fail.
Just PGP the info and append it to a JPeG file.
Anyone looking at the message sees only a JPeG.
The intended recipient knows better, chops the JPeG from the start of the file, decrypts and ... presto, they've got your info.
It's advantages are that it hides the fact that any data is being sent as well as encrypting the data so that no-one else can read it.
If the government were to catch on, you claim that you downloaded the picture from the internet and didn't tamper with it in any way at all. Plausible deniability.
This is the method I would use to smuggle sensitive information out of the company. Obviously, if JPeGs aren't allowed in our out then you zip it up as well...
the difference between stenography and encryption, is that with encryption you know that an encoded message has been sent, you might be able to pin down the source and destination, even though you don't know the contents.
the idea behind stenography is to hide that a secret message has even been sent, this generally means hiding your secret message inside an entrirely benign message, as completely concealing that a message has been sent is difficult.
if an encrytpted message is detected people will be looking for you, with a stenographic message, the idea is that it's not detected at all.
How is this a "new security concern"?
If someone is able to send packets out of your network they can leak data, full stop, end of . This is just one of many techniques for doing it. Either you let the wrong person access data, in which case there is nothing you can do anyhow (they have their eyes and ears after all), or you are letting an unauthorised person transmit data -- so you failed anyhow.
Same goes for malware on single-user systems -- if you let a program create or touch packets then your client side security (AV, firewall, ...) has failed already.
Either way -- you've more to worry about than just one stego method.
May already be defeated
I think some firewalls already deal with this e.g. from Checkpoint SmartDefense youy would get the message "Retransmitted data does not match original data".
This method might also be a bit obvious, whereas data injected into a video stream or into multiple picture files is considerably less conspicuous.
There are more interesting algorithms out there
Any noisy channel can be used for stego. There's nothing in particular that makes this idea stand out as interesting. As pointed out by several posters, this is quite easy to detect, particularly if the parties try to get a lot of bandwidth from the channel by giving up any attempt to make the retransmitted packet look like a slightly-mangled version of the original (or vice-versa). Anyone suggesting using this for bittorrent traffic obviously has no idea about how bandwitdh-limited subliminal channels have to be.
A more interesting system, IMO, is Rivest's chaffing/winnowing system:
The chaffing/winnowing system could be used on top of any communications channel, so it would be easy to implement on top of the retransmission system. Both parties would have to have to have to be running a synchronised message authentication algorithm (either a secret algorithm, or a known algorithm seeded with a shared secret key or nonce) so they can flag a retransmission as containing stego data at one end, and recognise it as such at the other. This would make the system more robust in the face of genuine transmission errors, but as noted with the basic system, you're still generating more noise than would be normal, which will betray your use of the channel to transmit more information.
Yet another option would be to encode your message as a function of the data actually being transmitted. If you're uploading a web page, you could build, say, a Huffman tree or markov model based on the word or character frequencies in the document. Your message could then be encoded in a compressed form by using shorter codes for any word appearing in the document. You could then send an unsolicited retransmission containing your message that's been compressed relative to the main stream and an authentication code to show that the retransmission contains a subliminal message. Throwing in a few more "chaff" retransmissions (which would fail the message authentication code) makes the job of analysing the substance of the subliminal channel more difficult. This is a bit more interesting (again, IMHO) and should use less retransmissed packets than the schemes described in the article, but it's still of fairly limited use..
@What a load of turd.
> When a re-sent packet comes along with a completely different CRC from the first then it's
> quite obvious that something dodgy is up
It's trivial to create a new packet with the same CRC as the original.. the CRC is simply the remainder in a polynomial division (in GF_2), so a small bit of linear maths is all that's required to calculate a constant term to add to your new packet so that it has the same CRC as the original.
@May already be defeated:
> I think some firewalls already deal with this e.g. from Checkpoint SmartDefense
> you would get the message "Retransmitted data does not match original data".
It really depends on where Mallory is situated. If she's doing egress filtering on your connection to make sure that you're not sending secret messages, then it's a valid point. Packets with transmission errors are, by definition, going to have different contents in general, though. If Mallory is close to you, then she has a better chance of detecting that the error rate on your transmission link is higher than it should be... Someone eavesdropping at the far end has slightly less chance of determining this because each node the packet passes through has a cumulative chance of inserting an error. With the internetworks being quite reliable, and getting more so, though, using error packets becomes more detectable, no matter where Mallory is situated.
Already been done
There was a much simpler version out some years ago, filling the padding of ICMP echo packets (pings) with data. So simple, assuming ICMP is allowed through of course :-)
Anyway, this isn't really steg - its more of a covert channel.
I'll try and have a look at it all the same.
Isn't SSL meant to prevent looking at the data from the server to the client EVEN WHEN YOU INTERCEPT the traffic?
What would the point of stenography be if the connection is encrypted, anyway?
If the firewall prohibits SSL traffic, then it will not be worth your time to use the network to get the information in/out anyway - use SneakerNet(tm)!
- Review Apple iPhone 6: Looking good, slim. How about... oh, your battery died
- Review + Vid Apple iPhone 6 Plus: What a waste of gorgeous pixel density
- +Comment EMC, HP blockbuster 'merger' shocker comes a cropper
- Moon landing was real and WE CAN PROVE IT, says Nvidia
- 46% of iThings slurp iOS 8: What part of this batt-draining update didn't you like?