SANS ISC: Microsoft Emergency Bulletin: Unauthorized Certificate used in "Flame" - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Apply the patch, possibly break your proxy unless you are using a Microsoft proxy. Given the lack of info, it's hard to tell what will break by applying the patch or what the real risk of delay is. Either way, this is just another illustration that HTTPS and the CA structure is fundamentally flawed. Any word on proxy vendor responses anyone has heard?

As I understand it from the blog post linked to from the story, there is a license management option for Windows Terminal Services, which allows companies to manage license usage by TS clients. Companies that use this lic. mgt. service get a certificate signed by Microsoft, which allows code signing, among other functions. Any code signed using one of these certificates appears to come from Microsoft, not from the MS customer using the LM service.

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.

Could already be going very bad. I've had two sites today with machines that have been sending HTTPS floods to unnamed Microsoft IPs that resulted in our firewalls shutting down traffic. We have shut down the three machines identified and are investigating - could be coincidental or diversionary... Anyone else seeing this?

Nope, Alan -- this isn't a DDOS platform, nor is it your traditional randomly-replicating worm. It wouldn't be generating "HTTPS floods" (btw: how much is a flood?) and certainly not to Microsoft (to what end?)

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.

Interesting that of all the news releases over this 'patch', none state any potential issues. Is this going to break enterprise environments running terminal services/remote desktop? Given that these are *Microsoft* ICAs we're untrusting, not rogue certificates, we're effectively breaking the trust chain. What legitimate stuff is hanging off the bottom of that chain? I would find it hard to believe that nothing depends on these ICAs.

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!

If these certificates don't exist on your system, deleting these thumbprints from the authroot with certutil (certutil -delstore authroot) won't work. You need the actual blob to add the certificate to the untrusted store. I've described how to do this on http://www.cupfighter.net/index.php/2012/06/mskb2718704-unauthorized-digital-certificates-could-allow-spoofing/

http://blogs.technet.com/b/msrc/archive/2012/06/04/security-advisory-2718704-update-to-phased-mitigation-strategy.aspx

This is published in WSUS under as a "Critical Update:" http://catalog.update.microsoft.com/v7/site/Search.aspx?q=2718704

IMPORTANT: DELETING _INTERMEDIATE_ CERTIFICATES IS POINTLESS!

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.

I should add a comment: in Windows even ordinary users can import certificates in the Windows certificate store - but only in their personal section of it. And, even if they are not aware of it, software (trustworthy or malicious) they run might do this for them.

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.

Flame self-destruct cmd sent ...
- http://www.symantec.com/connect/blogs/flamer-urgent-suicide
6 Jun 2012
.