Bruce Schneier
Schneier on Security
A blog covering security and security technology.
« Brazilian Logging Firms Hire Hackers to Modify Logging Limits | Main | James Bamford Interview on the NSA »
December 17, 2008
DNS Dead Drop
EDITED TO ADD (12/18): an updated version, as pointed out by Redfox in the comments.
Posted on December 17, 2008 at 4:29 PM • 12 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
mckt • December 17, 2008 5:33 PM
And this is why attempting to keep data from leaving your network, building, or country is a waste of time.
Of course, having your own DNS server could stop this, but there are so many other ways...
DGentry • December 17, 2008 5:39 PM
Admittedly its a clever way to trick a remote DNS server into storing small amounts of data for you. The main appeal seems to have been the challenge in getting it to work.
Then again, Dynamic DNS exists to provide a way to get a remote DNS server to store small amounts of data for you.
Bryan Feir • December 17, 2008 5:44 PM
@mckt:
It's noteworthy that from the description given in the article, even running your own DNS server won't stop this, unless said DNS server is either running custom software to never service unknown names, or it's completely inaccessible from the outside. Any DNS server that both sender and recipient can talk to will work for what he has, though it can almost certainly be detected via audit logs.
All this reminds me of a friend who used to talk about IP tunneling over DNS, because DNS was usually a deliberately open port in any firewall. This would allow him to run programs talking to non-standard ports by going through the IP-over-DNS gateway, then having another end of the tunnel on his home machine to send packets out. No idea whether or not he ever actually did it, but there is software out there to do this...
Mace Moneta • December 17, 2008 6:01 PM
I used to send messages in the ping packet payload, which most everyone ignores:
HOST1: ping -c 1 -p facedead12349876 host2
HOST2: tcpdump -x ip proto \\icmp and src host host1
Anonymous • December 17, 2008 6:03 PM
Sounds like something the terrorists would use to send secret messages.
Reginald J. Archibald • December 17, 2008 6:09 PM
Mace Moneta: The difference here is neither side of the conversation reveals themselves to the other. The only entity that knows the identity of both conversational peers is the erstwhile DNS server.
Johnny2Bad • December 18, 2008 1:04 AM
@mace: If two parties decided to communicate in this fashion, all they would have to do is choose a DNS server they both had access to. If both parties were working together with equal IV's (perhaps using an encryption algortithm to change it based on timestamp) they could have a very private conversation especially if the word lists are encrypted/decrypted in the same general manner of the IV. Of course variations of this method could probably also be used to flood and cause a DOS, but we'll leave that to the crackers/script kiddies. Oh and @anonymous, terrorists?? TERRORISTS???? Do you read this blog?
Redfox • December 18, 2008 1:33 AM
This is outdated.
The Author has written a new version of his Dead Drop:
>26 Jan 2008
>Implementing a Better DNS Dead Drop
@mckt: I've done this using SSH occasionally at certain "half-open" wifi hotspots. I haven't found it to work for the last couple of years and have stopped trying it. I don't even run the sshd on port 53 anymore. But I do still find lots of network admins who have some insane notion that port 80 and port 443 are "good ports" but other ports are "bad ports".
Govt Skeptic • December 18, 2008 7:40 AM
Even if the signature of the first implementation is too easy to detect, that's not really all that big a deal. The second implementation is pretty cool, but could probably also be detected.
Overall, though, there's no reason that a list of usable dns servers couldn't be published and used in conjunction with an IV to distribute the bits across many servers.
As another commenter pointed out, constructing a two-way protocol based on this is pretty easy. That, combined with some from of ecc (Tornado, whatever), would provide a pretty neat subchannel on the internet.
My weekend is now shot.
Bryan Feir • December 18, 2008 10:25 AM
@L:
Considering that arguably the most common port over which people get their machines infected is port 80, yes, that is an insane notion. Especially given the number of more active protocols designed to run over port 80 as part of the HTTP stream. Though if the admin is thinking along the lines of 'good for making sure nobody blames me' rather than 'good for the people on the network', then there might be a point.
Though port 110 (POP3) is probably pretty common, too.
Clive Robinson • December 19, 2008 5:25 AM
Both methods should be food for thought for "Joe Admin" and others...
But I guess they will probably just block the specific threat instead of thinking about it as a specific instance of a sub class of the more general class of Side Channel attacks (which in turn are a sub class of TEMPEST attacks).
The Ususal known rules for TEMPEST are bandwidth/energy. However this one can be stopped by a combination of a variation of "clock the inputs and clock the outputs" and sanitize "data held".
In this case if the DNS server actually checked the domain info was real before putting it in it's cache (ie checked with the authorative server), and only changed the data held in the cache when it had checked the change with the authorative server then this side channel would close.
But with a little thought you can probably see there are ways around this ;)
Just as a hint, think about using the latency of response to DNS requests for legitimate machines in legitimate domains (that is the response time if in the cache is shorter than when not in the cache).
Subscribe to comments on this entry
Post a comment
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT.
|
| Subscribe |
Subscribe via Kindle |
| Blog Menu |
SearchPowered by DuckDuckGoBlog Home Page
Archives by Date2013 J F M A M J
Tags  |
| Latest Book |
more books by Bruce Schneier |
Comments