Bypassing a DNS man-in-the-middle attack against Google Drive(varnull.adityamukerjee.net)
varnull.adityamukerjee.net
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
47 comments
> 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").
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").
> 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.
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.
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.
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.
You are correct. I misread his suggestion as rate limiting specific flows, not flat per device rate limiting.
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.
your reasonable response reminds me that my tone is excessively harsh... sorry :)
> 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?).
Wait, what? If they have cheaper hardware and can't invest in more now, that certainly is an issue, but traffic shaping per device does not require deep packet inspection.
Wait, what? If they have cheaper hardware and can't invest in more now, that certainly is an issue, but traffic shaping per device does not require deep packet inspection.
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".
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".
> But you should dial back the entitlement.
Not that you're completely wrong, but he is most likely paying to be there. If the company advertised the WiFi as part of the deal, and he paid for it, I'd say he is at least a little entitled to it.
Not that you're completely wrong, but he is most likely paying to be there. If the company advertised the WiFi as part of the deal, and he paid for it, I'd say he is at least a little entitled to it.
Seems like a general way to reduce bandwidth consumption, but there are probably better ways then a fake 404 page?
(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.
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.
> 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.
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.
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.)
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.)
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/) 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.
As a random aside, mosh (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.
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).
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)
(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)
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.
https://mikeash.com/ssh_socks.html
Though this might require some more work to avoid DNS MITM, because it only tunnels TCP.
You can tunnel DNS via socks, too.
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.
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.
Encrypting DNS should be standard policy on all roaming computers.
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.
Even my home network can't be trusted. Comcast hijacks DNS request to third party DNS servers.
If you can't trust Comcast, can you trust Digital Ocean?
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.
lowendbox.com - you can do much better than $5/month - try $8/year.
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.
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.
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/
* 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/
> 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.
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.
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
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
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.
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?
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.
DNSCurve is more robust in that respect. It's very hard to tamper with the data stream other than to break it entirely.
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.
OpenDNS makes money off those redirects, but you can turn them off if you create an account.
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.
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.
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.
> 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...
I'm pretty sure that name-based hosting is fairly common, especially for smaller websites...
It's only uncommon when it comes to sites running under TLS.
[deleted]
[deleted]
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.
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: 210Is this even a problem with Google's certificate pinning? Chrome would prevent the user from accessing Drive if it was MITM'd.
dns "hijacking"? hosts entry as solution? booooooooooooring.
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.