For what it's worth, this is the latest post on facebook from the researcher. https://www.facebook.com/cbyrneiv/posts/10155129935452436
The private key storage issue sounds like a reseller tool, like https://www.thesslstore.com/ssltools/csr-generator.php 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 detail... .......... 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 them. 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 years... 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 disclosed. 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 issue. 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 etc... 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
