Fraudulent Certificates...Again

If you did not hear about the latest saga of "rogue certificates" out there because of a Dutch company called DigiNotar by now, well, you are not paying attention to the security news :)

Certificate Authorities are backbone of Trust system we use for "secure" online access. To see that "lock" icon in the browser when we visit a site with an SSL certificate, and even a green bar if the site has an Extended Validation SSL (EV SSL), may give us a sense of security, which unfortunately proving to be a "false sense of security" these days.

There are plenty of articles out there on what happened (even a Wiki), how it happened, who got involved and what Microsoft, Google, Mozilla, etc are doing to contain damage, even a Wiki about it but also what you should be aware of. Here is one from Windows Secrets that explains it in laymen terms. I personally liked the detailed account from Firefox folks.

If you are reading this blog, you are probably interested in an easier way to find whether you have a cert or not and PowerShell can come to the rescue:

PS C:\Users\Adil> gci certificate::LocalMachine\Root |?{$_.subject -match "DigiNotar"}

I do not have it on my machine, so I won't go further but you if you search only "Digi", you will see some results:

PS C:\Users\Adil> gci certificate::LocalMachine\Root |?{$_.subject -match "Digi"}

    Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\Root

Thumbprint                                Subject

----------                                -------

5557C0953FBD9F93745B214FB2483E9369B597F0  CN=DT Soft Ltd, OU=Digital ID Class 3 - Microsoft S
5FB7EE0633E259DBAD0C4C9AE6D38F1A61C7DC25  CN=DigiCert High Assurance EV Root CA, OU=www.digic
3E2BF7F2031B96F38CE6C4D8A85D3E2D58476A0F  CN=StartCom Certification Authority, OU=Secure Digi
0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43  CN=DigiCert Assured ID Root CA,

Unfortunately, Safari / OS X does not have a mechanism to detect Revoke Lists (RL) but Apple should be releasing an update soon to fix the chain. In the mean time you can open up 'Keychain Access' tool and remove the DigiNotarRoot Certificate from GUI but where is the fun in that?

If you double click the certificate, you get detailed information as shown below.

And what if you had to do this on multiple Macs in an enterprise environment? You would want to use command line to do it. The command for all certificate related work is named 'security'.

You can dump a pretty list of all Root CAs in OS X using 'dump-keychain' parameter of 'security' command, which, as we mentioned above, is used to manipulate Keychains from command line.

If we only wanted to display the Friendly names of certificates, which would be equivalent of what we see in 'Keychain Access' GUI, we can filter by 'labl'

adil$ security dump-keychain "/System/Library/Keychains/SystemRootCertificates.keychain" |grep labl

    "labl"<blob>="Prefectural Association For JPKI"
    "labl"<blob>=" Certification Authority (2048)"
    "labl"<blob>="AOL Time Warner Root Certification Authority 1"
    "labl"<blob>="AOL Time Warner Root Certification Authority 2"

We can filter the results that start with 'D' and while at it, beautify it by getting rid of '=' and everything before it:

adil$ security dump-keychain "/System/Library/Keychains/SystemRootCertificates.keychain" |grep labl |awk -F '=' '{print $2}' |grep ^\"D

"DST Root CA X4"
"Deutsche Telekom Root CA 2"
"DigiCert Assured ID Root CA"
"DigiCert Global Root CA"
"DigiCert High Assurance EV Root CA"
"DigiNotar Root CA"
"DoD CLASS 3 Root CA"
"DoD Root CA 2"
"DST Root CA X3"

We can use also use find-certificate parameter to find the certificate and print all info. (-a for all keychains, not actually necessary here as we know this is a Root Certificate but good to be safe. If you happen to know the e-mail you could also use -e parameter)

adil$ security find-certificate -a -c "DigiNotar"/System/Library/Keychains/SystemRootCertificates.keychain
keychain: "/System/Library/Keychains/SystemRootCertificates.keychain"
class: 0x80001000
    "hpky"<blob>=0x8868BFE08E35C43B386B62F7283B8481C80CD74D  "\210h\277\340\2165\304;8kb\367(;\204\201\310\014\327M"
    "issu"<blob>=0x305F310B3009060355040613024E4C31123010060355040A1309444947494E4F544152311A301806035504031311444947494E4F54415220524F4F542043413120301E06092A864886F70D0109011611696E666F40646967696E6F7461722E6E6C  "0_1\0130\011\006\003U\004\006\023\002NL1\0220\020\006\003U\004\012\023\011DIGINOTAR1\0320\030\006\003U\004\003\023\021DIGINOTAR ROOT CA1 0\036\006\011*\206H\206\367\015\001\011\001\026\"
    "labl"<blob>="DigiNotar Root CA"
    "skid"<blob>=0x8868BFE08E35C43B386B62F7283B8481C80CD74D  "\210h\277\340\2165\304;8kb\367(;\204\201\310\014\327M"
    "snbr"<blob>=0x0C76DA9C910C4E2C9EFE15D058933C4C  "\014v\332\234\221\014N,\236\376\025\320X\223<L"
    "subj"<blob>=0x305F310B3009060355040613024E4C31123010060355040A1309444947494E4F544152311A301806035504031311444947494E4F54415220524F4F542043413120301E06092A864886F70D0109011611696E666F40646967696E6F7461722E6E6C  "0_1\0130\011\006\003U\004\006\023\002NL1\0220\020\006\003U\004\012\023\011DIGINOTAR1\0320\030\006\003U\004\003\023\021DIGINOTAR ROOT CA1 0\036\006\011*\206H\206\367\015\001\011\001\026\"

Well, enough playing. To delete the certificate, we will use 'delete-certificate' command. We have two choices:
1) Use -c parameter which is using 'common name'
2) Use SHA-1 fingerprint (safer).

Let's do both.

1) We need to use common name. This is the name you see in the GUI and we seem to get it from 'labl' line above. Command becomes

adil$ sudo security delete-certificate -c "DigiNotar Root CA" /System/Library/Keychains/SystemRootCertificates.keychain

2) As mentioned above, using SHA-1 fingerprint is less error-prone than relying on common names. To do that, we have to first locate the fingerprint. Noticed that it was not showing above when we displayed the certificate?

OK, so how do we get the fingerprint? Simple: we add -Z to the 'find-certificate' command which returns SHA-1 in the first line and then prints what we have seen above. So we will simply 'grep' the fingerprint:

adil$ security find-certificate -a -c "DigiNotar" -Z /System/Library/Keychains/SystemRootCertificates.keychain |grep SHA-1

SHA-1 hash: C060ED44CBD881BD0EF86C0BA287DDCF8167478C

And now we can get rid of the certificate:

adil$ sudo security delete-certificate -Z  C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain

Well that's all. Now, all you would need is to put these two lines in a shell script (find fingerprint if certificate exists & delete it), then run it against all your Macs.

Note that in general Safari and Chrome honor system-wide certificates, however, some versions of Firefox is not using the Keychain to store/retrieve certificates. It has its own database and you might need to manipulate that as well. Also note that browsers have their own list of trusted CAs so updating Chrome and Firefox would solve the problem as of today.

Update: There are several articles about why revoking this certificate may not be enough because of the way EV SSL treated in Safari. If you delete the certificate, this should not be a concern. However, there seems to be additional certificates that needs to be revoked to be safer.

In any case, I visited DigiNotar web site on Safari and found a page with "Order" button that takes you to another page with SSL. As soon as I clicked the "Order" link, Safari warned me that the certificate on the site was invalid (expired).

As far as I can tell chain goes like this:
DigiNotar Root CA -> DigiNotar Services 1024 CA -> *

So this seems to be good sign. I tried some other sites but I am yet to find a site that was issued and SSL from the the Root CA I deleted.

Update2: I saw mentioned as a test site here.  This is what I got on Safari:

It's good that I am getting a notification. Unfortunately, it is not because DigiNotar Root CA is missing from my Root keychain but because certificate has expired.

Update3: Apple today released a security patch to put the issue at rest. In their terms, here is what they did:
Description: Fraudulent certificates were issued by multiple certificate authorities operated by DigiNotar. This issue is addressed by removing DigiNotar from the list of trusted root certificates, from the list of Extended Validation (EV) certificate authorities, and by configuring default system trust settings so that DigiNotar's certificates, including those issued by other authorities, are not trusted.

Of course, they would not tell exactly what they did.  I had a pretty good idea which file they were talking about. Let's look at the last one "configuring default system trust settings":

adil$ pwd

adil$ ls -l
total 1048
-rw-r--r--  1 root  wheel    5353 Sep  9 17:53 EVRoots.plist
-rw-r--r--  1 root  wheel  167848 Jul  9 23:39 SystemCACertificates.keychain
-rw-r--r--  1 root  wheel  395312 Sep  9 17:53 SystemRootCertificates.keychain
-rw-r--r--  1 root  wheel   86380 Sep  9 17:53 SystemTrustSettings.plist
-rw-r--r--  1 root  wheel  282984 Jul 28  2008 X509Anchors

So backed up these files before applying the patch and ran a diff. First let's look at a record in the last one.

The bottom is the original, and above you see the updated file. Basically they updated the date and added a new array with a dictionary which set kSecTrustSettingsResult to 3.

Notice that I am looking at the Key that starts with C060E... which is the SHA-1 fingerprint we got above.

Also notice that IssuerName, we know that's DigiNotar. As noted in some of the links above, there were several certs by DigiNotar published by others. I can tell from the diff which are the ones that were affected but I cannot tell a way of figuring them out only by looking at the original as Issuer Names would be different and don't have a list of chains where DigiNotar exists.

No comments: