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?

Comments

Better covert channel?

[Rei]

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).

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.*? ;) (Metallica presses charges against the Recording Industry Association of America)..

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:Okay, but...

[PD]

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.

SSH trojan had this

[Signal 11]

There was an SSH trojan which was documented on BugTraq about 6 months ago that utilized this technique, as well as several others. It also had the ability to detect and bypass firewalls automatically from the remote site to establish a "reverse" connection with the attacker's proxy.

In short - this has been going on for a long time.

This is a pretty obvious covert channel

[ZZamboni]

This paper describes three techniques to covertly pass information in IP and TCP packets, using the IP identification number and the TCP sequence number. Nothing groundbreaking. The only mildly non-obvious part is the bouncing of packets off a third host, which makes up the third technique. The paper would be reduced to two pages if it were not for all the packet traces (which, in my opinion, do not add much to the explanations) and both the ``user's guide'' and the whole code of the sample program both of which should not be included in the paper, in my opinion.

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

Basically Shows that Security is a Problem

[Christopher B. Brown]

Those interested might want to see A GUIDE TO UNDERSTANDING COVERT CHANNEL ANALYSIS OF TRUSTED SYSTEMS from the NCC.

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

[KFury]

This is a nifty idea, but now that it's on /. it shouldn't be considered secure anymore than stegography is.

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:

• Send and receive the same size file every day at the same time, whether you have info to send or receive or not, so no patterns can be tracked
  
• Make m and n big enough that you don't need to change them (because bumping up from 5 megs to 10 is a sign that you're using more, and this is a piece of information you don't want known)
  

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

Why bother scheduling it?

[torpor]

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.