I don't see how this 'man' in the middle could actually intercept passwords, except for http, but who runs auth over http anyway. For https, the 'man' would have to substitute its own certificate and then the browser / client software wouldn't trust the cert/domain combination without the end user being extremely stupid (and knowledgeable enough to achieve the stupidity).
It could use something like bdfproxy[1] to intercept HTTP-downloaded EXE files, then add some persistent malware in _addition_ to whatever the EXE was doing. This has been done before, over Tor[2].
The malware doesn't have to add a new root certificate, either, though that's completely possible. The Zeus trojan [3] does "man-in-the-browser" to intercept banking information, for example.
so the spoofer distributing these devices is going to all this trouble/expense/risk in the hope there is a http downloaded exe it can corrupt, then hopes the hashing doesn't fail on that corrupt exe, and hopes the user ignores the untrusted source warning so that it can install a trojan?
I think what he means is that it seems like a lot of trouble to hack someone who is not necessarily hackworthy? Like what kind of things would you expect to gain from someone who would be as computer illiterate as to allow all that to come to fruition?
I work on a software company. You would be amazed to know how many manager types, earning 6 figures, who are absolutely naive with regards to security. Those are prime targets for this kind of exploit.
These are the same users who connected an untrusted block of hardware directly to their router and presumably gave them a their Facebook login and password.
SSL stripping perhaps? There are still plenty of sites that don't implement HSTS, and not all users are vigilant enough to notice when the site they're visiting suddenly doesn't have HTTPS anymore.
Web security has been improving a lot in recent years, but it's not yet at the point where a man in the middle isn't a relevant threat.
You type in http://yourbank.com, your bank respomds with a 301 to https, but this helpful router instead takes you to its phishing site. Lots of people wouldn't notice.
CA's are fully automated, they won't review or check for phishing lookalikes. Maybe reactively if it's being reported, but, should they operate as the internet police? What if it's a legitimate bank that has the same name (with an accent) and isn't beholden to the same trademark in their country?
+ It may seem like it is if your organisation gets a bunch of EV certs with the same organisation info under some bulk deal. The issuer only does the expensive manual EV steps once per period, if you're Google in January then (the thinking goes) you are still Google in June. This saves them money so it enables them to offer pretty good deals for lots of EV certs.
+ Good EV providers streamline the manual stuff in countries like the US that have their government records online. A call centre employee can do the searches, pull up contact details and phone your Head Office or whoever to confirm in minutes not hours. However this also means they won't necessarily pick up on subtle clues like why is this outfit named Myba N K ? Oh! That's My Bank but with misleading capitalisation and spacing.
+ White hats toying with EV discovered that outfits like D&B relied on in the business community to verify identity are... Not very reliable. If D&B says the Head Office is at 632 Wall Street that might be because somebody filled out a web form, not because D&B agents even checked 632 Wall Street exists let alone that the company has offices there...
The spoofer can obtain a valid certificate for another, seemingly legitimate site. Any software that hasn't explicitly pinned the leaf TLS certificates will still accept the (valid) certificate it is redirected to.
And sadly, a lot of software still doesn't perform certificate pinning.
This will seem like a valid website, especially if the phishing site is done well. Not just non-technical users, I'd wager some tech familiar users would be fooled too.
The focus always being on the lock icon might not always cover it.
I think Chrome for a while has simply refused to let you visit a page when there's an SSL problem (at least for certain types of problems), which seems like a reasonable solution to the "people will just ignore warnings" problem.
