|
|
|
|
|
by nsgi
2815 days ago
|
|
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. |
|
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.