Bypassing a DNS man-in-the-middle attack against Google Drive

http://varnull.adityamukerjee.net/post/73134171911/bypassing-a-dns-man-in-the-middle-attack-against-google

by chimeracoder • 13 years ago

56 44 13 years ago

varnull.adityamukerjee.net

romeo88• 13 years ago

dns "hijacking"? hosts entry as solution? booooooooooooring.

dsl3• 13 years ago

First of all, this isn't a MITM attack, it is simply policy enforcement at the DNS layer.

Secondly, imagine sharing a bus with someone pulling down tens of gigs of files from Google Drive over a shared cellular or satellite connection. They are watching out for everyones experience, not just yours. If you need to get work done, they don't prevent you from bringing your own dedicated connectivity.

chimeracoder3• 13 years ago

First of all, this isn't a MITM attack, it is simply policy enforcement at the DNS layer.

The way it seems to me, they are intercepting outgoing DNS requests that should be queried against Google's DNS servers, since I had "8.8.8.8" and "8.8.4.4" in my /etc/resolv.conf.

Is that not correct?

Secondly, imagine sharing a bus with someone pulling down tens of gigs of files from Google Drive over a shared cellular or satellite connection.

The solution to that would be to throttle speeds or bandwidth for each connected device, rather than block all access to specific domains. In my case, I just needed to read a static text document (a "Google Doc").

dsl3• 13 years ago

Is that not correct?

Calling it an "attack" is disingenuous and sensationalist.

The solution to that would be to throttle speeds or bandwidth for each connected device

That is a pretty slippery slope. You are escalating from blocking some DNS records to doing deep packet inspection of all traffic. You also have no idea what the operating requirements are (maybe they don't have {financial,computational,power} budget to do it your way?).

Again, bring your own connectivity and you get to make the rules. Use someone else's bandwidth, and they make the rules.

FireBeyond• 13 years ago

No. That's -your- solution. Not their solution. They -choose- to block access, which is their right.

Perhaps they should have managed that process better / more transparently.

But you should dial back the entitlement. This "I just needed"..., and then there's the "Well, I'm going to get around it anyway, since it's obviously blocked".

pocketheyman• 13 years ago

Seems like a general way to reduce bandwidth consumption, but there are probably better ways then a fake 404 page?

jwise02• 13 years ago

(expanding on my response on Twitter...)

I generally don't find /etc/hosts to be a sustainable answer against DNS hijacking, at least on hostile networks. For one thing, one-off hosts entries can cause you quite a lot of grief if Google chooses to change up what machines they host various services on; it may well also result in degraded performance if they use geoDNS to give you a lower-latency machine based on where you are accessing from.

But, more than that, even though "most" of my applications are SSL, if I know a network to be hostile, I would rather have absolutely none of my traffic passing through them unencrypted. If you have a machine somewhere to run OpenVPN on, that's probably the safest thing to do; I've mine listening on TCP port 443, as well as the standard UDP port 1194.

There are times when /etc/hosts is your best workaround -- such as a network that you generally trust, but which has some filtering that you need to work around. (Work networks often qualify for this.) But in the case of a truly hostile network, OpenVPN is probably your friend.

chimeracoder3• 13 years ago

I generally don't find /etc/hosts to be a sustainable answer against DNS hijacking, at least on hostile networks.

Completely agreed. Unfortunately, this requires preparation in advance.

Thankfully, this was just for a short bus ride - I actually changed it back immediately after loading the Drive homepage.

How much overhead does OpenVPN add? I've used it a bit on reasonably fast networks, but I'm curious if it would be too slow to use here.

jwise02• 13 years ago

I think in TCP mode, the big pain point is that packet loss on one wrapped session is lethal to your whole connection (i.e., all streams stop if just one stream stops).

In UDP mode, I think you lose only 70-ish bytes per packet, which isn't too bad.

(Another win that you get is roaming: if your local IP keeps changing, perhaps because your bus's cell modem keeps dropping out, then you don't lose your SSH sessions.)

chippy• 13 years ago

If this was a MITM attack what would have been the correct route of action? Use a VPN?

atmosx4• 13 years ago

Unbound + DNSSEC should be able to counter-measure this. That said, I'm not sure you'll be able to connect to a given IP if it's blocked. In this case you'll need a proxy/VPN/Anonymizer (Tor/I2P)

codeka• 13 years ago

Note that 74.125.228.1 is an IP address for drive.google.com. You'll get a different answer depending on where you are in the world when you issue the query (it will return an IP address for the datacenter nearest you).

muppetman• 13 years ago

They are probably doing this to stop people using DNS tunnelling to bypass sites/blocks/paywalls setup.

Doing this can end up biting you in the butt in a few months time when Google move the service to a different place and you've forgotten to change the IP in hosts.

Certainly works as temporary solution - this is how I test some of my websites before I push them into production via DNS.

coenhyde2• 13 years ago

VPN. Always VPN. Don't trust the local network. A Digital Ocean droplet is only $5 a month so for most of the readers here there's no excuse for not using a VPN.

Even my home network can't be trusted. Comcast hijacks DNS request to third party DNS servers.

nwh• 13 years ago

If you can't trust Comcast, can you trust Digital Ocean?

coenhyde2• 13 years ago

I trust Digital Ocean more than Comcast. And when I say trust, the trust part is that I trust Digital Ocean to deliver a service without playing silly games. Not that I trust Digital Ocean to keep my data private because at the end of the day you can't hide from agencies.

barrkel• 13 years ago

lowendbox.com - you can do much better than $5/month - try $8/year.

dictum• 13 years ago

I've FUD'd myself regarding lowendbox.

Using a Digital Ocean droplet as a VPN is probably the same as driving to Fort Meade monthly and handing them a hard drive with your full upload and download streams for the month, but using an unknown provider from LEB feels like handing out 2 drives: one for no such agency, another for some guy with a lot less data to sift through, thus a greater disposition to look at my data.

regecks• 13 years ago

If you have problems with your ISP hijacking DNS traffic, consider something like http://www.opendns.com/technology/dnscrypt.

They could stick hijack/block the traffic to the end server, but I suppose at that point you may as well give up and use a VPN.

philip1209• 13 years ago

Encrypting DNS should be standard policy on all roaming computers.

guelo• 13 years ago

Would it be possible to use a local BIND server with a large cache? I guess it needs to do zone transfers with root servers.

sehrope• 13 years ago

Not if you respect the TTL on the DNS records. For example for drive.google.com it's 300 seconds:

    $ dig drive.google.com
    
    ; <<>> DiG 9.8.3-P1 <<>> drive.google.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62437
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 0
    
    ;; QUESTION SECTION:
    ;drive.google.com.		IN	A
    
    ;; ANSWER SECTION:
    drive.google.com.	300	IN	A	74.125.226.225
    drive.google.com.	300	IN	A	74.125.226.238
    drive.google.com.	300	IN	A	74.125.226.231
    drive.google.com.	300	IN	A	74.125.226.228
    drive.google.com.	300	IN	A	74.125.226.224
    drive.google.com.	300	IN	A	74.125.226.227
    drive.google.com.	300	IN	A	74.125.226.232
    drive.google.com.	300	IN	A	74.125.226.226
    drive.google.com.	300	IN	A	74.125.226.229
    drive.google.com.	300	IN	A	74.125.226.233
    drive.google.com.	300	IN	A	74.125.226.230
    
    ;; Query time: 32 msec
    ;; SERVER: 192.169.1.1#53(192.169.1.1)
    ;; WHEN: Sun Jan 12 18:37:40 2014
    ;; MSG SIZE  rcvd: 210

bschlinker• 13 years ago

However, entering that IP address into your browser will give you the Google homepage, because unlike most sites, their servers check the hostname

I'm pretty sure that name-based hosting is fairly common, especially for smaller websites...

MatthewWilkes• 13 years ago

It's only uncommon when it comes to sites running under TLS.

revelation• 13 years ago

This is a situation ripe for regulation. Feel free to filter by port or ip subnet, maybe we can talk about DPI, but modifying clearly needs to be a crime. There may not be an expectation of privacy, but there is certainly one that the integrity of the technical systems we use is not violated.

atmosx4• 13 years ago

A couple of notes:

* This was not a MITM attempt

* When traveling laptops, it's more secure to use DNSSEC + Unbound

* The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so - fair enough, I trust Dr Bernstein even more than tptacek - but it's a bit contradictory. He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4).

Also, note, all major DNS providers are collecting data: OpenDNS (also adds a few suspicious redirects when the URL doesn't exist), Google is the leader of world-data mining, etc. The most trustworthy DNS, according to the a research I did some time ago, was/is OpenNIC.

At home I run a dnsmasq + unbound (DNSSEC) + OpenNIC DNS's. On my laptop I have a similar configuration which uses by default a local unbound installation when joins every other network except mine.

[1] http://googleonlinesecurity.blogspot.cz/2013/03/google-publi...

[2] http://en.wikipedia.org/wiki/DNSCurve#Deployment

[3] http://www.opennicproject.org/

chimeracoder3• 13 years ago

This was not a MITM attempt

I've heard captive portals on here eferred to as MITM attacks, and I think it's an accurate description of what's happening, regardless of the intent of the captor.

In this case, they were hijacking DNS requests that were explicitly being made to another provider (first OpenDNS, then Google), and returning their own results instead of OpenDNS's or Google's.

From a cryptographic perspective, I certainly would say that it fits the description of an MITM: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

He should be using OpenDNS which is the only major DNS provider of DNSCurve[2], instead of Google (8.8.8.8 and 8.8.8.4).

Actually, I was using OpenDNS initially - I switched to Google because I thought that might be the source of the OpenDNS error I was getting (the very first screenshot - admittedly a bit small to read in the picture).

But it doesn't matter which DNS provider you use if they're hijacking traffic on port 53, which is what was happening here.

The author trusts Google with his data, which uses DNSSEC[1], but not DNSSEC because @tptacek said so

It's not just "because tptacek says so" - it's because tptacek wrote a detailed critique comparing both services which I found convincing. I updated the post to link to tptackek's post that explains the issue in more detail; that's what I was referring to, but I couldn't find it at first when I wrote the post.

jrochkind1• 13 years ago

If you want to call it an MITM attack, but your browser gives you a cert error, then the most you can say is it's an incompetent, failed MITM attack, right?

atmosx4• 13 years ago

IMHO this diversion doesn't classify as an attack. It was not meant to hurt in any way, or at least there's no sign of any harm done in your post. I try to use common sense first, and only afterwards stick to the letter.

Not sure exactly that comparing DNSSEC (signatures == trust) and DNSCurve (encryption + signature but only hop_to_hop, not up to root.) makes sense, that's why I said above that unbound + OpenNIC (which I trust and support DNSCrypt).

Thanks for taking the time to reply

eli• 13 years ago

OpenDNS makes money off those redirects, but you can turn them off if you create an account.

colmmacc• 13 years ago

There's no reason to think that running your own copy of DNSSEC + Unbound would have helped here. Firstly, Google don't have DNSSEC signed DNS data, which renders the feature moot. But even if google did, DNSSEC would have triggered the same kind of error that TLS did; the knowledge of a false answer. It wouldn't have resulted in a correct answer.

DNSCurve is more robust in that respect. It's very hard to tamper with the data stream other than to break it entirely.

atmosx4• 13 years ago

Yes but DNSCurve is hop-to-hop and solves a different problem. If you are able to take a over a resolver between the victim and the TLD, you can easily hijack DNSCurve.

garthdog• 13 years ago

Is this even a problem with Google's certificate pinning? Chrome would prevent the user from accessing Drive if it was MITM'd.

tytso• 13 years ago

Why not just set up an http proxy on a linode box which only listens to localhost. Then use ssh -L to set up a port forwarding from your local host port 3128 to your linode host's port 3128, and then configure your browser to use localhost:3128 as your http proxy. Easy!

(Alternatively, I just pull out my Nexus 7 with LTE support, and either turn on the portable wifi hotspot feature, or plug it into my laptop, and turn on USB tethering. Problem solved. :-P)

twinge• 13 years ago

You don't even need to run a proxy on the linode host: just use ssh's SOCKS proxy (the -D flag).

https://mikeash.com/ssh_socks.html

Though this might require some more work to avoid DNS MITM, because it only tunnels TCP.

eru• 13 years ago

You can tunnel DNS via socks, too.

Bypassing a DNS man-in-the-middle attack against Google Drive

Related Stories