Potential SSL API flaw could reveal private keys

Piling on to Symantec's certificate authority troubles, a security researcher claims to have found vulnerabilities in the company's SSL API, which could have dangerous consequences, but proof of the flaws has been lacking.

To say Symantec has had troubles regarding its certificate authority (CA) recently would be a bit of an understatement, as Google put the company on notice for allegedly failing to properly validate as many as 30,000 SSL certificates. Symantec claimed the number was actually 127, but has also promised to reissue all of the certificates affected by Google's claim free of charge.

After that news broke, security researcher Chris Byrne came forward with allegations that Symantec's third-party SSL API had vulnerabilities and "allowed those certificates ... including private keys ... to be retrieved without proper authentication, or in some cases any authentication at all. Unless the third party added proper security around it, all you had to do was click a link sent in email, and you could retrieve a cert, revoke a cert and reissue a cert."

Byrne said he found the SSL API flaws in 2015 and notified Symantec. He said in a Facebook post that Symantec "committed to finding and replacing all of the certificates which may have been impacted, and then replace them ... that they would do so within six months for every cert they could identify, and within two years for every cert, period." However, Byrne wasn't able to follow up on the issue because of a battle with cancer and passed on the information he had to a number of security experts, including journalist Brian Krebs and Bobby Kuzma, system engineer for cybersecurity company Core Security, based in Roswell, Ga.

Kuzma said he was "not involved with any contact with Symantec, or discussions to that effect."

"My involvement was specifically with validating that the reseller implementation -- RapidSSL via SSLs.com -- required no authentication other than a numeric UID [unique identifier] to manipulate the SSL certs with revocation, reissue, etc.," Kuzma told SearchSecurity, adding that he was not involved with testing the private key flaw.

Justin Jett, director of audit and compliance at Plixer International in Kennebunk, Maine, said it would be "extremely dangerous" if the private keys could be retrieved.

"Typically, API access to a CA should allow a company to request certificates, including initiating the validation of domains, revoke certificates that have been compromised and renew certificates (which is essentially the same thing as requesting a new one)," Jett told SearchSecurity via email.

A spokesperson for Symantec told SearchSecurity that the company looked into Byrne's claims and "could not re-create the problem."

"We would welcome the proof of concept from the original research in 2015, as well as the most recent research. In addition, we are unaware of any real-world scenario of harm or evidence of the problem," Symantec said. "However, we can confirm that no private keys were accessed, as that is not technically feasible. We welcome any feedback that helps improve security for the community."

However, Byrne told SearchSecurity this was careful wording by Symantec, as the company may have tested its current first-party API because "they ended their third-party program in November of 2016." And while the company "does have records of every cert they process, they have no way of knowing if the requestor was properly authorized or authenticated ... particularly if they come in through a third-party API."

"In their RA [registration authority] program, they depended completely on the third parties to provide proper authentication and verification of identity and authorization. However, many third parties didn't bother putting any security in place at all," Byrne said. "That jibes with what Google saw, as well. At least 30,000 certificates were issued to third parties without proper authentication or verification."

Byrne noted that a malicious actor who was abusing the SSL API vulnerabilities would only be caught by an audit of certificates, like Google performed, or if the affected third party checked against the certificate revocation list.

"We were able to reissue certificates without authentication or notification of the original issuer," Byrne said. "[A malicious actor] didn't need to steal the private keys. They could reissue the certificate with their own private keys, without the original certificate owner knowing."

Craig Young, principal security researcher at Tripwire Inc., based in Portland, Ore., said if an attacker could "retrieve private keys from signed certificates, they can spoof any website associated with the certificates."

"Generally, impersonating a website would require an attacker with control over the network path from client to server. A government or telecom provider could easily use this technique to monitor or manipulate connections to specific services. Hackers could also take control of home routers to siphon data from these secure websites without raising any alarms," Young told SearchSecurity. "The biggest threat, however, comes from the use of Wi-Fi. This is because, very often, an attacker can impersonate a trusted wireless network to get total control over connections to secure websites, including those using HTTP Strict Transport Security. What is additionally troublesome is that this would enable an attack even against sites using HTTP Public Key Pinning, which is intended to detect hacking attempts using unauthorized certificates."

Jett said a third-party SSL API flaw like this could lead to "a great increase in identity theft if certificates with compromised certificates and private keys are not revoked quickly."

"Since Symantec is the parent company for many CAs -- Thawte, RapidSSL, GeoTrust, etc. -- there is a higher likelihood that a site's certificate could have been compromised," Jett said. "Certificate authorities have a responsibility to ensure that access to private keys is limited to the companies that own the keys. When APIs are used, they should be highly restrictive and use some form of authentication before allowing many actions to take place."

Byrne noted that since Symantec's press release on the Google audit, "people inside Symantec who I know reached out to me immediately once this was published, to make sure that the problem was fixed as of now at least. And they were able to validate that as of two days ago at least, the problem was fixed."