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.
Tuesday, January 14th 2020 - Initial Discovery
Tuesday, January 14 2020 - Tweet sent attempting to establish communications with Netgear
Wednesday, January 15 2020 - Reached out to Bugcrowd to attempt to establish communications.
Thursday, January 16 - Bugcrowd responds, but we are unable to establish a communications channel outside of the Netgear bug bounty programs.
Friday, Jaunary 17th - Conversation with bugcrowd proves inconclusive
Sunday, January 19th - Feeling we have exhausted our disclosure avenues, we decide to publish
I discovered this same thing in 2017. My bugcrowd report was shot down as dupe
https://www.chaoswebs.net/blog/tls-key-reuse-on-popular-rout...
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 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.
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$ router?
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.
I don't envy Netgear. They sell home routers to people who hardly know the difference between HTTP and HTTPS. In this regard, I respect them for NOT making those people submit sensitive information by ignoring browser security warnings and/or accepting self signed certificates. I.e, not teaching bad habits.
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...
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 the box which has the SSH user, password, and fingerprint for verification.
The App connects to the router over SSH to do router setup.
If an App is involved you wouldn't technically NEED to use SSH with the App but it was the first thing that came to mind.
The cert for www.routerlogin.net (Serial c1:a1:00:64:07:61:2c:07:00:00:00:00:50:f1:09:6a) isn't revoked yet: https://crt.sh/?id=1955992027&opt=ocsp
The reporters should have asked the CAs to revoke the certificate. If the CA doesn't do that within 24 hours, it's considered a violation of the rules that the CA needs to follow to stay in browsers.
Can anyone make out what the funjsq.com is about?
This is a world after QUANTUMINSERT for you. Somehow everything should be encrypted but key management are still unsolved
This reminds me of something I have been looking for for a long time. If you know any reasonable way to fix it please let me know!
This "any CA can authenticate any domain" system is ridiculous. I manage my own CA, which is fine for my own self-hosted sites, but the issue is that it doesn't protect me from a cert made valid by some other CA.
Is there any way I can whitelist my own CA such that IT ALONE will work for my domains? (note: this is a me-only thing. Don't need anyone to be able to validate these domains).
PS, I've asked this question elsewhere [0] before. I did not find an adequate answer.
[0]: https://security.stackexchange.com/questions/211401/can-you-...
I guess I run a different firmware for my Netgear ReadyNAS 312.
This is easy to inspect because the FW is Debian-based, and enabling inbound SSH is easy.
Checking on mine, it has a cert only for the "nas.local"-domain, and the cert is stored in /etc/ssl/certs/ssl-cert-snakeoil.pem and /etc/ssl/private/ssl-cert-snakeoil.key respectively.
Have to admit I love the naming of those files :)
Edit: Obviously it is a different firmware. Mine is a NAS, this was a router. And “snakeoil” seems to be default debianism.
> 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?
What’s a good netgear alternative for switches from 5 port to 48 port - too late for us now but for next buying wave
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.
Name and Shame.
Responsible disclosure ? How about reposonsible security pracitces first.
This is why I use OpenWrt. Shout out to the dude sticking up for screen reader users to! Thanks friend. Shit like footnotes and captchirs are the bane of my life!
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 stuff the key in there somehow. There’s no way around that.
Either browsers have to start accepting “local” certs more easily, or end-user network deployed appliances can’t have ssl.
Take a pick.
This is intentional on Netgear's part, and does not in any way degrade security compared to the alternative (an untrusted cert or no HTTPS). It is neither a bug nor a security issue.
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 coordinated effort, full disclosure is the responsible thing to do.