81–90 of 158 posts
Sure, Entrust is required to revoke it. It is bound by BRs. If it refuses, Entrust will get itself blacklisted by browsers. On the other hand, having the cert revoked will cost Netgear dearly. As a result, I wonder if Entrust might be dragging its feet on the revocation.
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…
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…
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's a private key for a certificate in the Web PKI.
You can disclose the fact that you know a private key that isn't yours without revealing the key by various methods, but one that's very easy for non-experts is to create a bogus CSR. Just tell OpenSSL (or a tool that's actually good) that you have this private key and you want to request a certificate for it. Give bogus details, for example in the Common Name of the proposed certificate you can explain this is a Netgear key you found.
You can now publish the CSR, it is inherently proof that you've got Netgear's private key but it does not contain that key and so black hats will need to do their own work, for which you are certainly not responsible, to get that key from a Netgear box if they want to.
It would also make sense to tell the issuing CA, you should send them that CSR, although it's not terribly harmful to send them the actual private key and I guess if you're worried the CA's representatives don't "get it" this is a very blunt way to make your point. If the issuing CA doens't respond, tell m.d.s.policy both that you found this key and that the CA did not respond, and if necessary that can be escalated until the CA is distrusted (by Mozilla, and in my experience eventually everybody for reasons we'll not think too hard about here).
In the case of Let's Encrypt the process is, like everything else, fully automated. Call the API (by running your client software of choice) and prove you know the private key for a certificate they issued and want it revoked, its status changes to revoked and the next batch of OCSP signatures will show revoked for that certificate.
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 was answered on the Gist in a comment[0] linking to a tweet[1]: Things to do instead of shipping TLS certs and static private keys to consumer-grade routers you sell by the thousand: Generate a unique keypair per device. Use this keypair to communicate upstream, in a similar fashion to CloudFlare's Keyless SSL. This keypair you generate on the device would need to be preloaded at the factory, unique per device,…
Same level of security, and a lot of extra complexity and cost.
On the other hand, making private keys publicly available is obviously far from ideal.
Damned if you do, damned if you don't. Again, I don't envy Netgear...
Is this cert revoked yet? Sure, Entrust is required to revoke it. It is bound by BRs. If it refuses, Entrust will get itself blacklisted by browsers. On the other hand, having the cert revoked will cost Netgear dearly. As a result, I wonder if Entrust might be dragging its feet on the revocation.
Earlier quoted context omitted.
> How does non-disclosure benefit them? And how does dumping the vulnerability without a fix help Netgear owners? They're all flapping in the wind right now. IMHO, the best scenario is coordinated disclosure. Full disclosure may be necessary to force a vendor to do something, but let us not pretend it is a good thing.
> And how does dumping the vulnerability without a fix help Netgear owners? It lets us know to buy another brand immediately and never buy Netgear again. > IMHO, the best scenario is coordinated disclosure The original post said that Netgear doesn't do coordinated disclosure, and subsequent posts were arguing whether non-disclosure or full disclosure were better. Nobody was disagreeing with what you said.
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 cert. Nor can the box request a cert in realtime at the time of setup.
Pre-provisioned cert won't work if the box is purchased more than 27 months after manufacturing (the current max validity period). For home network equipment, I suppose this isn't unusual.
I see TLS-SRP mentioned in comments. But the commenter hinted at its limited adoption in browsers.
Earlier quoted context omitted.
That isn't what disclosing these sort of vulnerabilities is about. The core reason for just going full disclosure is that the vendor has absolutely not incentive to fix any sort of bug that is kept private. The customer is impacted, never the vendor.
Nah, disclosing these vulnerabilities is usually about CV-padding and publicity . There aren’t many people out there hunting bugs just to be nice.
Is this his best work? Nah, this is amateur hour on the part of Netgear. But am I glad it was him who found it? Definitely.
Keep in mind, there really wasn't anything _to_ this vulnerability other than copying and pasting from one website (and a firmware zip) to another. They just added a little pretty formating and saved you the trouble of extracting the firmware.
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…