Netgear Signed TLS Cert Private Key Disclosure • Hacker News Board

Re: Netgear Signed TLS Cert Private Key Disclosure

#121

Post by wbl » Mon, Jan 20, 2020, 4:35 PM UTC

lima wrote: post #102

josteink wrote: post #58

To all the people shitting on Netgear and security in this thread, just how do you propose one deliver a secure network appliance to end customers which they can deploy on their network? And which is user-accessible to common users in modern browsers rejecting everything not touched by a proper CA? Really. Please educate the world with your ingenious insight. I’ll be waiting. The unavoidable truth is: You have to stu…

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.

Re: Netgear Signed TLS Cert Private Key Disclosure

#122

Post by gsich » Mon, Jan 20, 2020, 4:35 PM UTC

regecks wrote: post #2

6 days is nowhere near a justifiable timeframe for full disclosure. Even if you disagree with that, you should have first reported Key Compromises to Entrust and Comodo before publicly posting the private keys. They are bound by BRs and their own CPS to revoke certificates such as this one - and they would have done so promptly. This is not what you should do as a security researcher - delete the gist until the CAs h…

Who cares, this does not even warrant a responsible disclosure. Netgear can't fix that in a way that makes everyone happy. You can revoke the cert, then what? A firmware update with a new cert? Same problem, private key will still be on the device and in the firmware file. Self signed? You get users crying about the cert. HTTP only? You get users crying about "not secure" even though that might not be true in all cases.

My guess is that people before the ones in the gist have tried to contact Netgear about this (since it's not hard to find) and chose to ignore it.

Re: Netgear Signed TLS Cert Private Key Disclosure

#123

Post by creeble » Mon, Jan 20, 2020, 4:40 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.

Except for the browser complaint when filling out the form.

I have to agree with the calls for allowing warning-less HTTP for LAN connections.

Edit: Add last sentence.

Re: Netgear Signed TLS Cert Private Key Disclosure

#124

Post by gsich » Mon, Jan 20, 2020, 4:47 PM UTC

CiPHPerCoder wrote: post #45

mschuster91 wrote: post #10

The HTTPS cert is used for the router's login page - apparently putting an IP address on the box backside label confuses too many people. It makes sense to put it behind HTTPS because the browser will whine "this page is insecure"... but how is a router vendor supposed to include the neccessary certificate that won't get leaked? The only thing I can imagine here is a dedicated HSM chip... but that's overkill for a 10…

No, you can do something like CloudFlare does for TLS for their enterprise customers, where the TLS session is signed by a key held by Netgear. https://www.cloudflare.com/ssl/keyless-ssl The fallback would have to be self-signed TLS with random keys for initial local router configuration, which is hopefully done over an Ethernet connection rather than WiFi. You don't need a secure enclave or HSM to solve this problem…

You need a working internet connection. In most cases you go to the webinterface because you are either setting it up, or something (most likely connection) doesn't work.

Re: Netgear Signed TLS Cert Private Key Disclosure

#125

Post by gsich » Mon, Jan 20, 2020, 4:49 PM UTC

creeble wrote: post #123

wbl wrote: post #121

Earlier quoted context omitted.

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

Except for the browser complaint when filling out the form. I have to agree with the calls for allowing warning-less HTTP for LAN connections. Edit: Add last sentence.

This is not a hard-stop like the TLS warning pages. So not a "big" issue.

Re: Netgear Signed TLS Cert Private Key Disclosure

#126

Post by zelon88 » Mon, Jan 20, 2020, 4:55 PM UTC

ryanlol wrote: post #48

CiPHPerCoder wrote: post #46

Some commenters are decrying that this post fails to meet the bar for "responsible disclosure". Please stop using that phrase. "Responsible disclosure". It's wrong and harmful , and the person who coined it agrees with me: https://adamcaudill.com/2015/11/19/responsible-disclosure-is... You want "coordinated disclosure" instead. Netgear doesn't do coordinated disclosure. They do non-disclosure. In the absence of a coo…

It should be noted that it’s essentially never the people who find bugs arguing for “responsible disclosure”. It sure is easy to tell others what to do with their work product when you have zero stake in the game. There exists a really easy solution to the purported problem of full disclosure, vendors could just offer significant enough financial compensation for non-disclosure.

Let's take that avenue as a thought experiment...

1. Netgear buys the bug.

2. They keep shipping firmware with a private key.

3. Someone with malicious intent finds it.

4. Someone with malicious intent MITMs a Netgear network and does something bad.

5. Bad actor sells bug online.

6. Millions of Netgear devices continue operating with compromised certs.

Instead, here's what happened/happens now...

1. Researcher tries to coordinate with the vendor, realizes NDAs are involved and the vendor intends to keep shipping their private key.

2. Researcher dumps details of private key on GH instead.

3. Mozilla and Google stop trusting the cert.

4. Now Netgear no longer gets to decide if they want to fix the problem. Browser vendors have fixed it for them.

5. Millions of otherwise insecure Netgear devices are protected by the browser instead.

6. Netgear rightfully gets bad press and hopefully the shaming makes them rethink their positions on NDAs in their bug-bounty program.

7. Future bug hunters submit bugs straight to a receptive Netgear, who has learned a valuable lesson about being a lazy hack.

Re: Netgear Signed TLS Cert Private Key Disclosure

#127

Post by mook » Mon, Jan 20, 2020, 4:56 PM UTC

gene91 wrote: post #88

Netgear picked a terrible and clearly unacceptable approach. I I read through this discussion, trying to understand if there exists a good solution. Using plain http isn't a good solution because it involves telling the user to ignore the "not secure" warnings by browsers. This seems like the best available solution. Without network connectivity, the traffic can not be tunneled through a remote server with proper cer…

Unfortunately this is a problem that's mostly a result of the browser vendors (who are in control of the validation/UI), and can't be fixed by Netgear / etc. They've decided that security trumps usability.

I suspect at done point the router manufacturers will give up and just force setup through a phone app (assuming you could download it over a cellular connection). That makes me sad, though.

Re: Netgear Signed TLS Cert Private Key Disclosure

#128

Post by fulafel » Mon, Jan 20, 2020, 4:56 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…

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

Re: Netgear Signed TLS Cert Private Key Disclosure

#129

Post by actionowl » Mon, Jan 20, 2020, 5:15 PM UTC

fulafel wrote: post #128

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…

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.

Communicating upstream to a third party to get a cert won't work for all users (e.g. those that need to configure a static IP from their ISP.)

Re: Netgear Signed TLS Cert Private Key Disclosure

#130

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

jniedrauer wrote: post #113

gene91 wrote: post #110

Earlier quoted context omitted.

Encryption-only TLS doesn't protect MITM. It prevents sniffing. At a higher level, TLS provides integrity and privacy when the network linked is not trustworthy. As a result, I'm not sure what your proposal achieves. Similarly, resolution by IP address does not provide privacy or integrity unless you trust the network link.

The green padlock indicates two things about the server to the user: "This is really my name" and "no one can snoop on our conversation." It doesn't indicate anything about the trustworthiness of the server. The first one is meaningless in the context of an IP address. If a user is going to get pished by an IP address, then they could just as well get phished by 123.sketchydomain.com. The important part when communic…

> The important part when communicating directly with a device by IP address, is that the payload is encrypted end to end.

Which you can't be certain of unless you can verify where the "end" actually is. The IP address is no help here; the ARP cache can't be trusted. Packets can be redirected to any host on the local network regardless of the official IP address assignments. If you aren't authenticating the other end of the link then you can't be sure no one is snooping. Active MitM attacks on local networks are trivial. You don't even need to compromise the router—any peer on the network will do.

> The router could forge a self signed certificate even more easily than it could forge a certificate signed by a trusted CA.

Sure. As a form of TLS without authentication, one-time-use self-signed certificates would be worse than useless, offering only a false sense of security. The options here are "trust on first use" (betting against a malicious actor being present during initial setup) or offering some way to manually verify the fingerprint of the device's private key. Both approaches require authentication, not just encryption. For the second, more secure option, the cheapest way would be to permanently provision each device with a unique private key and print the key's fingerprint on the device's exterior. For more flexibility, store the key in a small removable HSM (similar to a SIM card) and print the fingerprint on the HSM itself and/or the accompanying documentation.