Happy New Year from SSL.com! Welcome to this edition of SSL.com’s Security Roundup, which showcases a selection of January’s developments in SSL/TLS, digital certificates, and network security. In this edition, we’ll be covering:
- SHA-1 collision: things get worse
- Hardware vendor’s private keys could use a little more privacy
- NSA discovers critical vulnerability in Windows 10
SHA-1: Chosen-Prefix Collision
It’s not breaking news that the SHA-1 cryptographic hash algorithm is vulnerable. About three years ago, Google researchers generated a fixed-prefix collision with the algorithm, sending it into a slow-motion death for serious cryptographic use. Consequently, it’s pretty much been abandoned in favor of the less-vulnerable SHA-2. This month, things got worse with a chosen-prefix collision, as reported by Ars Technica:
The new collision gives attackers more options and flexibility than were available with the previous technique. It makes it practical to create PGP encryption keys that, when digitally signed using SHA1 algorithm, impersonate a chosen target. More generally, it produces the same hash for two or more attacker-chosen inputs by appending data to each of them. The attack unveiled on Tuesday also costs as little as $45,000 to carry out. The attack disclosed in 2017, by contrast, didn’t allow forgeries on specific predetermined document prefixes and was evaluated to cost from $110,000 to $560,000 on Amazon’s Web Services platform, depending on how quickly adversaries wanted to carry it out.
This attack is significant. Though many have abandoned the SHA-1 algorithm, it isn’t yet fully deprecated (for example, it remains in use for certifying PGP keys in the legacy 1.4 branch of GnuPG). That makes this breach serious business, and experts are reiterating pleas to abandon the use of SHA-1 for certificates or authentication.
Hardware Vendor Mishandles Private Keys
As discovered by Nick Starke and Tom Pohl and reported by Shaun Nichols in The Register, Netgear had a rather embarrassing security breach recently. Valid, signed certificates – along with private keys – were embedded in router firmware available for public download and shipped with devices. That’s information that could be used to hijack users’ HTTPS connections to their routers, and appears to have been an attempt to make things easier for their customers, at the expense of security. As reported by Shaun Nichols:
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… 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.
At this point, the company has a couple of solutions at its disposal which are, of course, currently being debated online.
NSA Finds Critical Cryptographic Vulnerability in Windows 10
The National Security Agency discovered what they are calling a “critical vulnerability” in Windows 10 that impacts its cryptographic functionality. Specifically, the vulnerability impacts HTTPS connections, signed files and emails and some signed code. As a result, the agency is advising that users mitigate this vulnerability by installing all of the January 2020 Patch Tuesday patches ASAP. You can read more from the NSA on their website.
The vulnerability, which has been described as “broad” has unsettled researchers. As Dan Goodin at Ars Technica explains, the vulnerability exploits a loophole that breaks the chain of trust:
The flaw involves the way the new versions of Windows check the validity of certificates that use elliptic-curve cryptography. While the vulnerable Windows versions check three ECC parameters, they fail to verify a fourth, crucial one, which is known as a base point generator and is often represented in algorithms as ‘G.’ This failure is a result of Microsoft’s implementation of ECC rather than any flaw or weakness in the ECC algorithms themselves.
Attackers can exploit the flaw by extracting the public key of a root certificate that ships by default in Windows. These certificates are described as root because they belong to big certificate authorities that either issue their own TLS certificates or validate intermediate certificate authorities that sell certificates on the root CA’s behalf. Any root certificate will work, as long as it’s signed with an ECC algorithm… The attacker examines the specific ECC algorithm used to generate the root-certificate public key and proceeds to craft a private key that copies all of the certificate parameters for that algorithm except for the point generator. Because vulnerable Windows versions fail to check that parameter, they accept the private key as valid. With that, the attacker has spoofed a Windows-trusted root certificate that can be used to mint any individual certificate used for authentication of websites, software, and other sensitive properties.
In short, this bug can be exploited by bad guys to make it seem like malicious executables are from trusted, verified sources and to fake digital certificates. Worried? Here’s a link to test if you are vulnerable to the attack.
