API flaws said to have left Symantec SSL certificates vulnerable to compromise

Over the weekend, Chris Byrne, an information security consultant and instructor for Cloud Harmonics, published a post to Facebook outlining a serious problem with the processes and third-party API used to deliver and manage Symantec SSL certificates.

If exploited, the flaws would allow an attacker access to public and private keys, as well as the ability to reissue or revoke certificates.

In his post, Byrne said that he first became aware of the problems surrounding Symantec certificates in 2015. Everything was properly disclosed to Symantec, and Byrne agreed to limited non-disclosure, unless it became unethical or irresponsible for him not to disclose. In the end, it looked as if it would take nearly two years to fix the problem, based on conversations he had at the time.

Last week, Google disclosed their intent to deprecate and remove trust in Symantec-issued certificates, which is part of the reason why Byrne’s discovery is just now coming to light.

While not exactly related to Google’s actions (there is no evidence linking the two incidents), the vulnerability Byrne discovered runs parallel to some of the things Google is concerned about when it comes to issuing Symantec certificates.

Google’s notice says Symantec allowed at least four parties access to their infrastructure in order to issue certificates, but didn’t oversee the granted access sufficiently as required and expected.

“These issues, and the corresponding failure of appropriate oversight, spanned a period of several years, and were trivially identifiable from the information publicly available or that Symantec shared,” Google’s notice states.

The post goes on to state the full disclosure of these issues to Symantec has taken more than a month, and condemns Symantec for failing “to provide timely updates to the community regarding these issues” or proactively disclose them.

According to Byrne, who discussed his findings with Salted Hash, the certificate request and delivery API provided to third-party partners by Symantec, accepted URI-based UIDs without authentication or verification. The UIDs were sequential in nature.

Thus, if a malicious actor intercepted an email containing the API-generated link or took their own UID and changed it, they would’ve had the ability to gain full control over another user’s certificates without any of the usual identity checks. This includes obtaining public and private keys, revoking certificates, or reissuing certificates with new passphrases.

To add some context, Byrne told Salted Hash that one of the first things to hit him after he noticed how flawed the retrieval and management process was, is that once the link generated by the API was clicked – he was never asked for verification or authentication.

Byrne is one of the good guys, but criminals purchase SSL certificates too.

It’s possible a malicious actor discovered the same vulnerability Byrne did. If so, and the attacker selected a non-critical certificate, revoked it, and issued it again with a new passphrase, it could be months (or longer, if at all) before the hijacking was noticed.

Currently, no evidence exists to prove or disprove such a scenario, but the possibility alone was one of the biggest dilemmas Byrne faced when considering disclosure.

Even without revoking and reissuing a certificate, a malicious actor would’ve still been able to act as a man-in-the-middle.

“It would then be trivial to compromise DNS for a particular organization or person they wanted to attack. At that point, they could pretend to be that person’s bank, their credit card company, their employer, anyone,” Byrne said.

“Perhaps the worst compromise would be to spoof a patch and update server, for an entire company. Then every single machine at that company could be compromised simultaneously.”

The API problems observed by Byrne also create the ideal setup for a Phishing attack, because the target would get a legitimate SSL certificate. In this case, even if a user did everything that’s asked of them during awareness training, such as confirm SSL is active or check the certificate itself, they’d still become a victim.

Years ago, Byrne was told the affected partners were supposed to provide their own security, and never expose the URIs and UIDs.

The hope is that Symantec has since fixed the process problems and API issues. As things stand, this is likely the case, because the registration authority program was ended by Symantec.

Bobby Kuzma, currently a researcher with Core Security, and someone who examined Byrne’s discovery in 2015, said one of the third-party websites where the API flaw existed was SSLs.com – a reseller that offered Symantec certificates (including GeoTrust and Thawte) in 2015 and continued to do so until November 2016.

After that date, SSLs.com customers who had Symantec certificates were transitioned to other products. To be clear, the decision to leave Symantec by SSLs.com had nothing to do with the discovery made by Byrne.

Salted Hash reached out to SSLs.com for comment, but the company said the registration emails in question were issued from the certificate authority (CA) side directly, and they were not able to impact them in any way. This makes sense, because the URLs were generated by the API.

Salted Hash also reached out to Symantec for comment. We asked about the API vulnerability, and while there is nothing connecting the two incidents publicly, inquired as to whether or not that vulnerability was related to the problems Google publicized.

We didn’t receive a direct response. Instead, we were pointed to a statement where Symantec addresses Google’s actions. We asked follow-up questions about the API and will update this story should Symantec respond.

“Google’s statements about our issuance practices and the scope of our past mis-issuances are exaggerated and misleading,” Symantec wrote in a blog post.

“We have taken extensive remediation measures to correct this situation, immediately terminated the involved partner’s appointment as a registration authority (RA), and in a move to strengthen the trust of Symantec-issued SSL/TLS certificates, announced the discontinuation of our RA program. This control enhancement is an important move that other public certificate authorities (CAs) have not yet followed.”

In addition, Symantec stated that they operate their certificate authority (CA) in accordance with industry standards, and maintain extensive controls over their SSL/TLS certificate issuance process, and work to continually strengthen their CA practices.

[Updated on 3/27 to clarify that SSLs.com transitioned away from Symantec for reasons that were completely unrelated to the API issue.]

Update:

Symantec reached out with additional comments.

“We have looked into Chris Byrne’s research claim and could not recreate 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. 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. Anyone who would like to share further details about real-world scenarios or proof of concept should contact us.”

Head over to Facebook to let us know of any other flaws.