Typically at home I have this stack of papers and junk printed out that I want to flip through and read. Kinda like bookmarking something later, only in the analog world. Lately, I happen to hit a glut of papers talking about covert channels (I’ll link one or two if I still happen to have them around), which are always fun to look at. I then see the focus on ids list has a current discussion on detecting covert channels (really detecting encrypted channels which, as Ron Gula recently contributed, are a separate issue).
Covert channels are fun. They can be an easy way to break something, or use something for a purpose not intended by the creators. The old school version of “hacking” (which I subscribe to) tends to love this definition. They are also difficult and technical in some cases, thus I really believe that unless a firewall or proxy incidentally is blocking the channel, no one really blocks or watches these channels. If I ever get my home network more rounded out and the major projects done, playing with covert channels is something I’d love to tinker with. (And if I would do it, so would lots of other bored kiddies on the Help Desks at their jobs!)
[As an aside, I pick on the poor kiddies on the Help Desk or Tech Support or Customer Service desks a lot. I do so for good reason, though. Typically they can hold some very technically savvy people who have some level of access above normal users. They tend to not be in heavily taxing jobs and sometimes have “leisure” time at work to do some odd things. And let’s not even think about those overnighters with even more time on their hands… Really, it’s not that I distrust them, but I remember my days down there and what I would get my fingers into, and I know it happens.]
For instance, you can stuff information into a few non-used or little-used sections of ICMP packets and shoot them out to your target. But if a company is stopping all ICMP, that incidentally stops that particular covert channel. Someone can siphon away information using DNS, but if you only allow DNS traffic to servers you control…
Stopping (or using to your benefit) covert channels is much more difficult since it requires some pretty specific knowledge of TCP/IP and perhaps packet structure and creation. This probably makes the risk of someone leveraging this attack much smaller, which also may mean it is just not worth spending time combating for many companies.
But lets say you want to detect and/or stop covert channels? I won’t get into specifics since I’ve not done this myself, but here are some approaches I would take.
First, make sure a solid egress configuration on border firewalls are present. If this isn’t done, really, any other steps are simply academic and not going to add any security or sense of security. If you’re not stopping arbitrary ports from connecting to other arbitrary ports on the Internet… Likewise, there is no reason to tackle ICMP covert channel detection if ICMP is blocked anyway.
Second, you need to be monitoring for anomalous traffic. A sudden spike in ICMP or other weird traffic that is not normal could indicate a covert channel in use. Again, the chances are slim, but any network monitoring strategy should already be tracking anomalous traffic loads anyway. You might also want to detect for regular traffic patterns such as an HTTP request that occurs exactly every 3 seconds for hours, or something to that effect. You might see more false positives with things like Weatherbug or Firefox doing regular checks or IM keepalives, but if your company is tackling covert channels, likely they have stringent software and IP rules in place already to limit such noise.
Third, make sure packets are inspected for erroneous settings and flags. Kinda like no TCP packet has any business having both SYN and RST (I think) flags set, there is just some information that, if present, should be investigated.
Fourth, proxy all web traffic in a way that the proxy rebuilds the packets. This should take care of really funky HTTP covert channels and also allow you more logging on what is likely the busiest and least securable port on your network.
Lastly, I really don’t know what to do about steganography or hiding data inside other application layer data. I guess we have to hope that packet inspection firewalls eventually detect the normal tools and their signature/patterns, but I really wouldn’t book my paycheck on that. Image-based stego is still a technical skill, but the tools have gotten far easier to implement and there are tons of locations on the webs to drop images for offsite pick-up.
Speaking of covert channels, I can’t find the actual story, but I swear the Security Monkey had a post one time (I think a reader-submitted story) about someone hiding porn images inside a normal movie file, where a porn image would be one frame somewhere that could be extracted. Screen grab of sensitive docs instead?
When I took the Information Security class at Mississippi State, I wrote a HTTP covert channel for the final project/paper. The idea was to encode the data you’re trying to smuggle out of an organization into a series of GETs or PUTs of meaningful URLs. Assuming that the recipient owns or has access to the logs of the web server being visited (remember that there are a lot of web servers out there that have access logs in publicly readable directories), the information can be pulled out of the logs.
You can reduce the “obviousness” of this by making it look more like normal web traffic, possibly by using a server with a large number of interconnected pages. Encoding data into parameters for something highly interactive and repetitive like a web-based game would likely work well too. Chances are, though, that the web traffic wouldn’t be closely examined anyways.
In my paper, I tried to put the value of data being smuggled out of an organization in terms of a ratio: value-to-attacker/size. There are cases where a large amount of data (scanned PDFs of an employee manual maybe) has a certain value, whereas a small amount of data (say, a sentence explaining why the stock value is going to plummet in the next week) has a very high value to an attacker. The attacker can control another ratio: size-of-carrier-data/size-of-smuggled-data .
The (probably unsolvable) problem here is that for small amounts of high value data hidden in large amounts of carrier traffic, the attacker can stay below arbitrarily low thresholds of detection.
ncovert and the gray-world.net projects are ones to look at.
http://gray-world.net/pr_cook_cc.shtml
is a must read, which uses HTTP cookies to hide covert data
i also coined a phrase earlier this year, “call home through call home”, which is basically a way of using Windows Automatic Update (or Mac OS X Software Update), or similarly – AIM, Java, Adobe, etc update features to create a covert channel
most of this is almost completely moot if all an attacker wants is browser control. attackapi provides a model, running code, and an action plan to get undetectable botnets in every browser running javascript it can get its hands on. if someone provides a signature, there is always javascript obfuscation through compression, encryption, etc.