Hacker News Reader

Comment by tlb | Hacker News Reader

It's horrifying to watch your own DNS traffic. All sorts of mysterious domains show up. (On a typical macbook on WiFi, this will do it:)

   sudo tcpdump -i en0 -s 5000 -n port 53

On mine, these get resolved every 30 seconds (probably some Adobe updater):

  scss-prod-ue1-notif-39.adobesc.com.

Several servers get lookups of names long enough to be exfiltrating data:

  r3---sn-nvopjoxu-25ve.gvt1.com.  (Google)
  gzunified-ecselast-1isehuisml2g4-663788831.us-east-1.elb.amazonaws.com. (???)
  kube-nimbus-471965604.us-west-2.elb.amazonaws.com. (BitDefender)

If you hit a popular commercial site without AdBlock enabled, the list is loooong and sketchy-looking.

View on HN

That Google one uses a similar naming scheme to the servers used for video data for YouTube etc.

You just made me realize something, though. The Google and AWS examples you gave won't be able to do this, but if you set up wildcard DNS and tell DNS that you have your own nameserver via CNAME aliasing, you could make your software do a lookup for eg something like "bm9ib2R5IHdpbGwgZXZlciBub3RpY2UgaWYgSSB0cmFuc21pdCBkYXRhIGxpa2UgdGhpcyEKCg.example.com" and exfiltrate data via DNS request in the process. The server could then return 127.0.53.53 to mean "ACK; data received OK", whereas NXDOMAIN or any other error would mean to try again.

Hmmmmm. Wondering if I should delete this...

(I realize this is exactly how the Iodine DNS tunnel works. FWIW, freedns.afraid.org's free options are perfectly capable to get iodine working, I was very pleased to discover.)

I believe it's common for malware to beacon out with a similar method.

and as a bonus fully patched and firewalled Win10 will happily pass DNS traffic thru DNScache daemon without any filtering

I know several people who use these sorts of techniques to exfiltrate data from a network where you don't have outbound TCP but you can leak information through DNS. As you mentioned, Iodine lets you do this (though by default it tries to use VOID DNS responses that are blocked by a lot of networks).

It's pretty cool being able to do an rsync-over-DNS.

> VOID DNS responses that are blocked by a lot of networks

For ages I've been meaning to [figure out how to] report this to the iodine dev, but I actually set up iodine specifically to get a working network while I knew I'd briefly be visiting a hospital.

I discovered to my amusement that the (public!) hospital's IT infra is really, really good; I was trying to SSH directly on top of the iodine tunnel, and while the first few DNS requests associated with the connection setup would work and I'd get as far as getting a shell prompt, but everything would rapidly screech to a halt and jam up pretty much instantly after that; maybe I'd get a single character typed, then it would completely die. I figured I was looking at a remarkably well-put-together leaky-bucket implementation.

So I tried hacking usleep()s into likely-looking spots in the code, but that didn't seem to slow it down enough. iodine is a rather interesting program internally, and a quick overview while distractedly sitting in a waiting area wasn't entirely sufficient to figure out why I didn't seem to be slowing it down enough to be a problem.

Before this "production" test, I previously verified that iodine was working by running the client on an AWS box. IIRC, ping ran over the link for quite some time (less than an hour; many minutes) without a single hitch.

On another note, I found that iodine seemed utterly incapable of setting up a correctly-configured tunnel on my Arch (receiving/server) box; I always had to ifconfig the tunnel (I forget exactly) to make it work. Problem with that was, my ifconfig-ing only routed one specific IP address, iodine wanted to give connections their own discrete IPs, and old sessions that locked up would take a while to time out. So I made a gigantic hack-script that would repeatedly kill iodine over and over every 1.5 minutes if it didn't see an authenicated SSH login. Would be nice for everything to just work properly...

> sudo tcpdump -i en0 -s 5000 -n port 53

It may be better to do it like this:

    sudo tcpdump -i any -s 0 -n port 53

That way you'll get to see every single DNS query made, and capture everything about it.

On the other hand, if even you don't know what the domain corresponds to I suppose that does make it less privacy sensitive.

The primary privacy issue here isn’t the DNS lookup, but the data that was inevitably sent after the resolution.

I woke up in the middle of the night, seized by the realization that this meant that Adobe knows, down to the half-minute resolution, when I am using my computer (to do anything).

I've been running this command on my mac for over 10 minutes, trying different stuff, nothing. Also tried "sudo tcpdump -i any -s 0 -n port 53 -v". What's going on?

Little Snitch is a fun program to run to see what software is connecting to where. So many connections to Google Analytics...

At least with the AWS ELB ones, the names can't be wildcards, so the only information that can be transmitted is info that the other party had set up ahead of time. 'gzunified-ecselast-1isehuisml2g4-663788831' is actually in someone's ELB list somewhere.

That ELB is part of Bitdefender's infrastructure.

EDIT: For those who want to know how to determine that in the future, hit a generic ELB hostname with SSL and you should get the cert mismatch warning back with details.

Reply on news.ycombinator.com