Slashdot Mirror
Phony TCP Retransmissions Can Hide Secret Messages
Hugh Pickens writes "New Scientist reports that a team of steganographers at the Institute of Telecommunications in Warsaw, Poland have figured out how to send hidden messages using the internet's transmission control protocol (TCP) using a method that might help people in totalitarian regimes avoid censorship. Web, file transfer, email and peer-to-peer networks all use TCP, which ensures that data packets are received securely by making the sender wait until the receiver returns a 'got it' message. If no such acknowledgment arrives (on average 1 in 1000 packets gets lost or corrupted), the sender's computer sends the packet again in a system known as TCP's retransmission mechanism. The new steganographic system, dubbed retransmission steganography (RSTEG), relies on the sender and receiver using software that deliberately asks for retransmission even when email data packets are received successfully (PDF). 'The receiver intentionally signals that a loss has occurred,' says Wojciech Mazurczyk. 'The sender then retransmits the packet but with some secret data inserted in it.' Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message? As long as the system is not over-used, apparently not, because if a packet is corrupted, the original packet and the retransmitted one will differ from each other anyway, masking the use of RSTEG."
Does it matter if you send the real data or the masking data first, if you're just going to "fail" it and resend with the other data?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?
And, would your bandwidth not also double, if you use this and re-send one secret packet for every 'normal' packet?
Evolution - Est. 4500000000 B.C. Don't piss in the gene pool.
What happens when one of the packets actually gets corrupted?
can this somehow be used to bypass Microsoft's ISA proxy and run torrents through it when p2p is blocked??
You could transmit data over retransmission requests.. One retransmission request within 250 packages counts as a 1.. no retransmissions withing 250 packages counts as a 0. Then add an CRC on that, if the CRC doesn't match, throw it all away and resend your hidden message.
This way you could stream a movie and send your data over the retransmissions, without even writing it down into the tcp stream.
This could however of course be detected, if the government know about the algorithm and searches all TCP streams for it. :-)
If you on top of this add some sort of scramble key, it would be really hard to detect that a transmissions was ongoing.. Except the fact that one user constantly suffers from bad networking
I realize that all forms of steganography are basically security through obscurity, but this one is even more inane. Unless subjected to additional protection, anyone aware of this form of steganography could easily track it, and more importantly, it would look suspicious in traffic logs (drastically increased retrans requests, but only for a small subset of the TCP connections logged). Steganography should look innocuous, in addition to hiding information, if you want it to work.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
How does this get around censorship? The packets, even though retransmitted, is still from a blacklisted IP isn't it?
I suppose it's now critically important to know more about lost vs corrupted statistics. If it's 999/1000 lost, and 1/1000 bit corrupted, then the sudden up-tick in "corrupted" packets could be noticed.
I don't know a lot about the internals of TCP, but can't the sending party re-transmit even without being asked to do so? If so, you have a couple other possible channels for messages. For example, send a packet that says "if I double-send the next packet, take action."
[
For the purpose of this discussion it helps to bear in mind the criminalization of ambiguity. If I have a source of physical randomness and I use this source to write a multi-GB file to my hard drive, when the Mounties show up to repo my computer system (on false allegations under the Canadian DCMA soon to be shoved down our throats), and I'm unable to provide a password which unlocks my monolith of randomness into something with a lot less entropy, I expect I'll be successfully charged with obstruction of justice.
Ignorance of law is no excuse. No one in the legal system has the balls to state this point blank, but it appears as things are shaping up that ambiguity of circumstance is no defense either.
With the packet size of ~1500 bytes a 1MB send means ~700 packets. With an average of 0.1% packets lost even sending a single bit of information (a single 0 or 1) per 1MB transfered gives you a 150% increase in lost packets
With dialup and it's default packet size of ~500 bytes combined with much higher packet loss you might be able to sneak in 1-2 bytes per MB without making it possible at all to detect. Considering 56kbps modem upload speed and need for some error/fault correction in the protocol sending an equivalent of SMS (160 characters) would take more than 2 days.
All that is assuming that someone is looking for that type of transmissions. If not it looks like a very nice method to send very short messages.
Embedding a message in an ICMP (ping) packet is as old as the hills. Sure , you need root privs to send and receive the packet but you'll need the same privs to read the individual TCP control packets in this scenario anyway. Nice idea though but I imagine it could be extended to a number of different protocols.
Deliberately hide the stego resend packets in encrypted Bittorrent traffic. That would make this very hard to detect. Even if the Bittorrent communication was unencrypted, you'd need to figure out which segment of which torrent it's associated with, then calculate the checksum. Since the Bittorrent traffic is encrypted, this makes that much harder. Of course, you could spy on the traffic with your own peer, but the stego could be used to communicate only between known peers, in which case the other peers will never see the stego packets. This would also make traffic analysis much harder.
This is definitely a cool idea, but is readily detectable as others have already pointed out because the transmitted and retransmitted packets will obviously differ, and it is easy for someone to detect such a transmission and recover the steganographic message.
But, if you reverse the roles of sender and receiver, a much harder to detect mechanism can be embedded in the occurrence of each retransmission request. In the simplest scheme (which is easily detectable, so I would not recommend it), Alice wants to send a message to Bob. So, through a pre-arranged mechanism, Bob starts sending Alice a file. As each packet arrives, if Alice sends and ACK, she is sending Bob a 1, if Alice sends a re-transmission request, she is sending Bob a 0. The file being transmitted is acting as a carrier and has nothing to do with the steganographic message, which is encoded in the sequence of ACK / retransmit replies. To make this scheme less easily detectable, most packets will have to be handled normally (not encoding a reverse flow message), and only a relative few will be used to encode steganographic bits. And since TCP/IP is lossy, multi-failure CRC will have to be layered on top.
Put my fist through my alarm clock with its ding-dong death inside my ear. - The Blackjacks.
Doesn't anyone think it might be a bit obvious if your system suddenly starts re-requesting/re-sending a large number of its packets?
That would be an issue if the goal is to hide movie piracy.
If you want to transfer textual descriptions of totalitarian regimes, you do not need a lot of bandwidth.
I lost my sig.
This won't necessarily bypass the great firewall of china, etc..
Really depends on the proxying in place.
-- I'm the root of all that's evil, but you can call me cookie..
Too late. Packet scanners have been examining that since at least 2002. I know, since I wrote one for sale to various TL Agencies.
The receiver could have a website with empty pages pages titled 0.html and 1.html. To send the ascii character 'a', the sender accesses 0.html, 1.html, 0.html five more times, and then 1.html one last time. The receiver would then look in their web server log and see that the letter 'a' was transmitted.
Who modded this offtopic? It is a perfectly good example of stenography in a slashdot post. I'm just having a little trouble deciphering the hidden message.
Last century Poles cracked Enigma
Now TCP...
Covert channels like this are well known and have been part of the common criteria for decades. This is why systems handling classified data are usually physically isolated from others. When data is transferred into the classified system there no ACKs and the wires that would normally carry them aren't connected.
Heh, I can think up a half dozen better stegas:
(1) Encode the data as the packet length.
(2) Encode the data as the packet checksum
(3) Encode the data as the fragment offset.
(4) Encode the data as the number of extra ACKS.
(5) Encode the data as the starting connection sequence number.
(6) Encode the data as the window size.
(7) Encode the data as the inter-packet delay.
Steganography has the fatal flaw that the method has to remain secret. One basic rule of encryption is to assume the method is discernible and
the security must be all in some secret key.
-----"The new steganographic system, dubbed retransmission steganography (RSTEG), relies on the sender and receiver using software that deliberately asks for retransmission even when email data packets are received successfully (PDF). 'The sender then retransmits the packet but with some secret data inserted in it.' Could a careful eavesdropper spot that RSTEG is being used because the first sent packet is different from the one containing the secret message? As long as the system is not over-used, apparently not, because if a packet is corrupted, the original packet and the retransmitted one will differ from each other anyway, masking the use of RSTEG."------
Ok so we're re-tran'ing on packets we claim to be corrupt, but that were received successfully. So by monitoring traffic and keeping careful note of which packet the retransmit is requested on, and seeing what the checksum of that packet was, we will know whether an anomalous request is being sent. Basically the checksum of an uncorrupted packet will be correct, so while not a conclusive test, it's a tip off that something is up (either malicious intent, or a network problem downstream between the monitor and the receiving host causing corruption). Some analysis can also be done at this point to compare the frequency of these with run of the mill retransmits and possibly detect odd behavior. Yes it will be mixed in with noise, but I think with some careful observation a pattern could be recognized.
Some other ways off the top of my head to go about this:
- Remote host intentionally sends a corrupt packet in response first, which is actually some creatively XOR'd version of what was expected but intended to look like typical upstream nonsense. The retransmit, which is now keyed off an actual corrupt packet, sends what should be there. The receiver can then combine the two into a meaningful secret message, while not actually sending retransmit req's for properly assembled packets. IMO this is only really detectable by abnormally high levels of retrans, or something which knows the trick and proactively tries to reassemble the information. Encrypt it and likely it will never appear as anything more than line garbage.
- Since the only thing that must remain constant is the destination (or does it?), why not distribute this. Set it up using a botnet, and since these are very small messages now being spread out across a hundred hosts (or more), the requirements to monitor and detect traffic and then correlate it go up significantly. Will a single slightly "off" packet from a host trigger an alarm? Probably not. Spread out the signal distribution over a bunch of servers to receive the traffic as well and it will probably never be noticed.
might help people in totalitarian regimes avoid censorship
I'm assuming this includes the United States;)
WE'RE HUNGRY
These days, physical link layers seem to be pretty stinking good. How common are TCP retransmits for reasons of corruption?
Why do this at the TCP layer? Why not the application layer? Consider all of the covert channels that might exist with the ability of POST, PUT, and even method=GET.
I've thought off and on about botnets that use spamblogs or google search + zeitgeist queries to coordinate their activities. The web is the largest visible surface area of the internet, so if I wanted to hide something in plain sight, that's one avenue to look into.
My opinions are my own, and do not necessarily represent those of my employer.
[...] using a method that might help people in totalitarian regimes avoid censorship.
Shhh! Don't go BRAGGING about it! Geez, now they'll be on to it and find a way to block it already!
Like encoding the message in whether you request a retransmission of the packet or not.
Every time a new way to beat eavesdropping come out, the only thing mentioned is how we can now beat the censors of totalitarian regimes.
What about its other fun uses? Terrorists sending messages to detonate a bomb (defeating the godless atheist liberal censors trying to read their messages), drug gangs sending messages about who to murder (defeating the overbearing fascist police trying to read their messages), spies sending messages with national or corporate secrets (defeating the evil counter-intel agents), etc.
Are we really so naive that new techniques like this are only going to be used by oppressed do-gooders? Or that we'll agree that they shouldn't be oppressed and suppressed?
if(retransmit_rate > .005) {
beat_with_clubs();
}
... so... wouldn't it be the same just putting your data in the body of an ICMP echo message (ping)?
There is a principle that if there is any means of systems affecting each other, that mechanism can be used to communicate.
Consider classified and unclassified processes in a "secure" operating system, separated by a process boundary, and disjoint credentials (so, they can't see the same resources, like files).
The can communicate because the system has a finite amount of memory and simply requesting memory resources and noting successes and failures can be used to communicate.
It's awfully inefficient, but it can be done.
In Liberty, Rene
Oh, wait...
Imagination is more important than knowledge -Einstien
Sorry but these people werent the first to think of this. Only the first to publicly announce they had. I mean really. I never tried but I had this idea in the late 90s. Others probably thought it up before even I conceived of it. Then again, the layers was probably the biggest snoozefest I ever had to sleep through in class. So maybe it took so long because people kept falling asleep while trying to do it. Oh well better find me a copy of netmon and start sniffin.
And this has been another installament of Captain Obvious!
>As long as the system is not over-used
This assumption only works if nobody uses it. If it's really useful, over-use is inevitable.
Even simpler, but more overhead:
Every few minutes stop sending fake retransmits. This gives you an approximate real noise level.
In the in-between times, send a lot of retransmits for a "1" and a few for a "0."
Encode your message so it's tolerant of multi-bit errors.
You should be able to get a few dozen bits per hour out of this scheme easily, without deliberately making bad packets. That's enough to say "We attack at dawn."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Indeed- You raise a valid point that one could hide secret messages in (especially) posts marked as "Troll"... since the bulk of the readers won't even see them.
Mentioning any sort of xuniL-sv-swodniW argument is guaranteed to get you a Troll rating.
If this gets modded as Troll for that previous statement, then this sort of stego must be in use at slas*SAjkljaw<NO CARRIER>
Evolution - Est. 4500000000 B.C. Don't piss in the gene pool.
...of the implementation of a covert channel public, it's not a covert channel anymore. It would have been much more useful if they would have sold this research to a government or other organization who would use this technology to complete their mission. This https://abegetchell.com/code/covert_smtp_v0.1/covert_smtp.zip is a good idea, but since it has been publicly released (as well as a snort rule to detect this specific implementation), it cannot be counted on in the establishment of a covert channel.
but if they already suspect you, all they have to do is watch your stream and see which retransmit requests correspond to a packet with a perfectly good checksum. Given the .1% error rate quoted, the odds of a false positive are only 1/1 000 000
Internet censorship relies on filtering all packets, retransmitted or not. How does retransmitting a 'failed' packet avoid censorship filters?
Secrecy isn't a bug, it's a feature. For the target audience, if you get caught sending out encrypted messages, you immediately become a suspect. Which, in turn, can lead to a pleasant stay in the local version of Guantanamo until you decide to cough up the key. The object of the game is to prevent the authorities from knowing you've even sent a message. That's the whole point of steganography - if there was no need to hide the fact that a message existed, you wouldn't need steganography at all.
... we should also ban the terroristic device known as the "telephone" (because they can use it to coordinate their actions), the evil "postal service" (because they can send money through it), and the especially horrific "smoke signals" (highly secure because only people within range can see, dontcha know).
Sure, these techniques can help bad guys communicate. That doesn't mean they should be banned.
Do these polish people understand the definition of steganography? If you reveal how you're secretly embedding information in this communication system, then your secret is out and the whole method is useless. This is why you can [should] publish [good] cryptographic systems but you don't go on the web and blare to everyone how you're hidding messages in the TCP/IP protocol. Let's hope those authoritarian censor state's IT people don't read slashdot...
While the approach is obvious, you can do much better, e.g. by using the random initial sequence number to transport a (short) encrypted message. This is practically undetectable and doe not modify any TCP characteristic.
I call this non-nwes...
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I had a bit of a chuckle when I read this. The SciFi author James P Hogan described this technique in his book "Endgame Engima" back in 1987. His technique was not quite as fleshed out, but it didn't need to be for the story.
ISBN 0553051695
Not only do they seemingly not understand cryptography, stenography, or data tracking, they do not understand how much of Asia's network will not let this pass even as it stands now. There is a lot of Asia that runs through SAT links and they use true TCP acceleration which proxies the TCP segments. The retransmission will be pointless here at best. At worst they will screw up the far side connection resulting in a RST.
Also it would be like a little red flag saying "Look at me!" every time it was used. With data tracking equipment that stores terabytes of data for post analysis, it is almost assured to raise some questions. I can only assume that's not the effect they are looking for.
They set out to find a weakness in TCP and only found weakness in themselves. I recommend they pool their resources and buy a cheap book on stenography. Or use encryption.
I think you underestimate just how much I just dont care.
Whoever your peers were, they weren't familiar with best common practices for asymmetric bandwidth border crossings.
We did this in 1996 for the Whistle InterJet, back when the idea was relatively new, but it's now common practice. The problem is that if you have a border router with a relatively fast network inside the border and a slow connection to the Internet, with a faster connection for the router on the other side of the slow connection (e.g. for a DSLAM, for example, then what you're going to end up with is any larger transmission starving interactive traffic (for example, an update download vs. transient mail traffic, or a large file download vs. an ssh session.
The only reasonable way t deal with this situation from a bandwidth management perspective is to manage how full the buffer is on the routers on the other side of the slow connection, and that means banging the window size larger or smaller than it actually is in order to allow bandwidth control. Otherwise, your fast connection packs the router buffers full of data packets for the large transfers, and there's no room for packets not specifically related to the large data transfers, unless your router decides to do RED queueing. And that has its own performance issues (specifically, it increases the effective bandwidth delay product until it's the same as if it had been multiplied by your actual queue size divided by your high watermark at which pint you RED 50% of your incoming packets).
PS: This is why I always laugh at things like AltQ, which try to flow rate limit in order to do traffic shaping, since you can do that, but unless you adjust the window size, you're still going to pack up your router buffers with data unrelated to the flows that you wanted to prefer.
-- Terry
My firewall does random sequence numbers.
It does this to make up for a number of commercial operating systems that *don't* do random initial sequence numbers. Then it rewrites the packets as they go through the TCP stream, including the checksum, on both the way in and the way out.
This is a common method of mitigating "guessable" initial sequence numbers for older systems behind good firewalls.
-- Terry
In other news: Empty envelopes might be used to convey messages! News at 11!
-- Sig down
the people in China have been doing this for years now.
I thought Windows 7 wasn't going to be released until the end of the year.
What's worth the word Kleenex, Xerox or even Fax these days? It's not you and me defining words but everyone around us.
Those who don't understand everything will try to find anything "most like it" to define something they don't fully understand...
That definition is for them the most closest to steganography, which is a quite logical decision for those, knowing, packets normally don't involve secret injects of data...
It's sure not just "a hidden message" either to my definition ... Rstego maybe? ;)
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
This past week I discovered why sites like Digg and Msdn/Technet have been failing to load at all for me for the past 6 months or so: my router's MTU was set to 1500 (default for ethernet), but it was connected to an ADSL modem using PPPoE, so the MTU should have been 1492 (the absolute max for PPPoE) or less.
Since most web pages are over 1.5KB these days, that means fragmentation is a given. And it turns out that if any of the fragmented IP packets are lost, then the entire packet has to be re-transmitted. The link between me and those sites was apparently flaky enough to guarantee at least one fragments would always get lost, so the pages never loaded.
Based on this experience, I think the 1 in 1000 number is an unrealistically low estimate of corruption/packet loss. For the sites I mentioned, it must be closer to 1 in 30.
(p.s. WTF is up with slashdot suddenly discarding blank lines in comments? It's impossible to read text that's totally void of blank lines, so I had to insert periods.)
A pointers to a range of ideas for covert channels in IP networks (which is what the TCP scheme here actually is) can be found at:
http://caia.swin.edu.au/cv/szander/cc/index.html
and an interesting survey paper is:
"A SURVEY OF COVERT CHANNELS AND COUNTERMEASURES IN COMPUTER NETWORK PROTOCOLS"
http://caia.swin.edu.au/cv/szander/publications/szander-ieee-comst07.pdf
... could just mean that the last leg of the route is noisy. Someone monitoring the line should get suspicious if the rate of retransmission varies according to source, but not if it happens all the time.
The recipient software can mask the stego by requesting retransmission at roughly the same rate all the time. Only if the sending software is in on the stego would the retransmission be significant and (hopefully) encrypted.
Great!
Now we need to figure out how to jump-cross to the power circuits then into the house/apartment/building grid and blow the sucker to sticky-bits all over the pavement. Little calling cards from the Indignet Bastards to DHS and TSA Nazi trash.
Obama's Thought Police are going to be masterbating each other 'til dawn on this one.
I do'nt see a big deal with this. I have worked with Cisco on their one of the firewall stacks and today's networking devices are much more stateful and smart to do soemthing like this. Typical devices has a TCP normalizer that maintains a SYN cache and is capable of detecting attacks such as TTL, Duplicates attacks etc.
Imagine someone wrote an anonymising web proxy that used RSA key encryption between server and client. On the client the key generation would be a little slow as it would have to be javascript based, but it'd be worth the wait. And it wouldnt be able to transmit images - but that'd be ok as it'd keep the kiddy-porn accusations away. Now imagine they wrote it in a single PHP file that could be dropped into any existing site with no configuration and no extra javascript imports or other dependencies and contained in such a way that it was easy to style and tweak to fit in with an existing web site's theme. Now its easy for any web site owner in any country to host their own proxy, and blacklisting them would essentially mean blacklisting the entire internet, and no government would be able to keep up or escape international sanctions if they did. The Chinese govt would hate it, the CIA would love to know who wrote it but once it was out there we'd have the internet back.
Does anyone have a working implementation of RSTEG?