The Internet of Compromised Things
blog.codinghorror.com
blog.codinghorror.com
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.
> 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.
The 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.
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.
I thought it was funny that that comment is on a http:// website.