Netgear Signed TLS Cert Private Key Disclosure • Hacker News Board

Re: Netgear Signed TLS Cert Private Key Disclosure

#131

Post by nybble41 » Mon, Jan 20, 2020, 5:36 PM UTC

wbl wrote: post #121

lima wrote: post #102

Earlier quoted context omitted.

This. Yes, Netgear has a bad track record with security, but this is likely a calculated trade-off. Alternatives: - Self signed certificates. Users will learn to acknowledge the error and an attacker can just present their own self-signed cert. This what most vendors do. - Plain HTTP. Worst option, no security, not even against a passive listener (but no bad PR because of "security disclosures"... hooray!). - Somethi…

Plain HTTP is fine because the IP is a site-local.

So you trust every cheap IoT device connected to your local network? The LAN may be a slightly less chaotic environment than the open Internet, but that doesn't make it "safe". With a bit of ARP trickery any device on the LAN can intercept traffic intended for any other local device and carry out an active MitM attack—and with HTTP you don't even get the benefit of "trust on first use" that you'd get with a persistent self-signed certificate.

Re: Netgear Signed TLS Cert Private Key Disclosure

#132

Post by xg15 » Mon, Jan 20, 2020, 5:44 PM UTC

actionowl wrote: post #120

HTTP(S) might just be the wrong protocol for initial setup of a router! Maybe instead generate a password for each router and print it on the box along with the device's unique SSH Key fingerprint. Technical users can then SSH in and bootstrap the system (also generate/upload their own TLS certs if they want to use a browser and connect over HTTPS, etc). Non-technical users get an app and they can scan a QR code on t…

> Non-technical users get an app ...

So now I need an already-working smartphone to set up my internet connection.

Re: Netgear Signed TLS Cert Private Key Disclosure

#133

Post by xg15 » Mon, Jan 20, 2020, 5:53 PM UTC

> These certificates are trusted by browsers on all platforms, but will surely be added to revocation lists shortly.

So what about all the routers that were already sold and the customers that bought them?

Are we ok with leaving all devices that are already in operation or that are currently being sold unconfigurable for non-technical users, just to protect against a highly hypothetical scenario of abusing routerlogin.net?

Re: Netgear Signed TLS Cert Private Key Disclosure

#134

Post by fulafel » Mon, Jan 20, 2020, 5:56 PM UTC

actionowl wrote: post #129

fulafel wrote: post #128

Earlier quoted context omitted.

I think https could work fine, just give each device a unique key and dns name.

That approach has been mentioned in the comments. Some problems with it are: If a certificate is valid beyond 825 days Chrome will not honor it. So if you generate a key and cert at the factory for every device you run into the issue of the end-user getting a device with an expired cert. If you generate a unique key and self-signed cert users will complain and call support about the "insecure" site warning. Communica…

You shouldn't plug something with more than 2 years of missing security updates to the internet anyway (or sell it). Reflash & restock time by then.

Re: Netgear Signed TLS Cert Private Key Disclosure

#135

Post by tracker1 » Mon, Jan 20, 2020, 6:48 PM UTC

ryanlol wrote: post #79

JshWright wrote: post #59

Earlier quoted context omitted.

I think the millions of people with Netgear equipment deployed have some "stake in the game". How does non-disclosure benefit them?

I have zero sympathy for end users who aren’t willing to hold the vendors accountable. And besides, there’s nothing stopping the millions of end users from offering their own bribes in order to get shit fixed. $10 from each would go very far.

They already gave their "bribes" to get it fixed, by buying a product and expecting a reasonable level of support.

Personally, I haven't liked most Netgear hardware I've tried... but since the FCC cracked down on open firmware for consumer gear, options are really limited with most vendors.

Re: Netgear Signed TLS Cert Private Key Disclosure

#136

Post by dlgeek » Mon, Jan 20, 2020, 6:52 PM UTC

cipherboy wrote: post #94

tialaramex wrote: post #83

Earlier quoted context omitted.

Because this post is specifically a found private key for a certificate in the Web PKI it was not necessary to post that key in order to achieve all the positive consequences of public disclosure. The key only enables negative consequences. I could give some leeway to a grey hat who finds the data but doesn't understand what it is and posts it. "Hey, what's this blob of data?". But this poster clearly understands it'…

Yeah, but remember how they found it? On Netgear's website! In their firmware images! It wasn't like they had to hack a router, get root, and exfil the keys. All of this data was already made public, by Netgear! They just put together a document with prettier forms for everyone else to see. Hell, they probably could've given you a shell one liner to grab it from Netgear and extract the keys yourself. :-) Edit: and th…

It's still not, as of the time of this comment: https://crt.sh/?id=1955992027&opt=ocsp

Re: Netgear Signed TLS Cert Private Key Disclosure

#137

Post by CiPHPerCoder » Mon, Jan 20, 2020, 6:56 PM UTC

lima wrote: post #104

CiPHPerCoder wrote: post #93

Earlier quoted context omitted.

What do you mean "without providing any kind of meaningful security benefit"? It prevents a bored kid who dumps the private key from one router from being able to reliably impersonate thousands of consumers' routers, the world over. That's a meaningful security benefit.

The attacker would just dump the individual router's key instead and use the remote signer as a signing oracle to impersonate devices.

The owner/operator of the router could do that to their own device, yes.

The idea is that each router would get a certificate signed with a distinct subdomain unique to that router. So you still can't impersonate other devices. It wouldn't be a generic domain or wildcard certificate.

The remote signer would furthermore suspend suspicious connections (i.e. from multiple public IP addresses).

Re: Netgear Signed TLS Cert Private Key Disclosure

#138

Post by jsjohnst » Mon, Jan 20, 2020, 7:03 PM UTC

shock wrote: post #53

bottled_poe wrote: post #37

Netgear has reliably demonstrated to me over more than 10 years that they are incapable of delivering secure products of an acceptable quality. I actively avoid this brand like the plague.

I have posted this in another thread, but I am posting it again because more people need to be aware of Netgear's practices: I recently bought a couple of Netgear Managed Switches (for Business)⁰ and in their datasheet they list "Local-only management" as a feature. Only after they arrived we discovered that you only get limited functionality in the Local-only management mode, you have to register the switches to you…

Interesting. I’ve got a bunch of (older) Netgear GS-108s and it’s definitely entirely locally managed. Good to know I shouldn’t buy any newer ones, thanks for sharing!

Re: Netgear Signed TLS Cert Private Key Disclosure

#139

Post by dependenttypes » Mon, Jan 20, 2020, 7:43 PM UTC

air7 wrote: post #117

m-p-3 wrote: post #97

Earlier quoted context omitted.

Agreed, the key was already publicly available, and it was just a matter of time for someone with malicious intent to find it if that's not already the case. Exposing something already public to speed up the resolution and make sure the impact is kept to a minimum considering the circumstances.

Well, one can argue that every vulnerability is "already publicly available, and just a matter of time for someone with malicious intent to find it"

This is correct, which is one of the reasons that I personally support full disclosure for everything.

Re: Netgear Signed TLS Cert Private Key Disclosure

#140

Post by mschuster91 » Mon, Jan 20, 2020, 7:48 PM UTC

zonidjan wrote: post #71

moviuro wrote: post #32

Earlier quoted context omitted.

Number 2: already dealt with: * .test * .example * .invalid * .localhost http://www.rfc-editor.org/rfc/rfc2606.txt

What? No. While those are meant to be reserved, nothing stops you from configuring your resolver to answer for them.

Yes, but users will not be happy if they see ".example" on the URL bar. And you can't get a trusted cert for them either.

Not confusing users is why the fiasco with the https certificate problem here was initially created. And to be honest I do not have any idea how all needs (users have a trusted HTTPS certificate, a domain name and no "insecure" oe other warnings in the browser, while hackers don't get access to the certificate, and all of it works without internet uplink) can be met...