![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
This afternoon, I made a major breakthrough in a project I've been working on since November: I found and eliminated a major bug in my code that's been bugging me for two months.
To explain the project, I'll provide a little background.
The background
At Black Hat 2003 (a computer security conference), Simple Nomad presented a program he whipped together called nCovert. nCovert can run in client or server mode. If you give the client an input file, it can send the contents of that input file to a remote machine running the code in server mode.
That's boring.
What's interesting about nCovert is that the data it sends is entirely embedded in the TCP sequence field of the TCP packet header.
That's mildly amusing.
Amusing, but somewhat trivial, from a security perspective, for the following reasons:
1) The data's sent from a single source IP, to a specific destination IP, which must be the receiving host (unless that host is on a non-switched network -- a rarity these days). That means it's easy to identify the traffic stream if you're looking for it.
2) The datastream is TCP-based, which means it's stateful. It's trivial to kill a TCP session from a firewall.
3) The datastream has a "fingerprint"; that is, it's fairly easy to pick out the packets hiding the data from other traffic. I.e., the hidden data is fairly obvious.
Simple Nomad and I talked about these and other issues at the end of his presentation, and it got me to thinking about how something like this could work, and work well.
The Project
So, while sitting at Arecibo National Observatory in November, at 3am, listening to the galaxy whiz past, I started working on what I call Sifr's Obfuscator, or SOB for short.
SOB fixes all the problems with nCovert, and adds several unique twists. It performs the same basic function -- it hides a data stream -- but it does so in a much more sophisticated manner.
First, SOB uses UDP, not TCP, so there is no stateful connection to monitor and stop.
Second, SOB sends every packet from a separate source IP; there is no single source IP to block. The packets seem to come from everywhere.
Third, SOB can send the traffic to a broadcast IP. Technically, this could be done with nCovert as well, but TCP packets sent to a broadcast IP are extremely odd, and easy to spot as anomalous. UDP packets sent to broadcast addresses are common.
Fourth, SOB intentionally generates a random number of "noise" packets in between each packet containing hidden data. These noise packets are indistinguishable from the packets containing the data, and thus it's impossible for an outside observer to know which packets contain data, and which don't.
Fifth, SOB uses an IP header field (IP_ID) to hide the data, rather than a TCP header. This is less likely to be monitored by firewalls and IDSes.
Sixth, SOB implements what amounts to packet sequencing in the UDP protocol (this is necessary to obtain the data from a series of packets that come from random source IPs).
There are some other niceties built into SOB, such as a general purpose packet sniffer, the ability to specify a source and/or destination port to facilitate passing the data through firewalls (e.g., using port 53), and so forth.
This is purely a proof-of-concept (written in C) to demonstrate various weaknesses in current security methods, and to further the field of research into covert channel communications on the Internet. I'll be submitting it to be presented at Black Hat 2004 shortly, at which point the code will be released.
Just thought people here might be interested in the things that I do to entertain myself in my free time.
To explain the project, I'll provide a little background.
The background
At Black Hat 2003 (a computer security conference), Simple Nomad presented a program he whipped together called nCovert. nCovert can run in client or server mode. If you give the client an input file, it can send the contents of that input file to a remote machine running the code in server mode.
That's boring.
What's interesting about nCovert is that the data it sends is entirely embedded in the TCP sequence field of the TCP packet header.
That's mildly amusing.
Amusing, but somewhat trivial, from a security perspective, for the following reasons:
1) The data's sent from a single source IP, to a specific destination IP, which must be the receiving host (unless that host is on a non-switched network -- a rarity these days). That means it's easy to identify the traffic stream if you're looking for it.
2) The datastream is TCP-based, which means it's stateful. It's trivial to kill a TCP session from a firewall.
3) The datastream has a "fingerprint"; that is, it's fairly easy to pick out the packets hiding the data from other traffic. I.e., the hidden data is fairly obvious.
Simple Nomad and I talked about these and other issues at the end of his presentation, and it got me to thinking about how something like this could work, and work well.
The Project
So, while sitting at Arecibo National Observatory in November, at 3am, listening to the galaxy whiz past, I started working on what I call Sifr's Obfuscator, or SOB for short.
SOB fixes all the problems with nCovert, and adds several unique twists. It performs the same basic function -- it hides a data stream -- but it does so in a much more sophisticated manner.
First, SOB uses UDP, not TCP, so there is no stateful connection to monitor and stop.
Second, SOB sends every packet from a separate source IP; there is no single source IP to block. The packets seem to come from everywhere.
Third, SOB can send the traffic to a broadcast IP. Technically, this could be done with nCovert as well, but TCP packets sent to a broadcast IP are extremely odd, and easy to spot as anomalous. UDP packets sent to broadcast addresses are common.
Fourth, SOB intentionally generates a random number of "noise" packets in between each packet containing hidden data. These noise packets are indistinguishable from the packets containing the data, and thus it's impossible for an outside observer to know which packets contain data, and which don't.
Fifth, SOB uses an IP header field (IP_ID) to hide the data, rather than a TCP header. This is less likely to be monitored by firewalls and IDSes.
Sixth, SOB implements what amounts to packet sequencing in the UDP protocol (this is necessary to obtain the data from a series of packets that come from random source IPs).
There are some other niceties built into SOB, such as a general purpose packet sniffer, the ability to specify a source and/or destination port to facilitate passing the data through firewalls (e.g., using port 53), and so forth.
This is purely a proof-of-concept (written in C) to demonstrate various weaknesses in current security methods, and to further the field of research into covert channel communications on the Internet. I'll be submitting it to be presented at Black Hat 2004 shortly, at which point the code will be released.
Just thought people here might be interested in the things that I do to entertain myself in my free time.
