3 ms·

> it seems like the majority of them are either local privilege escalation or exploit a listening service, all of which won't much affect the typical situation

> it seems like the majority of them are either local privilege escalation or exploit a listening service, all of which won't much affect the typical situation of a single-user PC behind a NAT with no forwarded ports and a user who won't be downloading and running random binaries from strangers Browser exploit chains often end up attacking the kernel or local services as part of escaping the sandbox, so it's important to patch these vulnerabilities. > Fortunately, the truly scary scenario of an attacker taking control over the Internet of a machine that is just left on and with no action needed on the part of the user seems quite rare; in fact, something like that would be very memorable, yet I don't remember any in at least the decade. EternalBlue, which exploited a vulnerability in SMB, is probably the most prominent example in recent times. BlueKeep, an RDP exploit, was another serious threat from earlier this year.

userbinator 7y ago
Yes, browser exploits are always worrisome, which is partly the reason I have JS off by default. RDP and SMB aren't exploitable from the Internet if you're behind a NAT
- infosack 7y ago
  > Yes, browser exploits are always worrisome, which is partly the reason I have JS off by default. That is your personal preference of course, but it's highly atypical for any user to have JavaScript disabled. I was just pointing out that the attack surface isn't limited to downloading and running random binaries. > RDP and SMB aren't exploitable from the Internet if you're behind a NAT Unless they've forwarded the ports. But either way there are millions of hosts with RDP and SMB exposed (e.g. Shodan reports 5 million of the former and 1.5 million of the latter).
  - userbinator 7y ago
    Exploits or not, exposing those services to the Internet is a bad idea. If it weren't for NAT that number would probably be much higher...
    - z3t4 7y ago
      If you are a developer, make sure you make your app secure by default, eg. not listening on a public IP using a standard password. Don't fall in the trap of insecurity by convenience. Too many developers expect users to have NAT, that's why we can never adopt IPv6 for end users, and IoT will never take off until we get our shit together and make our software secure.
- EvanAnderson 7y ago
  The "behind a NAT" argument fell apart back in the days of the Nimda worm (2001) in my experience. I saw multiple environments where vulnerable machines were infected when portable computers became infected while attached to third-party networks and were subsequently brought back "behind the firewall" to infect other machines. The lack of defense in depth, lack of segmentation, and the general "soft, chewy center" of most networks is arguably the cause to blame. Still, most third-party networks I see even today are this way.

userbinator 7y ago

Yes, browser exploits are always worrisome, which is partly the reason I have JS off by default. RDP and SMB aren't exploitable from the Internet if you're behind a NAT

infosack 7y ago
> Yes, browser exploits are always worrisome, which is partly the reason I have JS off by default. That is your personal preference of course, but it's highly atypical for any user to have JavaScript disabled. I was just pointing out that the attack surface isn't limited to downloading and running random binaries. > RDP and SMB aren't exploitable from the Internet if you're behind a NAT Unless they've forwarded the ports. But either way there are millions of hosts with RDP and SMB exposed (e.g. Shodan reports 5 million of the former and 1.5 million of the latter).
- userbinator 7y ago
  Exploits or not, exposing those services to the Internet is a bad idea. If it weren't for NAT that number would probably be much higher...
  - z3t4 7y ago
    If you are a developer, make sure you make your app secure by default, eg. not listening on a public IP using a standard password. Don't fall in the trap of insecurity by convenience. Too many developers expect users to have NAT, that's why we can never adopt IPv6 for end users, and IoT will never take off until we get our shit together and make our software secure.
EvanAnderson 7y ago
The "behind a NAT" argument fell apart back in the days of the Nimda worm (2001) in my experience. I saw multiple environments where vulnerable machines were infected when portable computers became infected while attached to third-party networks and were subsequently brought back "behind the firewall" to infect other machines. The lack of defense in depth, lack of segmentation, and the general "soft, chewy center" of most networks is arguably the cause to blame. Still, most third-party networks I see even today are this way.