For what it's worth, this is the latest post on facebook from the researcher.

The private key storage issue sounds like a reseller tool, like
and he found the private key was stored with the reseller,  when he accessed 
the account.

Chris Byrne
March 24 at 8:02pm ยท 

UPDATED Tuesday March 28th, to clarify some language, and provide additional 
Looks like I don't have to stay quiet about this one anymore... 
I found out about this problem... and others related to it... back in early 
2015. I warned Symantec about it, and worked through some of the issues with 
At the end of it, they asked for a chance to verify how extensive the issue 
was, and to fix it. We both agreed it would take up to two years to fix, 
without creating more chaos and causing more damage... and I said yes.
I agreed to limited non-disclosure of the issue, unless I felt it was 
critically necessary, or it would be unethical or irresponsible for me not to 
disclose (for example, if there were a threat to national security, or I 
discovered a compromise of a client, or any actual criminal compromise arising 
from it, etc... etc...). 
That said, I informed Krebs and a few others about what I had found... and also 
that I agreed to let them fix it, because it would be less damaging to the 
world, than exposure would be. 
It was one of those issues where there's no GOOD choice... but I looked at the 
damage immediate exposure would cause, vs. a slowly rolling fix over two 
I talked to some of my friends on the grey and black sides of things, and did 
my own checking, to see if there was any chatter about this anywhere, and I 
couldn't find any... and I concluded that more harm would be done if I 
Fellow security professional Bobby Kuzma helped me investigate and validate 
these issues, and he can verify what I state here. 
I checked a few months later, and they HAD fixed several of the core 
problems... though not all of them... So I waited, and so did those who I had 
informed about the problem, and had verified it for themselves... 
Unfortunately, late in 2015, my cancer recurred, and spread to my lymph 
nodes... and I've been fighting it ever since, so I haven't kept up with the 

So... Here's what the post doesn't mention...
If you purchased a Symantec certificate (or a cert from any of their associated 
subsidiaries and partners) through a third party, from at least as far back as 
early 2013 until recently; their third party certificate generation, 
management, and retrieval API allowed those certificates... including in some 
cases private keys generated by third parties... 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 
re-issue a cert... and for some third party vendors, depending on the type of 
certificate, and how the certificate was issued, you could also retrieve 
private keys.
Note, this was not just for server certificates for SSL, it also included other 
certificates, such as personal certificates used for email and other personal 
encryption. These certs could be requested entirely through the web interface 
without a separate server issued certificate request, generating both private 
and public keys, which would then only be protected by a passphrase. 

Further, even with first party purchase, for some time in some web interfaces, 
it was possible for properly authenticated users to edit a URL, and at least 
retrieve information about first party certificates and their owners, and 
possibly the certs of others. 
This is because third party data retrieval was not limited to certificates 
issued by that third party. It was available to anyone by entering the UID of 
any other user. 
To clarify... at no time were we able to retrieve private keys directly from 
Symantec, only from third parties that issued certificates from a web interface 
without requiring a server generated certificate request.
We were able to confirm that these third party weaknesses extended to 
retreiving, revoking, and reissuing certificates, in some cases without 
notification to the legitimate certificate holder.
In one case, we were also able to reissue a certificate without first 
explicitly revoking it, and the original certificate continued working for at 
least 48 hours... We did not test further to see how long it would take for the 
certificate revocation list to propagate, and we're not pale to prove one way 
or the other if the organ certificate was revoked or not. 

It is possible that the certificate was never revoked at all, and another 
certificate was simply issued, leaving two valid certificates one controlled by 
the original requestor, and one controlled by the unauthorized party. This 
would be the worst case scenario. 
It is also possible that the original certificate was properly revoked 
automatically when we reissued the certificate, and it simply took some time 
for the certificate revocation to take effect, or that our browsers were 
ignoring or not retreiving on updating the CRL. However even under the best 
circumstances, there would be a latency period after revocation before the cert 
hit CRLs, and browsers updated their CRL cache. This latency period could be 
several days, or longer. Thus this would limit the compromise somewhat, but it 
would still be a very serous problem. 
Also, it was not uncommon at the time for browsers to load sites with revoked 
certificates, without warning the certificate was revoked, because they had 
short timeouts for CRL update, and long timeouts before requiring an update... 
So they would load sites without actually checking a current CRL, because they 
didn't want to interrupt the user experience, and get complaints or excess 
support requests etc... These are tunable parameters in most browsers.

There was only so much testing we could do, without actually compromising the 
certificates of third parties, or without committing a felony, so we were not 
able to test just how far the exposure and potential for compromise went.
The third party that we tried to work with (before testing with other third 
party resellers to confirm it wasnt just the one) was entirely incompetent, to 
the point where they actually said they had no-one who could speak with us 
about the issue, and directed us to speak with Symantec, which we did. 
Symantec told us at the time, that it was a third party security issue, and 
that it was up to the third parties to provide security around their 
certificate management... that the URI and UID were not supposed to be exposed 
to users. That if the third party were doing so, it was against their policies 
When I agreed not to disclose the problem until it was fixed or otherwise 
publicly disclosed, Symantec commited to investigating the full extent of the 
issue, and that if third parties were violating the conditions, policies, and 
processes required, that they would deal with those issues appropriately... 
finding all of the certificates which MAY have been impacted, and then replace 
them... In discussion, they estimated, and we agreed, that doing so would take 
at least six months for every cert they could identify, and two years for every 
cert period.
Given Googles experience and actions here, it appears that Symantec did not fix 
these issues as they committed to, or at least not within a timely manner. They 
terminated some third parties participation in their reseller program, and 
revoked and reissued many thousands of certs, but nowhere near all of those 
that may have been impacted... Unless they had some way of proving those certs 
were not compromised, that we are not aware of. 

Further, though the interfaces we knew about and had been able to demonstrate 
were compromised were fixed or shut down, they apparently did not fix their 
core API issues (they ended their RA program in November of 2016 but users may 
still have been able to retrieve, revoke, and reissue certificates using the 
original URI links and UID's) and thus as far as we are able to prove, this 
critical issue remained at least until November of 2016... and may still remain 
(I haven't attempted to verify again recently) and third party purchased 
symantec certs may still be subject to compromise in this manner.
UPDATE: Symantec states that they have tested the issue with their current APIs 
and interfaces, and are not able to recreate it.
So, at this point, I will publicly disclose what I know about the issue, and 
release anyone I shared the details of the issue with to do so as well. 
My STRONG recommendation, is that anyone who purchased a Symantec certificate 
from a third party, between early 2013 and late 2016, revoke that cert and have 
it re-issued... either directly by Symantec, or simply revoking and having 
another trusted CA issue a different cert... as soon as they are able to do so.
As to first party certificates... I don't know and have not been able to 
validate how extensive the exposure was, through which interfaces, etc... I do 
know that they fixed the specific issues that I found in the specific 
interfacecs I was able to validate, within six months as they agreed to. That 
said... It would be safer to revoke and re-issue, given the problems that 
Google themselves identified. 
As to end users... I would be extremely wary of any site with a symantec cert 
issued before late 2016, and take some extra caution regarding any symantec 
cert period.
dev-security-policy mailing list

Reply via email to