
Bypassing a DNS man-in-the-middle attack against Google Drive - chimeracoder
http://varnull.adityamukerjee.net/post/73134171911/bypassing-a-dns-man-in-the-middle-attack-against-google
======
dsl
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.

~~~
chimeracoder
> 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").

~~~
dsl
> 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.

~~~
ploxiln
You, sir, are quite wrong. Traffic shaping, counting packets per user in the
bus, is not deep packet inpection. Intercepting port 53 and replying on behalf
of the real owner of the destination ip is seep packet inspection.

Also, blocking a site that sometimes does and sometimes doesn't use a lot of
bandwidth, instead of just blocking all uses of lots of bandwidth by measuring
it in a destination-agnostic way, is clearly the worse option.

Finally, rules and restrictions on technological devices and connectivity are
retarded world-round. Your personal gadgets, your home internet connection,
your phone's internet connection, all have ridiculous restrictions that no
self-respecting technically savvy person follows (although most don't realize
all the things they do that are against the "terms of service"). I don't get
too worked up about them anymore, just systematically work around any I run
into, just like any sane technically proficient person.

~~~
dsl
You are correct. I misread his suggestion as rate limiting specific flows, not
flat per device rate limiting.

~~~
Dylan16807
Even then, looking at the TCP/UDP headers to balance traffic is not _deep_
inspection. Pretending to be a server and injecting yourself is both deep
inspection and MITM.

------
jwise0
(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.

~~~
chimeracoder
> 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.

~~~
jwise0
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.)

~~~
mct
_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_

As a random aside, mosh ([http://mosh.mit.edu/](http://mosh.mit.edu/)) is
incredibly good at IP mobility. One of my favorite examples: I circumnavigated
the globe in November of 2012, and used the same mosh session in San
Francisco, Hong Kong, Singapore, Kuala Lumpur, Penang, Bangkok, and Istanbul.
:-) mosh also provides predictive local echo, which has made working over
high-latency links _so_ much more pleasant.

------
codeka
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).

------
tytso
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
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](https://mikeash.com/ssh_socks.html)

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

~~~
eru
You can tunnel DNS via socks, too.

------
regecks
If you have problems with your ISP hijacking DNS traffic, consider something
like
[http://www.opendns.com/technology/dnscrypt](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
Encrypting DNS should be standard policy on all roaming computers.

------
coenhyde
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
If you can't trust Comcast, can you trust Digital Ocean?

~~~
coenhyde
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.

------
atmosx
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...](http://googleonlinesecurity.blogspot.cz/2013/03/google-public-dns-
now-supports-dnssec.html)

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

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

~~~
chimeracoder
> 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](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.

~~~
atmosx
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

~~~
Dylan16807
If the data is changed without the permission of either end party, then it is
an attack. There was no 'harm' done to the parties involved, but the 'attack'
here is not aimed at the parties, it's aimed at the integrity of the
connection. The integrity was completely destroyed, so I think 'attack' is an
appropriate term.

------
muppetman
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.

------
revelation
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.

------
bschlinker
> 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
It's only uncommon when it comes to sites running under TLS.

------
guelo
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
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

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

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

~~~
atmosx
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)

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

