6 ms·
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 a
by regecks 7y ago
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 have a chance to revoke it via OCSP.
- mjevans 7y agoI think in this case it's to force browser vendors (who have the most exploitable endpoints) and companies like Apple and Microsoft at the OS level, to blacklist the offending certs. Though the CAs in question should probably have an automated challenge-response system to which a timed signed reply of a given message of their choice causes a revocation of the key that signed the message. (As sufficient proof of "this is vuln, kill it now, ask questions after".)
- toast0 7y agoDid this researcher even contact the CAs? Generally, they're pretty responsive and will revoke quickly; there are CA/Browser forum guidelines that address this; if nothing else, you can send them the private key to prove possession.
- buraksarica 7y agoThe OS level actions won't be fast. So this disclosure is closer to an irresponsible attitude. At least CAs should be informed.
- philprx 7y agoI tend to differ: Netgear security is paid to manage security. They failed by not responding to these legitimate communications requests. The researcher are not paid. They did what could be done to really fix the problem. Of course you can always do better as a researcher, always, but consider time available and paid vs. pro bono time. Also consider all the people who probably found this before and may have sold it on black market, you’re attacking the wrong people.
- RL_Quine 7y ago> 6 days is nowhere near a justifiable timeframe for full disclosure. Of course it is, if you didn't get a response in the first 48 hours you're not going to, that's the way things like this tend to operate. The security contact for all companies is either a) inactive or b) very active. It's a detriment to everybody that for some reason it has been normalized that people should wait months or years for disclosing bugs. Full disclosure is the only way things get fixed. > This is not what you should do as a security researcher - delete the gist until the CAs have a chance to revoke it via OCSP. Github is archived in real time for the most part. Especially you'll notice that if you post a private key for a cryptocurrency address or credentials for AWS, it'll be stolen and used within seconds. There's some really good sets of information out there like https://www.gharchive.org/ https://www.gharchive.org/ which give you an idea of the sheet amount of data that github produces on a daily basis, and that's just the metadata and things like comments rather than actual git repository contents. The idea that you could delete something from there and have it actually "removed from the internet" is amusing.
- gdm85 7y agoThere is another reason why responsible disclosure would have been better (and less short-sighted): vendor might make an internal audit, find root cause and invalidate a bunch of certificates at once (think about similarly leaked certificates due to a bug in some deployment tool). Now it's an open race with the bad guys, and surely a lot of them all at once; hardly an advantageous scenario for end users.
- JshWright 7y agoThat's an awfully big (and awfully optimistic) "might" in your first paragraph there...
- StavrosK 7y agoNot to mention that all the bad guys had to do to get the private key was unpack the firmware image, so they've probably noticed long ago.
- gdm85 7y agoIt's not optimistic, it's what a responsible vendor is supposed to do. By not following responsible disclosure the researcher has lifted the vendor from the possibility of organizing a proper response.
- gdm85 7y agoBy the way, I meant coordinated disclosure and I am not aware of Netgear not doing any at all, never.
- kick 7y agoResponsible disclosure is meant as a way to harm researchers and users for the benefit of companies. This is absolutely the right thing to do as a security researcher, especially given that Netgear prevents public disclosure, ever, if you submit a bug bounty. To make sure it stays online: https://web.archive.org/web/*/https://gist.github.com/nstarke/a611a19aab433555e91c656fe1f030a9 https://web.archive.org/web/*/https://gist.github.com/nstark...
- yardstick 7y ago“ Thursday, January 16 - Bugcrowd responds, but we are unable to establish a communications channel outside of the Netgear bug bounty programs.” I’m curious to what does this mean? They got a response form Bugcrowd but not Netgear themselves? Or they got through to Netgear but didn’t like what Netgear said so they went public? Something else?
- ukd1 7y agoGuessing they meant they were/are unwilling to.
- beardog 7y agoI discovered this same thing in 2017. My bugcrowd report was shot down as dupe https://www.chaoswebs.net/blog/tls-key-reuse-on-popular-router-models.html https://www.chaoswebs.net/blog/tls-key-reuse-on-popular-rout...
- Thorrez 7y agoFull disclosure means 0 days generally.
- tinus_hn 7y agoBoo hoo. Netgear should have known better than to expose their keys like this in the first place, this is really amateur hour stuff. They were reached out to and didn’t respond. It’s their own fault and they have to make do with what they’ve been granted. Now they get to pick up the pieces.
- devwastaken 7y agoYep. Defending bad security products only leads to people buying more. Netgear has not and will not learn any lesson, and will continue to serve bad devices. This time the good to users comes from publicizing that.
- ryanlol 7y agoFull disclosure is always perfectly justifiable, unless you’re stealing someone else’s work.
- lima 7y agoIt wasn't the researcher who disclosed the keys, it was the vendor who did, knowingly and purposefully (in their firmware updates).
- gsich 7y agoWho 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.