Leave your admin interface's TLS cert and private key in your router firmware in 2020? Just Netgear things
Finding sparks debate over bug disclosure – and how to secure a local gateway's web control panel
Netgear left in its router firmware key ingredients needed to intercept and tamper with secure connections to its equipment's web-based admin interfaces.
Specifically, valid, signed TLS certificates with private keys were embedded in the software, which was available to download for free by anyone, and also shipped with Netgear devices. This data can be used to create HTTPS certs that browsers trust, and can be used in miscreant-in-the-middle attacks to eavesdrop on and alter encrypted connections to the routers' built-in web-based control panel.
In other words, the data can be used to potentially hijack people's routers. It's partly an embarrassing leak, and partly indicative of manufacturers trading off security, user friendliness, cost, and effort.
Security mavens Nick Starke and Tom Pohl found the materials on January 14, and publicly disclosed their findings five days later, over the weekend.
The blunder is a result in Netgear's approach to security and user convenience. When configuring their kit, owners of Netgear equipment are expected to visit https://routerlogin.net or https://routerlogin.com. The network's router tries to ensure those domain names resolve to the device's IP address on the local network. So, rather than have people enter 192.168.1.1 or similar, they can just use that memorable domain name.
To establish an HTTPS connection, and avoid complaints from browsers about using insecure HTTP and untrusted certs, the router has to produce a valid HTTPS cert for routerlogin.net or routerlogin.com that is trusted by browsers. To cryptographically prove the cert is legit when a connection is established, the router needs to use the certificate's private key. This key is stored unsecured in the firmware, allowing anyone to extract and abuse it.
Netgear doesn't want to provide an HTTP-only admin interface, to avoid warnings from browsers of insecure connections and to thwart network eavesdroppers, we presume. But if it uses HTTPS, the built-in web server needs to prove its cert is legit, and thus needs its private key. So either Netgear switches to using per-device private-public keys, or stores the private key in a secure HSM in the router, or just uses HTTP, or it has to come up with some other solution. You can follow that debate here.
Anyone in the world could have retrieved these keys
"These certificates are trusted by browsers on all platforms, but will surely be added to revocation lists shortly," noted Starke and Pohl.
"The firmware images that contained these certificates along with their private keys were publicly available for download through Netgear's support website, without authentication; thus anyone in the world could have retrieved these keys."
Netgear did not respond to a request for comment on the report.
We note that while there is a certificate and private key for the routerlogin interface, there is another set for mini-app.funjsq.com, which appears to be a method for playing games online in China.
In addition to exposing the vulnerability in Netgear equipment, the infosec bods also took issue with the way the networking giant deals with security flaws. In particular, its policy of keeping bug reports quiet.
Yeah, says Google Project Zero, when you think about it, going public with exploit deets immediately after a patch is emitted isn't such a great ideaREAD MORE
"We are aware that Netgear has public bug bounty programs. However, at current date those programs do not allow public disclosure under any circumstances," the duo explained.
"We as researchers felt that the public should know about these certificate leaks in order to adequately protect themselves and that the certificates in question should be revoked so that major browsers do not trust them any longer. We could not guarantee either if we had used the existing bug bounty programs."
The decision brings up a debate that has plagued developers and security researchers alike for years: how best to handle disclosure.
On one side, there is the argument that keeping bugs under wraps minimizes the chances they will fall into the wrong hands. On the other side, there is the belief that getting issues into the open increases awareness and allows everyone to work on fixing and patching a bug.
In this case, Starke and Pohl went with the latter approach, informing the company last Tuesday and going public after hearing nothing useful back from either the router maker nor the organizer of its bug bounty. ®