This is a serious problem for those of us who need to use public WiFi. The only thing standing in the way would be HTTPS but that's far from comprehensive at this point.
I am trying to confirm that cox does this with google. The cert is funky and doesn't match what I see from other connections. All hosts from nslookup are cox hosts, etc.
Lots of people think nothing of a bounce from an HTTPS download link to an HTTP-only download link, and will happily ignore even flagrant warnings...
Root CA's have been compromised in the past, and will be again. I expect 0-day root CAs are up for sale somewhere as I type. It's not like the so-called "good guys" can't physically demand access to private keys, or big businesses can't out-right buy root trust (ex, "We need to do this on our private network - we'll never put it on the Internet, really. Here's a lot of money."). The root system is only as strong as it's weakest policies, and it's about as leaky as a steamer basket.
Even if an attacker can't get a directly useful signature, she can take control of a server already in possession of a valid cert, merely for hosting purposes (if Ubiquiti can be scammed, so can Google, as can you or I). This can be an inside job, or a one-off breach - all it takes is one click or breach of trust. (The DNS MITM tricks that work for the download can also be used to get between 2 parties higher up the trust heirarchy.)
And, of course, it is also always possible to buy a fresh, perfectly valid cert for a domain that looks close enough to pass the user test, or - quite alarmingly - one with UTF characters that combine to display in the address bar identically - or close enough - to the domain being impersonated.
That's just what comes to my mind immediately.
It's amazing any of it works at all, and arguably it doesn't. If you haven't be breached, it's probably because you haven't been targeted,
That's one of the reasons I'm on a VPN right now. I'm at a rental place, and the owner is reasonably competent technically (ex-DEC engineer - we have some good chats), but I still don't trust that his router is 100% safe. Come to think of it, I don't trust that mine is. Maybe I should start using a VPN even while I'm at home. Unfortunately, this can introduce a few problems of its own.
(1) You have to trust the VPN provider. Not a big problem in this case, but worth mentioning.
(2) If you have to be on your work VPN as well, you're going to have a bad time. Being only on the work VPN often isn't an option, as a lot of personal use might run into blocks and/or violate the company's policy on use of their resources.
(3) Some sites block VPNs, either intentionally or unintentionally. Just yesterday I noticed that Tumblr is blocking most (but not all) of my VPN's connection points. It's probably just an overzealous anti-DOS system rather than a deliberate block, but the effect is the same.
We really do need a better solution here. Jeff's right that home routers are a huge vulnerability. DNS and BGP hijinks are too effective and well known to leave them unaddressed any longer, and there are other issues that need to be solved as well.
ISP's could be doing a better job of looking for/blocking out these shaddy DNS servers. Until that happens, workaround is to setup all devices to not rely on router provided DNS.
Blocking DNS servers gets into the tricky business of common carrier status, and also actually knowing which DNS servers really are shady and which are just hijacked. Because if you block a server that’s sending shady results, you could block a legitimate service.
If you don’t trust router-provided DNS, then you really shouldn’t trust the unencrypted DNS traffic that goes through your router, either. The current defense against that is to run your own recursive DNSSEC-validating DNS server. Most domains are not DNS signed, though, and most clients do not distinguish DNSSEC results, so this is sort of hollow advice.
The claim about HTTPS not being sufficient for downloading Chrome (or anything else) is incorrect. The page cites https://cryptostorm.org/viewtopic.php?f=67&t=8713 for this, but that's a long page of nonsense.
Most likely what's happening is that HTTP resource loads are being manipulated; thus it appears to affect all browsers. Also possible is that the end-machine has been compromised some other way and the malware is attacking local programs.
As far as a user is concerned, the difference is irrelevant, but we'll never get a grip on problems if even technical pages are fear mongering.
VPN addresses a different issue not the one discussed in the article. If your router is compromised, then the encryption on the local network is useless, including that which is used to encrypt the VPN tunnel.
17 comments
[ 4.3 ms ] story [ 46.6 ms ] threadThe only problem is with the shoddy crap we call operating systems, very difficult to have them maintain radio silence until the VPN is active.
I've generally found it ok. They can serve annoying ads if you use the free service.
[1] http://www.ex-parrot.com/pete/upside-down-ternet.html
> Compromised router answers DNS req for *.google.com to 3rd party with faked HTTPS cert, you download malware Chrome. Game over.
So this is a DNS mitm? Doesn't it still require the faked cert to be signed by a trusted root CA?
/s
The worst part is that we don't know that it's happened until someone figures out that they're being MITM'ed.
Lots of people think nothing of a bounce from an HTTPS download link to an HTTP-only download link, and will happily ignore even flagrant warnings...
Root CA's have been compromised in the past, and will be again. I expect 0-day root CAs are up for sale somewhere as I type. It's not like the so-called "good guys" can't physically demand access to private keys, or big businesses can't out-right buy root trust (ex, "We need to do this on our private network - we'll never put it on the Internet, really. Here's a lot of money."). The root system is only as strong as it's weakest policies, and it's about as leaky as a steamer basket.
Even if an attacker can't get a directly useful signature, she can take control of a server already in possession of a valid cert, merely for hosting purposes (if Ubiquiti can be scammed, so can Google, as can you or I). This can be an inside job, or a one-off breach - all it takes is one click or breach of trust. (The DNS MITM tricks that work for the download can also be used to get between 2 parties higher up the trust heirarchy.)
And, of course, it is also always possible to buy a fresh, perfectly valid cert for a domain that looks close enough to pass the user test, or - quite alarmingly - one with UTF characters that combine to display in the address bar identically - or close enough - to the domain being impersonated.
That's just what comes to my mind immediately.
It's amazing any of it works at all, and arguably it doesn't. If you haven't be breached, it's probably because you haven't been targeted,
(1) You have to trust the VPN provider. Not a big problem in this case, but worth mentioning.
(2) If you have to be on your work VPN as well, you're going to have a bad time. Being only on the work VPN often isn't an option, as a lot of personal use might run into blocks and/or violate the company's policy on use of their resources.
(3) Some sites block VPNs, either intentionally or unintentionally. Just yesterday I noticed that Tumblr is blocking most (but not all) of my VPN's connection points. It's probably just an overzealous anti-DOS system rather than a deliberate block, but the effect is the same.
We really do need a better solution here. Jeff's right that home routers are a huge vulnerability. DNS and BGP hijinks are too effective and well known to leave them unaddressed any longer, and there are other issues that need to be solved as well.
3 is actually a bit of a problem, AWS IP ranges are notorious for being widely banned.
If you don’t trust router-provided DNS, then you really shouldn’t trust the unencrypted DNS traffic that goes through your router, either. The current defense against that is to run your own recursive DNSSEC-validating DNS server. Most domains are not DNS signed, though, and most clients do not distinguish DNSSEC results, so this is sort of hollow advice.
Most likely what's happening is that HTTP resource loads are being manipulated; thus it appears to affect all browsers. Also possible is that the end-machine has been compromised some other way and the malware is attacking local programs.
As far as a user is concerned, the difference is irrelevant, but we'll never get a grip on problems if even technical pages are fear mongering.
I thought it was funny that that comment is on a http:// website.