Yes, everything SHOULD be like this. I should be able to trust my neighbors and leave my doors unlocked as well, and I should be able to have faith in my elected officials. And yet...
The other issue is that you can connect to a website that implements HTTPS correctly, and still be borked if that site doesn't implement HSTS properly - there are tools that implement HTTPS downgrading on Kali.
>I still don't understand how this device could steal login details...Whenever I visit a website with an expired certificate, for example, Chrome gives me a big red warning banner before allowing me to continue to the site.
The problem comes when your corrupted router messes with DNS and sends you to https://evil.chase.com, which has a pixel perfect mock up of a chase bank login screen, and a perfectly valid cert.
And requires that if the user had visited chase.com, that chase.com not have includeSubdomains in their HSTS header.
In reality the "evil" page would look something like "https://www.login.chase/login?id=DEADBEEF/.evil.com". For a non-trivial number of users, that's enough - "I see the nice green lock, I see chase, and some crazy web address characters that are always there".
Unless you're doing something super clever with characters that I'm not understand, that's not how urls work. ".evil.com" is clearly part of the query parameter.
If you think is rare, I can tell you some fortune 500 FX and stocks trading have this vulnerability a year ago (didn't checked again).
HSTS is useless in this case isn't it?
Technically, if the domain had DNSSEC enabled, it might prevent this kind of attack, but no regular consumer is using a validating stub resolver, so even DNSSEC wouldn't work.
Now that browsers are saying "Not Secure" by default for HTTP pages, users are apparently expected to notice this popping up where it didn't before and realizing they're on a phishing site.
any site that is loaded via http can have content mutated -- forcing users to http (and then acting as MITM), injecting javascript, other payloads.
If you can get a foothold on client computers you can also do things like inject trusted CA's to allow yourself to act as MITM without any cert issues raised.
DNS can be mutated.
Auto update software that does not check the cert chain and hash of the deliverable can be used to inject and run code.
...
Hundreds (if not thousands) of repeatable attack vectors given physical access to the network like this.
> any site that is loaded via http can have content mutated -- forcing users to http (and then acting as MITM), injecting javascript, other payloads.
Which is why everyone is moving to HTTPS.
> If you can get a foothold on client computers you can also do things like inject trusted CA's to allow yourself to act as MITM without any cert issues raised.
If you get access to the client computer all bets are off. You can just force all their traffic through a MITM proxy, no router hacking needed.
> DNS can be mutated.
Which won't allow you to MITM HTTPS sites.
> Auto update software that does not check the cert chain and hash of the deliverable can be used to inject and run code.
Any auto update software which doesn't verify certificates has a major security vulnerability.
Yes, but a MiTM can block or hamper conversion to https and mutate the content. HPKP and HSTS are not widely used yet (and even if they are the first request can be bypassed given this topology). Given current "end user" level protections having a device such as this on your network basically ensures you can be hijacked if even one request made is over https or not currently pinned to HTTPS.
>If you get access to the client computer all bets are off. You can just force all their traffic through a MITM proxy, no router hacking needed.
FFS, the point is the MITM gives a huge amount of attack surface to breach the client -- which yes, after that is done you lose all bets. Everything from injecting code intip zips/exec/etc downloaded over http to using 0day browser exploits and mutating requests. The device itself is physical access to your network which makes access to the clients 1000x 9if not more) easier.
> DNS can be mutated.
There are other protocols besides HTTPS.
>Any auto update software which doesn't verify certificates has a major security vulnerability.
Given, Yes. That does not make it rare or unusual. look at the CVS. There are many developers that write (or enable) auto updaters that should not be responsible for that given their understanding of security.