111–120 of 158 posts
Earlier quoted context omitted.
Not 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.
If what you said were true then zero-days would be always ignored and not a concern.
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.
I have submitted a report - they are obligated to revoke within 24 hours.
Earlier quoted context omitted.
When I can control the client configuration, I just set up my own trusted root CA and then have the distributed systems automatically submit a CSR on initialization. This doesn't work when you have to support end user's web browsers though (unless you're somehow lucky enough to own a public CA and don't care about ICANN rules). It really does seem like there should be an encryption-only option for TLS. Maybe anything…
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.
> Similarly, resolution by IP address does not provide privacy or integrity unless you trust the network link.
That's a fair point. It's certainly no worse than our current situation where you have to trust a self signed certificate on a case-by-case basis. The router could forge a self signed certificate even more easily than it could forge a certificate signed by a trusted CA.
Earlier quoted context omitted.
The problem is, that someone setting up a public wifi (in a restaurant for example), will be vulnerable to sniffing attacks (if they don't know what they're doing).
So get a cert before setting up wifi. This is not a hard problem. 1. Connect to AP with random key from the box 2. Open admin panel over HTTP 3. Follow instructions to get Internet access 4. As soon as it has a connection, the router obtains a cert and redirects you to HTTPS 5. Now you can make all your poor security decisions
Everything is a hard problem if it’s any steps at all.
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…
“ 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?
Responsible disclosure ? How about reposonsible security pracitces first.
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…
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.
Earlier quoted context omitted.
So get a cert before setting up wifi. This is not a hard problem. 1. Connect to AP with random key from the box 2. Open admin panel over HTTP 3. Follow instructions to get Internet access 4. As soon as it has a connection, the router obtains a cert and redirects you to HTTPS 5. Now you can make all your poor security decisions
Have you met ‘normals’? Everything is a hard problem if it’s any steps at all.
Although, one could argue that setting up a router really shouldn't be left to people who don't understand how they work...
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.
Anyone with access to the private key can submit a problem report to the CA, they're obligated to revoke if the key is exposed to a non-subscriber. I have submitted a report - they are obligated to revoke within 24 hours.
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.