[amckinlay]

I still don't understand how this device could steal login details. Everything should be encrypted and authenticated through PKI when using any website that accepts 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.

[hguant]

>Everything should be encrypted and authenticated through PKI when using any website that accepts login details.

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.

[jugg1es]

I'm disappointed that's not a real website

[westpfelia]

It is a real website he just got the URL wrong. Its supposed to be https://www.chase.com/

[EADGBE]

I live for these kind of zingers!

[gorgonian]

Of course it's not real. Its a subdomain of chase.com. Parent should've said something like chase.evil.com.

[tomsmeding]

If the user hasn't visited the subdomain evil.chase.com yet, a http downgrade attack (https://news.ycombinator.com/item?id=18090419) would maybe work.

[hunter2_]

That's not a downgrade, but a lack of upgrade. A few comments back said https://evil but it would have to instead be http://evil assuming no rogue root cert is installed.

And requires that if the user had visited chase.com, that chase.com not have includeSubdomains in their HSTS header.

[deaps]

So to prevent a downgrade attack before a first connection is made, not only does the domain need to "includeSubdomains" - and have a valid lifetime (maybe of at least 31536000 seconds, or 1 year [this may just be a government standard]), but they'd also have to send the preload directive in their HSTS header and have been preloaded by that browser platform. If the domain is not preloaded, that first connection is required to get the HSTS information to the client in the Strict-Transport-Security header.

[hunter2_]

Perfectly valid cert how? Assuming no theft of a chase private key.

[hguant]

Perfectly valid cert for the evil.com domain - someone below pointed out that I flipped the domain names.

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".

[SamBam]

Huh? "https://www.login.chase/login?id=DEADBEEF/.evil.com" wouldn't go to evil.com, it would go to login.chase. "chase" is the TLD of that URI.

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.

[notriddle]

Assuming they're not doing anything weird with Unicode, the evil pi is probably running its own DNS server, intercepting the traffic intended for normal DNS, and basically creating its own TLD the same way you would normally do localdomain. The evil.com part is redundant.

[SamBam]

Sure, that's a totally different scenario than tricky-looking urls.

[closetohome]

This seems...a little unnecessarily pedantic. It's an example of a well-known URL obfuscation technique -- we all understood what he meant.

[ttty]

For example you can go to my http://website.com now the normal website has a HTTPS redirect on home page. Your router replaces that page and disables the redirect. Now is up to you to notice you're on a http connection.

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).

[implying]

This is why certificate pinning and modern web security practices are so important. On a well configured site, this attack would fail.

[nielsole]

If you had never visited the site, how would modern security practices have prevented the attack?

HSTS is useless in this case isn't it?

[peterwwillis]

Correct. HSTS does not protect against a first visit to a site. And to work around HSTS, there are many ways to get users to clear their caches, install new browsers, or use new devices to browse sites they've already visited.

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.

[hrrsn]

Many sites can be included as HSTS only in Chrome itself, so it wouldn't be entirely useless.

https://hstspreload.org

[Avamander]

Anyone can preload their domain in Chrome, Firefox and others that share the preload list. I'm not sure what vulnerabilities are left after your site has been preloaded.

[deaps]

The only vulnerability left would be, as mentioned above, a client installing a browser that doesn't support HSTS.

[deaps]

No. If the domain (and its subdomains) are preloaded - then a first visit is not required. The HSTS requirement is then baked into a list supported by modern browsers such as Firefox and Chrome.

[Boulth]

Preloading always include subdomains (it's not possible to preload just tld).

[nsgi]

HSTS and Certificate Transparency, yes. Certificate Pinning is too easy to shoot yourself in the foot with, so it should only be considered for the most sensitive sites.

[Boulth]

Dynamic pinning (HPKP header) is being rolled back from browsers because of the reasons you mention. Only a small set of static pins will remain (in Chrome, Google sites for example).

[83457]

I think the idea is that it could proxy communication. Mitm

[rootw0rm]

you still have to install the proxy certs

[mjevans]

Pick your favorite windows 0-day and use it to only install a cert and nothing else that would tip off AV software.

[alangpierce]

Are Windows 0-days really that common? I thought they were usually saved for really serious attacks, e.g. from state-sponsored actors, not scams on the level of "pay some random person $15 a month to attach a mysterious device to their router".

[eponeponepon]

I can't answer your question authoritatively, but there are plenty of organised criminal enterprises in the world with state-level resources.

[floatboth]

Not just a question of state-level-ness, but of targeted/mass. Burning a 0day on a mass scam is really, really stupid.

[avhon1]

Not only that, but because the device has unfettered access to the internet, an attacker can always update it with new ways of installing certificates on your machine.

[moviuro]

You don't even need 0-days, as most users hate updates and try to disable them, every single time.

[wstuartcl]

Assume one of many attack vectors:

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.

[nsgi]

HTTPS protects against all of these:

> 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.

[wstuartcl]

>HTTPS protects against all of these: >Which is why everyone is moving to HTTPS.

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.