The flaw, discovered by Chris Byrne, an information security consultant and instructor for Cloud Harmonics, could allow an unauthenticated attacker to retrieve other persons' SSL certificates, including public and private keys, as well as to reissue or revoke those certificates.
Even without revoking and reissuing a certificate, attackers can conduct "man-in-the-middle" attack over the secure connections using stolen SSL certs, tricking users into believing they are on a legitimate site when in fact their SSL traffic is being secretly tampered with and intercepted.
"All you had to do was click a link sent in [an] email, and you could retrieve a cert, revoke a cert, and re-issue a cert," Byrne wrote in a Facebook post published over the weekend.
Symantec knew of API Flaws Since 2015
Byrne said he first discovered the issues surrounding Symantec certificates in 2015 and agreed to "limited non-disclosure," as Symantec said the company would take nearly two years to fix the problems.
"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," Byrne said.The researcher did not disclose any details to the public until last week when Google disclosed its plan to gradually distrust Symantec-issued certificates inside Google Chrome after discovering several issues with the company and four of its third-party cert resellers.
"Given Google's experience and actions here, it appears that Symantec did not fix these issues as they committed to," Byrne said.
However, Byrne was not able to verify that the vulnerability he found were exactly the same issue Google engineers disclosed last week.
According to Byrne, the certificate request and delivery API Symantec provides to its third-party resellers accept URI-based UIDs "without proper authentication, or in some cases, any authentication at all."
Since the API server didn't authenticate users prior to accessing certificate information, any potential tech-savvy customer could have easily intercepted an email containing the API-generated link or took their own UID and modified one of its parameters.
This would have, eventually, allowed the malicious attacker to access information on other Symantec customers, identifying high-value targets, and perform automated attacks.
Gaining Full Control Over Another User's SSL Certificates
Using the same API vulnerabilities, the attacker could have even gained full control over another customer's certificates, which includes obtaining public and private keys, revoking certs, or reissuing certs with new passphrases.
Currently, neither the researcher nor the company has discovered any evidence to prove such a scenario, but the possibility alone was enough for Byrne when considering disclosure.
"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 added.
"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."According to the researcher, Symantec has since fixed some of the issues, but not all. We have reached out to Symantec, and will update the story as soon as we hear back from the company.
Symantec has not yet responded to the Byrne's disclosure, though the company has recently published two blog posts accusing Google of "exaggerated and misleading" claims the search engine made last month regarding its CAs.
UPDATE: Symantec's Response
Symantec has responded to this API flaws and provided the following statement to The Hacker News:"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 here."
