Hmm, I would think scp would be way more secure if he can shell into both sessions? idk. There's probably a perfect use case out there somewhere. Still a neat trick, heck you could probably do it with any service, not just DNS, cause you're basically just capturing traffic to receive it...
I'd guess the use case would be someone trying to send files through a network that's mostly locked down (think: corporate network using a transparent proxy for HTTP, etc), but allows outgoing DNS traffic.
Been there, done that. A lot of public WiFi hotspots will allow outgoing (and incoming) DNS, by design.
It's unbearably slow (especially when you use SSL over it, which I'd consider almost mandatory if you do this) for anything other than email and maybe running a few shell commands, however. Applying additional obfuscation/whitening to the data stream to make it harder to detect makes it even slower.
Running a DNS server isn't inherently harder than running any other type of server. I think the point isn't to pwn any existing DNS server, but rather to hide communications from e.g. an IDS.
For the described technique, no. However, it would be easy enough for one request to have a different length hostname than the rest which contained a checksum, and if then try different combinations of the rest until it matched the checksum, which it would only need to do if it were out of order. And if that happened, you could increase the time between requests, to compensate.
edit whoops, hit the reply link under the wrong comment. This was supposed to be a comment under "This is a prime example of a covert communication channel."
If anyone is interested in having more fun with this kind of stuff, take a look at Tor's pluggable transports[1], for example. A taste specimen of 'covert channels':
* various 'have everything appear to be random TCP with no other marks' transports (+/- padded packet lengths, time intervals, etc.)
* skype-look-alike transport
* various-stuff-over-http-look-alike (html, etc) transport
* a transport that imitates git's push/pull
* a transport that, given enough 'permitted'/non-censored data, learns to imitate arbitrary protocols (learns and encodes them as regular expressions; some interesting and crazy CA madness)
This is awesome, but I've found it usable only for very low bandwidth applications (like a remote terminal session). Web pages and emails are large these days :(
While a high number of requests for uncommon domains might trigger a lot of suspicion, you can cart out smaller amounts of data over DNS in ways that are really hard to detect. I've seen situations where data was being sent over DNS requests where the attacker merely held the ability to view the outgoing DNS traffic, but didn't really control (or want to risk modification) of traffic.
It should, but it's unfortunately very rare to find a shop that looks for these kinds of covert channels. Most of the time DNS/ICMP/HTTP/etc are simply let through without logging or inspection.
Since most clients are supposed to work through a specified resolver rather than run their own, the easy block is to deny port 53 to non approved resolver hosts. Probably a good idea anyway in a secure environment, since it can potentially avoid cache poisoning if DNSSEC is setup right.
You can use the approved resolver. Just set up a DNS record delegating some subdomain to the fake DNS server, and then any unsuspecting resolver will work for you, sending the request upstream to the authoritative nameserver.
This sort of abuse of protocols is pretty well used. A number of interesting port knockers are written using ping (ICMP echo). One of the more interesting to me was using the TTL value to pass hex nybbles. Implementation was up the ttl until your ping got through, then send your 'value' as ttl + value to your destination. It was limited mostly because you don't get that many hops generally. It is also negatively effected by path randomization but if you're willing to commit bits to forward error correction you can still get a message through.
A lot of ping traffic through, shows up like most of these ideas in any shop with regular network monitoring.
28 comments
[ 2.9 ms ] story [ 28.3 ms ] threadNot airtight, but ... something like that?
It's unbearably slow (especially when you use SSL over it, which I'd consider almost mandatory if you do this) for anything other than email and maybe running a few shell commands, however. Applying additional obfuscation/whitening to the data stream to make it harder to detect makes it even slower.
If anyone is interested in having more fun with this kind of stuff, take a look at Tor's pluggable transports[1], for example. A taste specimen of 'covert channels':
* various 'have everything appear to be random TCP with no other marks' transports (+/- padded packet lengths, time intervals, etc.)
* skype-look-alike transport
* various-stuff-over-http-look-alike (html, etc) transport
* a transport that imitates git's push/pull
* a transport that, given enough 'permitted'/non-censored data, learns to imitate arbitrary protocols (learns and encodes them as regular expressions; some interesting and crazy CA madness)
* etc.
[1]: https://www.torproject.org/docs/pluggable-transports.html.en and https://trac.torproject.org/projects/tor/wiki/doc/PluggableT...
[0] http://en.wikipedia.org/wiki/Covert_channel
Useful for hotspots that allow DNS but nothing else
If you're interested in IP-over-DNS, you may also be interested in IP-over-Facebook: https://news.ycombinator.com/item?id=7256477
While a high number of requests for uncommon domains might trigger a lot of suspicion, you can cart out smaller amounts of data over DNS in ways that are really hard to detect. I've seen situations where data was being sent over DNS requests where the attacker merely held the ability to view the outgoing DNS traffic, but didn't really control (or want to risk modification) of traffic.
A lot of ping traffic through, shows up like most of these ideas in any shop with regular network monitoring.
https://github.com/ryancdotorg/dnsstore