Netgear TLS Certs Left Exposed
Security researchers recently disclosed that Netgear TLS certificates with their associated private keys were exposed publicly in the vendor’s wireless router firmware.
What Has Happened?
Nicholas Starke, threat researcher at Aruba Networks, and Tom Pohl, head of software architecture at Businessolver, were looking for vulnerabilities in the Netgear firmware and found that private keys for signed TLS certificates were being exposed through that firmware.
"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," the bug report stated.
Tom Pohl said that he and Starke found the exposed TLS certificates relatively quickly. "I was looking for anything I could in the firmware to look for vulnerabilities and this was the first thing that popped out at me after looking at it for a short period of time," he said.
Netgear’s response
In response to the vulnerability report, Netgear posted a security advisory. The affected products include R8900, R9000, RAX120 and XR700 wireless routers. The vendor instructed their customers to “download the latest firmware hotfixes for these product models as soon as possible.”
However, Netgear noted that “security hotfixes are beta firmware created outside of normal development and testing processes. While the hotfixes do fix the security vulnerabilities identified above, they could negatively affect the regular operation of your device.” Because patches are currently unavailable for the firmware, the vendor recommended customers use the Netgear Nighthawk app or log into their routers' web interface using http://routerlogin.com/ instead of https.
CIO Study: Automation Vital to Address Shorter Lifespans and Massive Growth of TLS/SSL Certificates
Why did this happen?
This mistaken certificate management process came as a result of Netgear's approach to balance security and user convenience. When configuring their routers, 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 certificates, the router has to produce a valid HTTPS certificate for routerlogin.net or routerlogin.com that is trusted by browsers. To cryptographically prove the certificate 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.
Uninformed treatment of machine identities
The public disclosure of this certificate management flaw highlights two issues. First, the way Netgear’s bug bounty program works, which “do not allow public disclosure under any circumstances," said the researchers. As such they “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 second issue at hand is what can happen when developer teams don’t respect machine identities. Specifically, valid, signed TLS certificates with private keys were embedded in the software, which was available to download for free by anyone, and shipped with Netgear devices. This data can be used to create HTTPS certificates that browsers trust and can be used in man-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.
This unfortunate certificate management procedure highlights the importance of having in place a central certificate services program, one that can act as a safety net to procedural mistakes as well as possible certificate-related outages. Certificate owners, like Netgear’s firmware developers, are not always knowledgeable about best practices in machine identities management. On the other hand, certificate services teams are far outnumbered by the certificate owners and cannot prevent all malpractices. As a result, poor certificate management procedures are in place and mistakes like the one the researchers disclosed are more likely to happen.
A certificate services program backed by a consistent security policy has a twofold purpose: educate the certificate owners to apply best practices when it comes to managing machine identities and provide the certificate services team with the tools to automate certificate management and warn owners of mistaken management practices.
VIA Venafi includes eight steps towards building a central, effective machine identities management program which can help businesses and vendors minimize errors in managing certificates, preventing thus certificate-related outages or embarrassing situations.
VIA Venafi: 8 Steps to Stopping Certificate-Related Outages
Related posts