Microsoft Emergency Bulletin: Unauthorized Certificate used in "Flame"
Microsoft just released an emergency bulletin, and an associated patch, notifying users of Windows that a "unauthorized digital certificates derived from a Microsoft Certificate Authority" was used to sign components of the "Flame" malware.
The update revokes a total of 3 intermediate certificate authorities:
- Microsoft Enforced Licensing Intermediate PCA (2 certificates)
- Microsoft Enforced Licensing Registration Authority CA (SHA1)
It is not clear from the bulletin, who had access to these intermediate certificates, and if they were abused by an authorized user, or if they were compromised and used by an unauthorized user. Either way: Apply the patch.
The bulletin also doesn't state if this intermediate certificate authority or certificates derived from it could be used to fake the patch. Microsoft Certificates are used to sign patches, and a compromise could lead to a sever break in the trust chain. The use of a "real" Microsoft certificate is surely going to increase the speculations as to the origin of Flame.
[1] http://technet.microsoft.com/en-us/security/advisory/2718704
[2] http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-releases-security-advisory-2718704.aspx
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
========== UPDATE 1 (04 June) ===========
We'll update this story as we learn more
A post today from Microsoft sheds more light on this:
[3] http://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-certification-authority-signing-certificates-added-to-the-untrusted-certificate-store.aspx
If you are not patched or otherwise mitigated, your workstation will trust code signed with this cert - remember that patch Tuesday is coming up, this could go very bad very quickly !!
The certificates in question are issued by "Microsoft Root Authority" or "Microsoft Root Certificate Authority". "Microsoft Root Authority" is certainly in my browser list trusted for "All issuance policies" and "All application policies".
This lends more weight to the wording in the original SA [1], which indicated that these certs can be used in MitM (Man in the Middle) attacks on SSL as well as code signing.
We've discussed the potential in the past for pushing malware as a patch, but seeing this as possible in a major platform like Windows is NOT common !
The patch provided by Microsoft removes trust for these, but you can do this yourself in your browser, or by using the CERTUTIL command line method. However, I don't see anything in my list that looks like what's been compromised - and in order to move a CA to the untrusted list it needs to be in your list in the first place. Removing the Microsoft Roots are (of course) not recommended !
========== Update 2 (04 June) ==========
I've had a reader ask - how do I remove these from the Trusted Publishers list without applying a patch that I haven't yet tested?
Simple, you can use certutil. For instance, to remove the first cert ("Microsoft Enforced Licensing Intermediate PCA", with a Thumbprint of "2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70" ), enter the command:
certutil -delstore authroot "2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70"
After you delete the offending items (or apply the patch), you can easily check the status in IE, under "Untrusted Publishers" tab in the "Content" / Publishers section
========== UPDATE 3 (05 June) ===========
Our reader Matthijs correctly points out that in this case you cannot delete what is not there. If you don't have these in your Cert Store in the first place, you cannot delete them with this method. Check his comments (and his link) in the comments section - some great input there, thanks Matthijs !
===========
Rob VandenBrink
Metafore
Application Security: Securing Web Apps, APIs, and Microservices | Washington | Dec 13th - Dec 18th 2024 |
Comments
Alan
Jun 4th 2012
1 decade ago
If that is indeed what happened, then there did not have to be theft of a CA or code signing certificate to enable the scenario in question. MS willingly made the legitimate signing certificates available.
John
Jun 4th 2012
1 decade ago
Alan
Jun 4th 2012
1 decade ago
Unless you are Iran, Israel, Sudan, Syria, Lebanon, Saudi Arabia, Egypt or one of the other middle-east countries being targeted, it is /highly unlikely/ you will have a chance to observe this beast in the wild.
Just Some Guy
Jun 4th 2012
1 decade ago
Poor response from Microsoft, little to no technical information. It's a critical security issue yet they don't even issue a security bulletin for it!
Jimmy
Jun 5th 2012
1 decade ago
Matthijs
Jun 5th 2012
1 decade ago
dsh
Jun 5th 2012
1 decade ago
Matt (again)
Jun 5th 2012
1 decade ago
EXPERIMENT. https://isc.sans.edu/ uses the following certificate chain:
Entrust.net Secure Server Certification Authority
---+ USERTrust Legacy Secure Server CA
------+ isc.sans.org
Start Firefox with a blank page and delete "USERTrust Legacy Secure Server CA" from the Firefox certificate store (if you're unsure, make a backup first by exporting it). You can find it under the "Authorities" tab, under "Entrust.net". Note that Firefox brings its own certificate store which is fully independent of the Windows certificate store.
Now open https://isc.sans.edu/ and take another look in your Firefox certificate store: the certificate is back again! What just happened?!? Firefox received the intermediate certificate from isc.sans.edu and has re-added it to your _personal_ Firefox certificate store (the one in your Firefox profile).
LESSONS LEARNED FROM THIS EXPERIMENT:
(1) Deleting an intermediate certificate from _Firefox_ is pointless, as it is simple readded to your store if provided with the payload.
(2) Apart from _system_ certificate stores, there are also such things as _personal_ certificate stores. So, deleting a certificate may remove it either from your _personal_ store or from the _system_ store, but another user might still have the particular trusted certificate in her personal store!
Although there are some differences between the Firefox certificate store and the Windows certificate store, both Windows and Firefox come with _system_ and _personal_ certificate stores. However, intermediate certificates seem not to be added automagically to any of the WINDOWS certificate stores (at least in XPSP3).
Interestingly the intermediate certificate "USERTrust Legacy Secure Server CA" is NOT found in any of the certificate stores on my PC: nor in my account's HKCU/Software/Microsoft/SystemCertificates/, nor in HKLM/Software/Microsoft/SystemCertificates/ (note: I'm using slashes because of disappearing backslashes when posting to this site).
Since I do not get errors when visiting https://isc.sans.edu/ using MSIE8, and more importantly, if I look at the certificate chain in MSIE8 by clicking the lock icon, I notice that "USERTrust Legacy Secure Server CA" is present! So this certificate must be loaded _temporarily_ (e.g. in memory only).
Conclusion: deleting intermediate certificates is pointless. You can only rely on revocation (which is known to be very unreliable), _or_ (preferably) you should import the same certificate in the _revocation_ branch of the SYSTEM certificate store. Only in that case you can be certain that the particular certificate will be untrusted (regardless of whether it is present in one of the _trusted_ stores or not).
Side note: don't rely on Firefox when testing whether you've correctly configured your https server to send both your server certificate and any intermediate certificates. Firefox may have cached the intermediate certificate(s) from another site! Either use a fresh Firefox installation with a new profile, or use another browser.
Erik van Straten
Jun 5th 2012
1 decade ago
In the context of this vulnerability this is irrelevant, as intermediate certificates are processed dynamically by Windows anyway when submitted with the payload.
However, in case of compromised ROOT certificates, deleting them instead of blacklisting them basically does the job, provided that you remove the offencing certificate from the _system_ certificate store AND from _each_ of your users's personal stores.
Hence blacklisting is a lot easier - and the most secure way to go.
Erik van Straten
Jun 5th 2012
1 decade ago