DigiNotar, GlobaSign, StartCom, and the #MostSophisticatedHackOfAllTime

Over a week ago it became known that the Dutch CA authority Diginotar had been compromised and certificates mis-issued by them had been seen live attacking users in the wild. Numerous other blogs have reported on various parts of this debacle, so I'll try not to re-state previous works.

Here's what you need to know.

1. This crisis is ongoing.

On August 31st Jacob Applebaum (@ioerror) reported that he had been notified that *.torproject.org was being targeted in this attack. He listed a number of serials and provided some background for how it might affect folks.

For my part, I find the torproject being targeted to be particularly interesting. Since we're not being given all the x509 data, as security researchers, we have to presume that that the certs are similar to the ones we've seen in the wild. That is, like the *.google.com certificate, which contains pointers to a CRL and an OCSP server of validation.diginotar.nl and that they have an expiry of 2 years since the signing.

Applebaum reported that he was told the certs had an exceptionally short expiration period and that they had all expired by Aug 17th. I don't beleive this claim to be likely as it deviates from the prior *.google.com cert, and was generated at the same time and in a similar way. Its far more likely they meant that they had revoked the certificates at those dates -- which as I'll get to shortly, has not happened.

On September 1, diginotar switched their OCSP server into a reversed mode. If you query for a serial number that is fictional, you'll get a revoked response, and the revoked timestamp will equal the timestamp the serial was first queried for.

For example on September 2nd, I queried their server for the serial 0x1234567890ABCDEF ... which if you query it today, you'll see that as the revocation time. If you query for a totally made up serial, you'll get the current time as the revocation time.

But what about the tor serials. It appears that they have been specifically whitelisted in the validation.diginotar.nl OCSP server. If you query for 899AE120CD44FCEC0FFCD62F6FC4BB81 for example, you'll get a OCSP response of

0x899AE120CD44FCEC0FFCD62F6FC4BB81: good
    This Update: Sep  8 09:40:05 2011 GMT
    Next Update: Sep 10 09:40:06 2011 GMT

Meaning that the cert is known to the ocsp server (they have unknown = revoked set now) and that it is being reported as GOOD.

This is quite disturbing as it indicates that the attackers certificates, if they are not expired as claimed (and that I tend to think unlikely), then they are still useful in the wild for browsers that have not been patched.

Diginotar could prove these certificates to be expired very easily by releasing the x509 data, however, short of that we have no independently verifiable reason to believe these certificates have an unusually short expiration time.

However, I also inquired on the 7e2236785477d7538e40153e8a7073db serial provided in Fox-IT's interim report. That gave an interesting answer from their OCSP server too:

openssl ocsp -issuer inter.crt -serial 0x7e2236785477d7538e40153e8a7073db -url http://validation.diginotar.nl
0x7e2236785477d7538e40153e8a7073db: revoked
    This Update: Sep  8 09:40:05 2011 GMT
    Next Update: Sep 10 09:40:06 2011 GMT
    Reason: unspecified
    Revocation Time: Sep  8 00:15:32 2011 GMT

(The revocation time being my inquiry time, indicating that this cert is not on the white-list, but was also not explicitly revoked and simply hit the catchall = revoked rule)

2. Serious allegations of an ongoing Cyber Warfare operation, with StartCom CEO Eddy Nigg ( "Lucky Eddy") saying: "No, I never imagined to take part in a state-sponsored cyber-war, but here we are." and posting a tweet - now deleted from twitter but preserved by retweet - "Run On Mean And Notoriously Insane Amok" which becomes ROMANIA when made acronym.

GlobalSign too has recently suspended, and is now talking about a Monday restoration of their certificate services, however have not yet said "the hacker's" claims hold no merit.

3. Chrome will not implement Convergence according to Adam Langley (@agl__)

4. The hacker controls codesigning certificates, and this was validated by signing calc.exe. Having codesigning ability may explain how he is able to penetrate systems.

5. There appears to be a commonly deployed Apache configuration issue that may allow someone with a rogue CA to create client certificates that will walk right past many client authentication schemes (See my prior post). This may explain certificates like Global Trustee and the repeated attempts to make very specifically named intermediate CA certificates.

6. Public security research continues to be hampered by the lack of transparency and non-publication of x509 data -- especially as it relates to the intermediate CA certificates.

7. I continue to investigate OCSP and revocation issues amongst the CA's affected. If you want to exclude my traffic look for bin2hex encoded serials with my email in them.

8. There does not appear to be a public response from Apple yet in relation to this crisis which is leading security experts to question the platforms reputation for security.

9. Mobile appears to be totally screwed, with few readily deployed update mechanisms. These devices (RIM, iPhone, Android) may be vulnerable in the wild for a very long time.

10. We have not seen the worst of this attack. So far no private key information has been publicly leaked. Yes, folks, it can, and likely will get worse.

11. The story of a single hacker from IRAN, diminishes in credibility daily. The attacks used represent significant engineering effort. If it is a single hacker, he is potentially the most skilled that has ever been publicly reported upon. The attacks instead feel much more like the Stuxnet virus authorship, and have a decidedly professional feeling to them. For example going after high value black-marketable communications certificates rather than directly usable certificates for financial organizations.

12. One scenario suggests that IRAN may be the victim here, and that the attack could have been carried out in a new attempt to sabotage their nuclear ambitions. Another scenario suggests that it could be a mercenary operation with the certs being sold to the highest bidder. (In the iran case, the government may have purchased the private key from the hacker)

In the end, we're left with more speculation than facts and a system in crisis. That SSL has been contemplated for electronic voting in Canada -- these events should now underscore the ludicrousness of that idea.

As an update to my CC system vulnerability, after a successful introduction to the issue, I am currently waiting on response from the Canadian Privacy Commissioner's Office and The Ministry of Public Safety to decide how to proceed with the publication process for my additional vulnerability against the SSL system.

More to come.