Transfer Files Using TCP... Headers? 72
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?
Re:Similar to old phrack article (Score:2)
Pallet Packets? (Score:1)
What we do is use real wood pallets to encode the information in art sculptures. Then we burn them in a wild party, with drums used to transmit the signals that were in the art to the participants. OK, the packets are kind of big, but most observers will be distracted by the art that they'll never clue in that the painted glyphs on the packets contain actual information.
It's kind of lossy, and you need trucks to transport the pallets, but it makes for a great party. And you can even roast the pidgeons from the other method if you get hungry.
Re:Do NOT moderate this down (Score:1)
So Signal 11 posts a lot. In fact, judging by # of posts and user number, he probably has 5 digit karma. He even proudly proclaims he is the "greatest karma whore of all times"
That DOES NOT give anyone the right to unfairly moderate him down. I happen to read /. because of the good posts and I will not stand to see good posts unfairly modded down. That totally defeats the purpose of /.
I vastly prefer any Signal 11 post to an AC post. The moderator abuse has gotten so bad that now I can't see most of his posts because they are unfairly modded down to 0 or -1.
Please stop.
Covert? (Score:2)
Security through obscurity isn't very good security, and since this has been posted on
A method of encoding data (Score:1)
Is there any security that _isn't_ by obscurity? (Score:2)
What is all the big fuss about U.S. encryption export laws anyway? ROT-13 and XOR should be perfectly good for anyone... =)
--
Did it in X.25 (Score:1)
Agreed (Score:1)
Steanography over usenet porn is clever... this isn't. I can't think of a simpler covert channel in TCP.
Mailtunnel (Score:2)
It's not really a covert channel, but Mailtunnel [detached.net] lets you send IP packets via Internet mail messages, which is an equally twisted way of getting data from A to B.
Better covert channel? (Score:5)
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
Re:Better covert channel? (Score:2)
--
Not just random data (Score:1)
Rather than just encrypting noise, I'd encrypt sensible data, such as a story or maybe even a jpeg of a dog.
... and ISDN (Score:2)
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.
Improving password communications (Score:1)
Re:Well actually (Score:1)
Scheduling it a LOT (Score:2)
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.
--
Re:Pointless (Score:1)
only on one condition: (Score:1)
You need at least one blue mana.
ICMP echo reply / UDP? (Score:1)
What is the big deal?
Re:Okay, but... (Score:4)
Or maybe "Attack Jun 6 44, Normandy".
There is much data that is tiny, but sensitive.
Re:Alternative to security through obscurity (Score:2)
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
that is really funny... (Score:1)
subspace modulation (Score:1)
by modulating sub-space.
Just as geeky
Re:Using fingerd as webserver! Not with netscape. (Score:1)
Re:Pidgeon Packets? (Score:2)
I'd caution anyone against employing this mode of data transport in a production environment. Not only is latency high, but the RFC [faqs.org] still has experimental status:
http://www.faqs.org/rfcs/rfc1149.html [faqs.org]
Even better... (Score:1)
A program to perform this kind of stuff (Score:1)
ICMP for da mass :) (Score:1)
Re:What about Firewalls? (Score:1)
ah...can't seem to find the article, but I do remember it--maybe the two could be combined into the firewall proof version...or I could just be talking out my ass again.
you decide
Re:Pidgeon Packets? (Score:1)
C.
Re:Better covert channel? (Score:1)
- The ICMP Time Exceeded message contains only the IP header and the first 8 octets of the packet, so the transfer will be very inefficient (perhaps not a problem for some applications, but transferring MP3's 8 bytes at a time would get old pretty quickly).
- Some sites already rate-limit ICMP messages to avoid some kinds of DoS attacks, which although it wouldn't prevent this channel, would restrict the bandwidth still further.
I'm not sure if there is any way around these, but the channel would still be useful for low-bandwidth communication.
Other high bandwitdth covert channels (Score:1)
Re:This is a pretty obvious covert channel (Score:1)
Re:subspace modulation (Score:1)
They had to play back the rhythm of some weird alien glockenspiel.
Now _that's_ geeky.
Re:What about Firewalls? (Score:1)
Not really. It depends upon the type of firewall. A full application proxy firewall will do this, but a simple packet filtering firewall will not. Rewriting the TCP packets is a very time consuming process and for performance reasons this may not be acceptible. In fact, the two most popular commerical firewalls, Checkpoint FW-1 and Cisco PIX, are stateful inspection firewalls and don't rewrite the TCP packets.
Related: Chaffing and Winnowing (Score:3)
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.
Man.. I can't belive.. (Score:2)
Similar to old phrack article (Score:2)
Transfer Files using TCP headers... (Score:1)
Okay, but... (Score:1)
SSH trojan had this (Score:4)
In short - this has been going on for a long time.
This is a pretty obvious covert channel (Score:4)
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
Re:This is a pretty obvious covert channel (Score:1)
I have seen some stuff like this. (Score:1)
What about Firewalls? (Score:3)
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?
Pointless (Score:3)
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.
Basically Shows that Security is a Problem (Score:5)
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.Alternative to security through obscurity (Score:5)
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
Define 'file'. (Score:3)
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!
Re:Do NOT moderate this down (Score:1)
Thanks but no thanks.. I have no done that for some time now: what I post is what I *really* *do* *believe*. Please judge me on my content, and not who I am. As part of this, I usually do not use my +2 bonus.. all I ask is that if people do want to moderate that they do so on what I'm saying.. and not who I am.
What would be interesting.... (Score:3)
I'd like to see Metallica try to shut that down.
Re:Alternative to security through obscurity (Score:1)
Use tar to archive up your system, pass the output tar file through gzip or compress. Then encrypt it with tripple DES using a randomly generated key and then forget the key. For better randomness, skip a random number of bytes into the output stream before using. If you want even better randomness, XOR it against another data set. While not perfect, it does generate a huge data set that is hard to predict. Anywhere you can throw in a randomness into the generation method helps improve the output data set. One possibility would be to randomly select files to archive. Randomly you could drop blocks or XOR them with them with the next block. When building a chaff data set like this it's important to lose input information and bring in other randomness as it's built.
For a truely random number generation method see LavaRand [sgi.com].
*Shrug* Not practical (Score:1)
A decent firewall, supports statefull filters. (i.e. Outside connections can only be established if they originated from the inside.) As for Public Web Servers, they should be setup in a DMZ, not on the private side. (Firewall 101)
This method relys on getting a SYN (not SYN/ACK)request in from the outside. With statefull filters, this is most difficult.
As for spoofing IP addresses, a firewall should never allow private address from the outside/public network.
This exploit is only good for a skr1p+ k1dd13 trying to hack into his high school.
Re:Alternative to security through obscurity (Score:1)
Storing Data on the Net (Score:1)
Complete anonymity (Score:1)
other uses...ICMP (Score:2)
IIRC, the Trinoo distributed DoS attack system used ICMP packets to communicate...this is how it got past many detection schemes.
--
Re:In JPEGS! The Description Field! (Score:1)
That's the thing with covert channels. If you don't mind very, very low bit rates, if there are unimportant bits somewhere, you can use them to send information. It doesn't matter one jot what format those bits come in, bits are bits. eg, you could use a series of /. posts to distribute your metallica mp3s. Encrypt your data with a public key, then have a substitution table, a particular value between 0 and 255 -> a particular english word. Then break it into random size chunks, then post it to /. some "hidden" sids. And too reconstruct it, you need to take into account the time and order it was posted, and shove it through some complex algorithim to work out the true order of the chunks. Voila, covert channel, stable for 2 weeks.
How about PPP over DNS? (Score:2)
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...
Re:What about Firewalls? (Score:1)
Other than that, I think the PIX rots.
One sure way to tell you're running nmap against a PIX is that all the sequence numbers are impossible to predict and they're running IIS.
Re:What about Firewalls? (Score:1)
Not having read anything:
ipfilter, common on FreeBSD and OpenBSD has the option of dropping packets with tcp options. See the latest SysAdmin mag for more info. I don't think Linux ipchains has this ability.
Re:Alternative to security through obscurity (Score:2)
A chaotic source would include white noise from radio frequencies carrying no stations.
A random source would be how often I blink while sleeping or how much fluid I drink while sipping my coffee -- these are unpredictable (within their limits).
Well actually (Score:2)
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.
Re:Okay, but... (Score:1)
Pidgeon Packets? (Score:2)
DDoS just a large file (Score:1)
Why bother scheduling it? (Score:4)
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.
Re:Alternative to security through obscurity (Score:1)
Back orifice does something similar... (Score:2)
Re:Alternative to security through obscurity (Score:1)
Right, unless you either care about a delay of more than one transmit-period (eg, day) or that there might be a backlog if you start getting more than your batch size. If this happens, your backlog would just get longer and longer.
I do like the of constant or randomly placed up and download periods, as options, so the user would have a tradeoff of predictability (some would value more predictability, such as needing their daily files by 9am each day, and sending out their batch at 6pm), while others would value the obscurity a randomized schedule would provide.
As far as legality goes, there's also a nice defense in being able to say "The transmission on 9am wasn't anything out of the ordinary. We always transmit a 5 meg file at that time, every day, before we'd ever met Bob" while a randomized schedule might create unfortuante coincidences, "We see that right after your telephone conversation with Bob, you sent off a 5 meg file. Why is that?"
Steady stream may be the way to go, but then again, if you are looking to hide this at all (not that obscurity is useful), a steady stream tends to attract flies more than a periodic burst.
Kevin Fox
Re:This is a pretty obvious covert channel (Score:1)
Re:Do NOT moderate this down (Score:1)