September 2011 - Posts

Diginotar declared bankrupt

2
Published: 2011-09-20,
Last Updated: 2011-09-20 11:16:50 UTC
by Swa Frantzen (Version: 1)
Rate this diary:

4 comment(s)

In the latest installment of this seemingly never-ending saga, a Dutch court in Haarlem (NL) declared DigiNotar bankrupt.

Read more:

The CA business is all about selling trust. After all a CA is supposed to be a trusted third party. Let's hope all the remaining ones get the right message: it's not about not getting caught being hacked. On the contrary: it's about doing the right thing once you have been hacked. Let's hope it leads to more transparency and public scrutiny of the CAs we trust explicitly or implicitly though the choice of some of our vendors.

--
Swa Frantzen -- Section 66

More DigiNotar intermediate certificates blacklisted at Microsoft

Published: 2011-09-13,
Last Updated: 2011-09-13 19:42:58 UTC
by Swa Frantzen (Version: 1)
Rate this diary:

0 comment(s)

Microsoft issued yet another update to remove trust in the cross signed intermediate certificates of DigiNotar.

Early Patch Tuesday Today: Microsoft September 2011 Patches

1
Published: 2011-09-09,
Last Updated: 2011-09-09 23:43:32 UTC
by Johannes Ullrich (Version: 1)
Rate this diary:

4 comment(s)

Looks like Microsoft made the bulletins live that were supposed to be released this coming Tuesday. The bulletins are dated September 13th 2011. While the links below work as I type this diary, they may not work later today. Some of the related links may not have any information yet (like CVE). All bulletins appear to be live right now, and we will add them to the list below as we get to it.

This information may of course change as the final bulletins will be released on Tuesday. Some readers report that the bulletins are no longer available.

# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*)
clients servers
MS11-070 Vulnerability in WINS could allow elevation of privilege. Replaces MS11-035.
WINS

CVE-2011-1984
KB 2571621 - none - Severity:Important
Exploitability:?
Important Important
MS11-071 Vulnerability in Windows could allow remote code execution (DLL Linking Vuln.).
Windows

CVE-2011-1991
KB 2570947 yes Severity:Important
Exploitability:?
Critical Important
MS11-072 Arbitrary code execution vulnerability in Excel. Replaces MS11-045.
Excel

CVE-2011-1986 CVE-2011-1986 CVE-2011-1987 CVE-2011-1988 CVE-2011-1989 CVE-2011-1990
KB 2587505 - none - Severity:Important
Exploitability:?
Critical Important
MS11-073 Code execution vulnerability in Microsoft Office. Replaces MS11-023, MS10-087 .
Office

CVE-2011-1980
CVE-2011-1982
KB 2587634 - none - Severity:Important
Exploitability:?
Critical Important
MS11-074 Microsoft Sharepoint Elevation of Privilege Vulnerability. Replaces MS11-016.
Sharepoint

CVE-2011-0653
CVE-2011-1252
CVE-2011-1890
CVE-2011-1891
CVE-2011-1892
CVE-2011-1893
KB 2581858 CVE-2011-1252 publicly disclosed. some of the others are not disclosed but likely simple to exploit XSS flaws. Severity:Important
Exploitability:?
-N/A- Important
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
  • The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
  • Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
  • All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.

(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.

--
Johannes B. Ullrich

********************************************************************
Title: Microsoft Security Advisory Notification
Issued: September 6, 2011
********************************************************************

Security Advisories Updated or Released Today ==============================================

 * Microsoft Security Advisory (2607712)
  - Title: Fraudulent Digital Certificates Could Allow Spoofing
  - http://www.microsoft.com/technet/security/advisory/2607712.mspx
  - Revision Note: V3.0 (September 6, 2011): Revised to
    announce the release of an update that addresses this issue. 


DigiNotar breach - the story so far

Share |
Published: 2011-09-01,
Last Updated: 2011-09-01 14:26:50 UTC
by Swa Frantzen (Version: 3)
Rate this diary:

1 comment(s)

I've been following the DigiNotar story as it evolved for a few days now with growing concern and increasing alarm.

I'm by far not privy to the inside information to be able to really assess and audit the situation, so this is purely based on what is publicly known. Being a Dutch native speaker I have access to what the press in the Netherlands writes about it with the subtle nuances that an automated translation will not capture. I do lack the resources to independently double verify everything and as such some errors might still be in it, consider this a best effort at creating some overview and leading up to conclusions with the limited information that is available.

If we do attract the attention of DigiNotar and/or Vasco: please do contact us, we'd love to talk to you and get more information!

So who is DigiNotar and what do they do when all is normal?

DigiNotar is a CA. They sell SSL certificates, also the EV kind.

But there is more that's mostly of interest to those in the EU or the Netherlands only:

They are also (I'm simplifying a bit, I know) an accredited provider in the EU and provide qualified certificates and approved SSCDs to customers to create digital signatures that -by law- in the EU are automatically considered to be qualified digital signatures and as such they are automatically equivalent to manual signatures. This status forces regular 3rd party audits against the relevant Dutch law and standards such as ETSI TS 101 456.

They also provide certificates services under the PKIOverheid umbrella in the Netherlands. This has even more and stricter rules. e.g. Things that are suggested in the ETSI standards, but not mandatory, can become mandatory for PKIOverheid.

DigiNotar is a 100% daughter company of Vasco (since Jan 2011), so if you see Vasco sometimes doing things like press releases regarding the incident, that's why. 

So what do we know in a chronological order ?

  • Dating back as far as May 2009, the portal of DigiNotar has been defaced, these hacks remained in place till this week after f-secure exposed them in their blog.
    Source: f-secure blog
  • On July 10th 2011 a certificate was issued with a CN of *.google.com by DigiNotar
    Source: pasted certificate
  • In July 2011 "dozens" of fake certificates were issued by intruders -most likely Iranian, but that remains to be proven-.
    Source: Jan Valcke, Operational director at Vasco in an interview with "webwereld" [in Dutch]
    The list of fake certificates appears to include certificates for mozilla, tor, yahoo, wordpress and baladin.com, but does not include any financial institutes.
    Source: nu.nl article [in Dutch] would love a second or more authoritative source for this.
  • On July 18th 2011, 6 fraudulent certificates were created with a CN of *.torproject.org
    Source: torproject
  • On July 19th 2011, DigiNotar detected the incident and supposedly the majority of these certificates were revoked. At least one, possibly more certificates were missed in this process.
    Source: Jan Valcke, Operational director at Vasco in an interview with "webwereld" [in Dutch]
    There's a bit of a bad feeling with this claim, see further.
  • On July 20th 2011, (at 06:56, unspecified timezone) a second batch of 6 fraudulent certificates were created with a CN of *.torproject.org
    Source: torproject
    Note we lack timezone info from both the claim above and these certificates, don't jump to conclusions just yet.
  • On an unknown date, an unknown external auditor did not catch the fraudulent certificate for *.google.com. as well as any others that might be missed as well.
  • On Aug 28th 2011, (some sources claim 27th) a user from Iran posted on a forum using Chrome was warned by his browser the certificate was not to be trusted.
    Source: Forum post
    Chrome does additional protections for gmail since chromium 13.
  • On Aug 29th 2011, the *.google.com certificate was revoked by DigiNotar
    This can be seen in the CRL at http://service.diginotar.nl/crl/public2025/latestCRL.crl [do not click on this URL, most browsers "understand" CRLs], see further.
  • On Aug 29th 2011, the response from Google and the other browser makers came: Basically the "sh*t hit the fan" as the browser vendors are pulling the plug on DigiNotar and not trusting their processes anymore.
  • On Aug 30th 2011, Vasco issued a press release reporting the incident.
  • On Aug 30th 2011, various claims of both Vasco, and the Dutch government try to stress that the activities of DigiNotar under the PKIOverheid root were not affected. Some arguments used in the press such as that the root certificate of PKIOverheid is not at DigiNotar (they have an intermediate) are obvious and irrelevant.
  • On Aug 30th 2011, DigiNotar released information for users of Diginotar certificates [in Dutch]. This includes a very painful statement: (my translation): "Users of SSL certificates can depending on the browser vendor be confronted with a statement that the certificate is not trusted. This is in 99,9% of the cases incorrect, the certificate can be trusted". I've got nothing positive to say about that statement. They also offer a free upgrade to the PKIOverheid realm for those holding a SSL or EVSSL certificate.
  • On Aug 31th 2011, it is confirmed security company Fox-IT is performing a forensic audit of the systems of DigiNotar. Results are expected next week at the earliest.
    Source: webwereld article [in Dutch]

Analysis of the CRLs

DigiNotar claims all breaches were under the "Public 2025 Root" ref [in Dutch]. What "root" does in there is somewhat unclear to the technical inclined mind, and the "public 2025" just seems to be some sort of internal name. Let's assume they meant the fraudulent certificates all were signed by the same intermediate.

The CRL indicated in the fraudulent *.google.com certificate does indeed point in the same "public 2025" direction, so let's get that CRL:

$ wget http://service.diginotar.nl/crl/public2025/latestCRL.crl

Let's make this file human readable:

$ openssl crl -text -inform DER -in latestCRL.crl >/tmp/t

And let's verify there is indeed the Serial Number in there of the *.google.com fake certificate we found on pastebin:

$ grep -i "05e2e6a4cd09ea54d665b075fe22a256" /tmp/t
    Serial Number: 05E2E6A4CD09EA54D665B075FE22A256

So yes, it's revoked. Getting the other relevant lines (it means first figuring out how many, but I skip the boring part).

$ grep -i -A4 "05e2e6a4cd09ea54d665b075fe22a256" /tmp/t
    Serial Number: 05E2E6A4CD09EA54D665B075FE22A256
        Revocation Date: Aug 29 16:59:03 2011 GMT
        CRL entry extensions:
            Invalidity Date:
                Aug 29 16:58:47 2011 GMT

So that checks out nicely. [One should of course check that all signatures are valid everywhere]

Unfortunately one can only see the Serial Number of the certificates revoked, not the more juicy fields like the CN or so that would allow to see what and when other (fake) certificates were revoked.

But since we have the revocation date, maybe we can see the peak where they revoked the fraudulent certificates. I know the nature of revocation and any other work in a CA/RA can be highly cyclic with huge peaks in it, and I know not to worry about any revocation as such, users loosing control over a certificate happens all the time.

So let's see revocation activity in July 2011 split out per day:

$ grep "Revocation Date:" /tmp/t | sed 's/^.*Date: //' | sed 's/..:..:.. //' 
|sed 's/GMT//' | sort -n | uniq -c  | grep 'Jul .* 2011'
   1 Jul  1 2011
   3 Jul  4 2011
   3 Jul  5 2011
   6 Jul  6 2011
   6 Jul  7 2011
   1 Jul  8 2011
   2 Jul 11 2011
   6 Jul 14 2011
   1 Jul 15 2011
   1 Jul 18 2011
   2 Jul 19 2011
   1 Jul 20 2011
   1 Jul 21 2011
   3 Jul 22 2011
   3 Jul 26 2011
   7 Jul 28 2011
   5 Jul 29 2011

Uhmm, where is the "dozens" on July 19th ?

Since the *.google.com one was made on Jul 10th, there is no dozens neither before nor shortly after the 19th.

They might have been added to another CRL, hard to say as DigiNotar does not allow directory listing and doesn't have an easy to find list of CRLs they publish either.

Still, even if we look at the "normal" workload in 2011:

$ grep "Revocation Date:" /tmp/t | sed 's/^.*Date: //' | sed 's/..:..:.. //' 
|sed 's/GMT//' |grep 2011| sed 's/ .. 2011//'| sort -n | uniq -c
  93 Apr
  34 Aug
 112 Feb
 144 Jan
  52 Jul
  18 Jun
 118 Mar
 118 May

We see that the Jun/Jul and Aug months are very light on revocations. [Note that August was not yet complete in GMT time when I downloaded the CRL file].

I know my sed, grep commands could be optimized to save a few CPU cycles, but this isn't a unix lesson.

I'd love to see the "dozens" of revocations around July 19th in a DigiNotar CRL, but I simply cannot find them.

The torproject was in touch with Diginotar and got a spreadsheet with validity dates , SN and some more fields of the certificate (CN, L, O, ST, C) of 12 fraudulent certificates.

Excel spreadsheet is here. The 12 certificates had a validity of Aug 17th, 2011 or Aug 19th 2011

torpoject spreadsheet

$ grep -i -A4 "899AE120CD44FCEC0FFCD62F6FC4BB81" /tmp/t
$ grep -i -A4 "7DD16C03DF0438B2BE5FC1D3E19F138B" /tmp/t
$ grep -i -A4 "5432FC98141883F780897BC829EB9080" /tmp/t
$ grep -i -A4 "73024E7C998B3DDD244CFD313D5E43B6" /tmp/t
$ grep -i -A4 "B01D8C6F2D5373EABF0C00319E92AE95" /tmp/t
$ grep -i -A4 "FF789632B8D4AECD94A0AAB33074A058" /tmp/t
$ grep -i -A4 "86633B957280BC65A5ADFD1D153BDE52" /tmp/t
$ grep -i -A4 "E7F58683066112DC5EB244FCF208E850" /tmp/t
$ grep -i -A4 "1A07D8D6DDC7E623E71205074A05CEA2" /tmp/t
$ grep -i -A4 "79C8E8B7DE36539FFC4B2B5825305324" /tmp/t
$ grep -i -A4 "06CBB1CC51156C6D465F14829453DD68" /tmp/t
$ grep -i -A4 "ED1A1008190A5D1654D138EB8FD1154A" /tmp/t
$

These were clearly not revoked in this CRL. And we can confirm what the torproject concluded about that themselves: we simply can't find proof of revocation.

So what's the known impact right now:

  • If you're a general Internet user: you're unlikely to see much impact, maybe you'll run into a website with a DigiNotar certificate somewhere that will now warn the certificate is not trusted anymore.
    Keep your browser up to date!
    The longer term impact will still have to manifest itself, and for sure breaches such as these will prompt thinking of other solutions.
    If the add-ons of Mozilla were indeed attacked using a MitM approach, impact might be more widespread, but that becomes somewhat less likely.
    If you really need to access a website that is using a DigiNotar SSL certificate that your browser is not trusting anymore, I'd encourage you not to ignore the warning of the browser, certainly not to add the yanked DigiNotar root certificate back in. Instead the safe procedure is to go examine the certificate and contact the website operator out of band (e.g. by phone). Make them tell you what the fingerprint is of their certificate, verify that with what you see and only then accept the certificate. If you want to be sure you're talking to the right website, you need to perform the work the 3rd party used to do for you, not blindly click OK.
  • If you're a user in Iran, and had something to hide from your government, odds are you're in trouble with your government.
  • Tor users: the torproject confirms the tor network itself is not reliant on SSL certificates. Downloading their client should be done with great care, but the fraudulent certificates that DigiNotar informed them about have by now all expired on their own - revocation can't be confirmed yet.
  • If you're a stakeholder in the Dutch PKIOverheid, well then I'd be careful with the preliminary "all is well" messages, I know PKIOverheid a little bit and I know it's one of the strictest things to get a certificate from, but never say never till it's proven. I do understand the need to keep confidence in the system, but that is also achieved by first investigating before saying there is no problem based on false logic and/or irrelevant data.
  • You're a customer of DigiNotar: DigiNotar lost the trust from the browser makers, how permanent that is is too soon to say, but it's a big unprecedented dent.
    If you're a PKIOverheid customer that leaves you a bit more breathing room, and there are 6 more providers to migrate to, and apparently no urgent need to do so.
    Other customers seem to have been offered to migrate to PKIOverheid, but the stringent requirements there might be too much for some, so your best option might be to seek another provider, if you have not done so already.
  • If you're a CA or RA, this is yet another big wake-up call. If you're a 3rd party auditor of said, it's the exact same thing. CAs are now a target.

What is the biggest thing we all lack to better see what impact there is/was ?

  • Full list of fraudulent certificates (CN, SN fields at the very least)
  • Clarity on when each certificate was created and when it was revoked
  • I for one would love to know who that external auditor was that missed defaced pages on a CA's portal, that missed at least one issued fraudulent certificate to an entity that's not a customer, and what other CAs and/or RAs they audit as those would all loose my trust to some varying degree. This is not intended to publicly humiliate the auditor, but much more a matter of getting confidence back into the system. So a compromise that an unnamed auditor working for well known audit company X is now not an auditor anymore due to this incident is maybe a good start.
  • Clarity over what was affected by the hackers, a full report would be really nice to read. Special attention should be given to explain how it is sure PKIOverheid, the qualified certificates etc. are for sure not affected and how privacy of other customers e.g. was affected. Similarly the defacements should be covered in detail as well as how they could be missed for so long.

Obviously it's unlikely we'll get all those details publicly, but the more we get the easier it will be to keep the trust in the SSL "system" in general and more specifically in DigiNotar.

Glossary

  • CA: Certificate Authority
  • CN: Common Name, in case of a SSL certificate for a web server this contains the name of the website, can be a wildcard as well in that case.
  • CRL: Certificate Revocation List a machine readable list of revoked certificates, typically published over http. Contains the Serial Numbers (SN) of the revoked certificates along with some minimal supporting data.
  • "dozens" used in my text above is a somewhat freely translation of the Dutch "tientallen", literally, "multiple tens"
  • ETSI TS 101 456: A technical specification on "policy requirements for certification authorities issuing qualified certificates"; used as a norm in audits of said providers.
    Can be freely downloaded from ETSI: version 1.4.3.
  • EV: extended validation: essentially the same SSL certificate, but with a slightly stricter set of rules on issuing. Most browsers render something like the URL in the address bar in a green color when they see such a certificate
  • PKIOverheid: a PKI system run under very strict requirements by and for the Dutch Government. There are 7 providers recognized to deliver certificates under a root certificate held by the Dutch government. This PKI not only issues certificates to (web) servers, but also to companies and individuals to do client authentication against government websites as well as provide means to create qualified digital signatures.
  • RA: Registration Authority
  • SN: Serial Number
  • SSCD: Secure Signature Creation Device. Mostly a smartcard or smart USB token that holds key pairs used for signing and protects the secret keys

Update History

  • version 1: initial release
  • version 2: updated with more information from the torproject, thanks for the pointer Gary!
  • version 3: update to include the DigiNotar press release of Aug 30th.

--
Swa Frantzen -- Section 66