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?
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
Or you could just run your torrents over an unblocked port, with protocol encryption... Nah, I'm sure reducing your bandwidth by multiple orders of magnitude is the way to go...
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
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.
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.
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?
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 a deeply censored regime, there are no unblocked ports, and all traffic which looks encrypted is blocked, and perhaps illegal.