

Tunneling Data and Commands Over DNS to Bypass Firewalls - tedyoung
https://zeltser.com/c2-dns-tunneling/

======
mayli
I've been using iodine
[http://code.kryo.se/iodine/](http://code.kryo.se/iodine/) for a long time.

~~~
buserror
Ah, I need to start using this. Work's firewall is completely bonkers, and
they just removed access to webchat.freenode.net, so I need to find a way to
punch thru... You can't even ssh out, or use websockets etc...

~~~
chrismsnz
Circumventing your companies firewall is not a great idea in the first place.

Additionally, if they have aggressive egress filtering, its likely that the
only DNS communication will be via an internal resolver which is going to be
monitored - iodine is going to leave a LOT of shit in those logs.

~~~
buserror
Well I hope they don't proxy the DNS -- it's quite costly to do so, if they
don't it'll be fine. If they do, well, I'll have to find another way using
'long' http transactions and such...

~~~
chrismsnz
Running an internal DNS resolver is actually very cheap, almost every
broadband CPE device runs or can run its own DNS proxy resolver.

It's also a great source of information when monitoring egress communication,
so I would just make sure you know what you're doing.

------
jbuzbee
From reading the article, it looks like in the most restrictive environment,
the "malware" (dnscat2) behind the firewall passes data out by resolving lots
and lots of unique subhosts at the controlled DNS server, e.g. many queries of
hosts like: 19c301abcddeadbeef.malware.com.

It seems like this pattern could be recognized behind the firewall. How often
would a real Internet client resolve hundreds or thousands of sub-hosts in a
short timeframe?

~~~
TheLoneWolfling
Relatively often, actually.

For instance, on this link on HN:
[https://medium.com/@bchesky/7-rejections-7d894cbaa084](https://medium.com/@bchesky/7-rejections-7d894cbaa084)

It loads <some random subdomain>.cloudfront.net - and it changes every reload
for me. For instance, d262ilb51hltx0.cloudfront.net,
dnqgz544uhbo8.cloudfront.net, d262ilb51hltx0.cloudfront.net.

~~~
jbuzbee
That seems a bit different. A unique subdomain for each web page load might be
common, but from my reading of the article, it looks like every packet of the
tunneled conversation gets a unique domain. So for transferring any amount of
data, I'd expect to see hundreds (thousands?) of subdomain resolution queries
in a few minutes. That could raise a red flag.

I suppose if the malware wanted to be more stealthy, it could slow transfers
way down, intermix unrelated queries and spread the tunnel across multiple
unrelated controlled domains.

~~~
TheLoneWolfling
As you said, you can do slow data transfer extremely easily and stealthily
with this method. Bulk data transfer, not so much.

------
dvt
Don't tell anyone, but I did this on a plane ;) It was fickle, but I imagine
you could build an entire protocol on top of DNS.

~~~
gruez
wait, you could bypass the inflight wifi's paywall by using dns tunneling?

~~~
gwillen
You can bypass essentially all paywalls using DNS tunnelling. The connection
you get has _terrible_ bandwidth and latency characteristics, which is why
nobody does it.

~~~
huhtenberg
Not entirely correct.

This doesn't work for many hotel paywalls, because they would have a catch-all
rule for all DNS A queries (resolving to a local IP of authenticating proxy)
and block everything else. And the reason is exactly because of the DNS
tunneling, which was making rounds in p2p circles as far back as 2005 if not
earlier.

~~~
cfallin
Doesn't this cause issues with cached bogus A records once the user pays and
is granted access? I suppose you could return really short TTLs, but there
would still be a delay of at least a few seconds.

(I'm not doubting they do this, just saying it seems very hacky...)

~~~
detaro
Yes, it does, and of course fails if the site called is https. AFAIK some
implementations work as a proxy after successful authentication to reduce that
problem.

Other solutions use proxy configuration detection to redirect people to a
proxy that first asks for authentication/payment. (wpad file)

Both solutions are kind of hacky, but they work for more or less all devices.

------
jkot
One mobile operator in central europe allows ICMP on all phones...

~~~
slirpee
I was tinkering with DNS tunneling for free mobile internet, and found that
TCP port 53 was apparently unfettered. (Other traffic I tried was firewalled,
and HTTP was captured and redirected to a page prompting to buy a data plan.)
I guess the intention was for DNS over TCP, but I was able to ssh over that
port and got decent speeds and no apparent tampering of the traffic.

