Slashdot Mirror
Transfer Files Using TCP... Headers?
cloudmaster sent us something pretty sweet: a document describing how to send files byte by byte using TCP headers. Pretty crazy covert channel if I've ever seen one. Anyone see any other clever ones lately?
Just read the article, and the stego reference reminded me of another paper on the Peacefire site. Another good read for ideas on covert internet activity.
How could this be covert if everyone knows about it? If your sniffing the line, your going to be getting all the data anyway, and if you know about this technique, then you can read the information. Not exactly ultra-l33t stuff here.
/. it isn't even obscure anymore.
Security through obscurity isn't very good security, and since this has been posted on
ReadThe ReflectionEngine, a cyberpunk style n
What is all the big fuss about U.S. encryption export laws anyway? ROT-13 and XOR should be perfectly good for anyone... =)
--
--
fat lenny's gonna lick your brain today.
It's not really a covert channel, but Mailtunnel lets you send IP packets via Internet mail messages, which is an equally twisted way of getting data from A to B.
-- Ed Avis ed@membled.com
I'd like feedback on this idea of mine for passing covert information. I've gotten it down to packets that seem to come from anywhere on the net, going to the proper subnet but not the specific computer (Oh, but I am still trying to come up with a way to get them to have the destination of an arbitrary location... maybee in a few weeks I'll have come up with something).
;) (Metallica presses charges against the Recording Industry Association of America)..
;)
Ok, here's how it goes: Using raw sockets, you can write your own IP headers. First, you pick your subnet you wish the packet to come from. You determine how far away it is, in hops. Then, you set the packet timeout time to 1 less than that. You then make the packet's source IP be the address of the subnet you wish to send to, but an incorrect node on that subnet, and its destination address the subnet you want the packet to appear to come from.
Now, on the end of the net which you're faking as the source, the packet will timeout and it will send a timeout response (much in the same way traceroute works). This includes the original packet. This packet gets forwarded to what it thinks is the original address, which is actually a fake node on your destination net.
When it gets to the destination net, the receiving end is in promiscuous mode, that is, it picks up all packets. It filters them out for some "code" information, perhaps using a public key encryption scheme to hide the source address and some checksum data so it'll know that it is something it should pick up, and where it came from.
The only complication that I've come up with so far for this scheme is smart firewalls, that is, ones that check the source IP to make sure its possible before sending it on. You can't expect anything like that from a net backbone, or even a large ISP, but perhaps on a local network; thus, if this method is used, other methods (such as simply faking the source address as being from another node on your current subnet, and sending straight to a fake node on your destination subnet) should be used. Another risk is that firewalls get smart to this, and the person's destination firewall learns to block return packets when they're coming too frequently, but thats just a bottleneck.
.. Of course, if both options did exist, noone would be the wiser as to whether that was truly your subnet, or whether it was a completely fake one. Anyone want to have music being pirated from 208.225.90.*?
Please send me feedback on this idea. I may be implementing it soon. Too bad it needs root access for raw sockets/promiscuous mode
- Rei
Son, a woman is a lot like a refrigerator. They're six feet tall, 300 pounds... they make ice... umm...
ISDN has a similar feature (not very surprising - ISDN borrows some concepts from X25), and I heard that some people actually used this loophole to transfer files. (Remember, this is Europe, where you have to pay for local calls.)
Of course, it takes a long time to transfer a file this way. Each packet can hold only a few bytes.
Finally, the local phone company answered by charging a small call setup charge for ISDN to ISDN communications.
WWTTD?
When I read this I wondered if you might not build it into a network protocol, something like token ring except with tokens of constant size. Sometimes they'd have noise, sometimes they'd have data, but the tokens would show up every second (or whatever) and every single one would be 10 MB (or whatever) so no one would be able to gain any information by looking at the size or frequency.
:)
Disclaimer: I'ts now 3 AM and I'm typing this is my sleep, so I haven't thought the idea through. So don't flame me if it's a dumb idea.
--
Someone you trust is one of us.
How many packets does it take to transmit the message "Boss' credit number 1234 5678 9012 3456 11/00".
Or maybe "Attack Jun 6 44, Normandy".
There is much data that is tiny, but sensitive.
If tits were wings it'd be flying around.
Its a method to help you get toward security, not security in itself (blah, blah).
... ;-).
...
At any rate, the best method, along the lines you mention, would be to covertly hitch the data along existing data streams, not create new ones. This is much more difficult, but a better approach to hiding your data. You would want to hide your encrypted data in a packet of a given type and figure out some way to get it from A to B while looking just like other packets already taking that route that you have not "manufactured".
Doing this would probably be near impossible (without source-routing, which is disabled on many hosts now) but could be simulated with a next generation of anonymous remailers; ISPs that bounce individual packets at a given frequency only (very low) and send them along to where they need to go. This way, each piece of the message would take a different route, each piece would be sent in the wrong order, and be reassembled (sounds like a really bad TCP connection
The problem with your idea is that it would be relatively easy to identify the true encrypted data unless your random number source is sufficient to produce 5M per day of random bits. It probably won't, so you'll end up with a patterned 5M per day, with a more chaotic bit in it some days (the encrypted traffic).
I would be tempted to use TCP fragments, small IPX packets containing the encrypted data sent over a UDP encoded stream, etc. to send small amounts of a message over the process of a few days or weeks. This would spread it out so much that it would be much harder to trace, especially if out of order.
Its not an ideal system for actual messages, but quite interesting as a method for key exchange
- Michael T. Babcock (Yes, I blog)
I'd caution anyone against employing this mode of data transport in a production environment. Not only is latency high, but the RFC still has experimental status:
http://www.faqs.org/rfcs/rfc1149.html
Remember, people, this is steganography, not encryption (Ok, there are some encryption aspects, too). Don't complain that it's not secure to eavesdroppers - its purpose is to obfuscate data, not make them unreadable.
...people want their pirated Metalica songs that badly...
DrLunch.com The site that tells you what's for lunch!
A phrack article a few years ago had a cool idea of sending data in the payload field of ICMP packets. Not sure if this was covered in the article, but the phrack article was cool reading.
In short - this has been going on for a long time.
You can tell by now that I did not like this paper very much. The covert channels described are all quite obvious. The one thing I liked was that the author actually implemented his technique. I think this is interesting because there are not many covert-channel implementations out there.
I see this paper more as an example of simple covert channels, used to explain what covert channels are about, than as a research paper in the area.
--ZZamboni
The article mentioned that there exists firewalls that do not prevent this sort of thing, but it didn't mention whether there are firewalls that do prevent this sort of thing.
It seems that any network that woud require you to utilize a covert channel like TCP headers will have a firewall. If it doesn't have a firewall then using any normal protocol will be just as "covert" as using TCP headers since there won't be anything that can monitor the data coming in or out of network.
So if we assume that a firewall is in place, how much of the article still applies? I think any firewall that is worth anything will rewrite all TCP packets that pass through it. Also, a decent firewall should ensure that all return address's are in fact valid, so the spoof method would not work.
Basically, it seems like this method will only work on networks that contain poorly written firewalls or on networks that don't have a firewall. Am I correct with these statements?
Sig goes here
This document is incredibly long and draw out, and yet it can be paraphrased down to "you can hide small bit's of data in a TCP/IP header". The document is full of minor technical errors (ascii values in the range 0-255, nah! Just call it an octet).
If you really want to go about hiding a data communications channel try encoding it icmp packets (A ping can be up to almost 64k filled with whatever you like), or maybe additional http headers. Going to all this effort for a hidden comms channel seems almost deranged.
Identified channels include:
- Space exhaustion
- Unmounting of busy system channels
- Contention for devices like printers
- Timing of processes
The notion that TCP winds up transmitting some "header" info that doesn't always get recomputed presents an obvious instance of this; it is only covert to those that don't properly understand TCP/IP.If you're not part of the solution, you're part of the precipitate.
If you want a secure way to transmit data from point A to point B without letting anybody know the size, contents, frequency, or destination of the transfer, I would suggest the following:
An intermediary (ZeroKnowledge, or datahaven of your choice) could be set up such that every day as a specific time, it mails you an encrypted file of size n (Say 5 megs) and you mail it an encrypted file of size m (again, say 5 megs). This is automated (with a 'dispatch program' on the client side), and most days the files just encrypt noise.
Now say that you, Alice, want to send a file to your friend, Bob. You encrypt it with Bob's public key, and put it in your dispatch queue (a program supplied by the data haven) along with Bob's identifier.
The next time your dispatch program is supposed to send something out, it looks in the queue, finds Bob's package, appends it with an EOF and enough noise to reach size m (5 megs), encrypts that with the data haven's public key (either a regular key, or preferably a freshly exchanged key), and sends it on to the DH.
Once there, it's decoded, revealing Bob's package, and the address to send it to. This now goes into Bob's inbound queue at the data haven, so the next time Bob's dispatch program connects at it's regular time, the file is gathered with whatever other files Bob has received and is encrypted (with the appended noise, for size constancy) and sent down to Bob's folder, where it is decrypted, and the individual packages are decrypted as well (automatically or as desired).
The keys here are that you:
This way outsiders can't tell how much data you're actually sending or receiving, who you're sending it to, who you're receiving it from, how frequently you're sending or receiving data, or whether you're actually getting or sending anything at all (you could sign up just to thwart prying eyes, and never send anything through but the default noise file).
Further, if the data haven is compromised at a given point in time, they would have the packages A was sending to B, which were already encrypted with B's key, so not even the data haven knows what's inside. Depending on how the DH is run, you may or may not be able to tell where the package came from (that info could be hidden inside the package before sent), or any history info of transactions (preferably no record be kept, obviously).
Of course, for the paranoid, you can nest data-havens (send to bob@datahaven2@datahaven1, etc) or chain them yourself with ghost users (send to bob@datahaven2@bobsfakeaccount@datahaven1).
Basically, it'll be like the post office: You send out one batch a day (or week, or hour, whatever) and you get one batch back, no more, no less, and data analysis by activity pattern is thwarted, and obscurity doesn't play a breakable part of the data pipeline.
Kevin Fox
Kevin Fox
Most peoples /etc/passwd or /etc/httpd/httpd.conf wouldn't take very long to transfer this way...
;)
I like the idea of spoofing packets out to the net with retaddr set to target. That's pretty damned interesting, actually... the more I think about it, the more fun it is!
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
Would be a version of a distributed file sharing client (like Gnutella) that uses covert channel #3 (bouncing forged packets off a third party host) to anonymize the server.
I'd like to see Metallica try to shut that down.
NO CARRIER
In a related thing,
IIRC, the Trinoo distributed DoS attack system used ICMP packets to communicate...this is how it got past many detection schemes.
--
This one has actually been done just to prove it's possible.
I learned of it in an Interop tutorial back a number of years ago - either David Clark or Marshall Rose mentioned it in passing. Intrigued, I pawed through the RFCs long enough to satisfy myself that although it was weird, and would require an accomplice on the inside, it was possible, and would simply fly through pretty much any firewall that allowed DNS resolution of external IP addresses.
I don't know if anyone has ever publicly used or distributed this method.
The basic problem is that pretty much anything that goes through can be used to tunnel almost anything else if you want to do it badly enough...
"The future's good and the present is nothing to sneeze at." - Roblimo's last
Encrypted data transmitted in TCP headers is, as far as I can tell, impossible to detect. You can even spoof a bunch of packets out to the network with the return address set to your target and the network will merrily bounce the packets to their destination. Cool stuff.
Only problem is it'd take a long time to transfer a file like this.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Pesonally I think packets are best transferred by homing peidgeons. Only really applies to pings though. Huge packet loss when it's hunting season.
Just keep sending it out, constantly.
Otherwise you give investigators a clue as to when messages were sent in the *real* world - this can be important when creating an evidence trail for conviction. Being able to say that "the dummy packets sent out between X and Y dates contained the secret info" is one step closer to having evidence - so throw out the time factor and it reduces the investigative trail as well.
Also, a scheduled send permits calculated intercepts. If you're going to all this trouble to fight a war on your own rights to private communication, there is no point giving your enemy any information at all - and a simple "dummy messages goes out at 5pm" gives the opportunity for other tactics.
If you're worried about bandwidth, then just do random sends/receives of the dummy data, albeit on a more persistent basis.
; -- the corruption of government starts with its secrets. a truly free people keep no secrets. --
I believe that one of the communication protocols used in back orifice 2000 www.bo2k.com involves sending information in ICMP echo request and responses. There is a limited amount of optional information that you can include in the IP header of any such packet (ICMP or otherwise) that you can use for such a purpose. -kozubik