Today, we released Security Advisory 2718704, notifying customers that unauthorized digital certificates have been found that chain up to a Microsoft sub-certification authority issued under the Microsoft Root Authority. With this blog post, we’d like to dig into more technical aspects of this situation, potential risks to your enterprise, and actions you can take to protect yourself against any potential attacks that would leverage unauthorized certificates signed by Microsoft.
We’d also like to share how this issue relates to a complex piece of targeted malware known as “Flame”. As many reports assert, Flame has been used in highly sophisticated and targeted attacks and, as a result, the vast majority of customers are not at risk. Additionally, most antivirus products will detect and remove this malware. That said, our investigation has discovered some techniques used by this malware that could also be leveraged by less sophisticated attackers to launch more widespread attacks. Therefore, to help protect both targeted customers and those that may be at risk in the future, we are sharing our discoveries and taking steps to mitigate the risk to customers.
- How did this happen?
- What Microsoft is doing to protect customers
- Thumbprints of affected certificates
- Connection to Flame malware
How did this happen?
When we initially identified that an older cryptography algorithm could be exploited and then be used to sign code as if it originated from Microsoft, we immediately began investigating Microsoft’s signing infrastructure to understand how this might be possible. What we found is that certificates issued by our Terminal Services licensing certification authority, which are intended to only be used for license server verification, could also be used to sign code as Microsoft. Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing without accessing Microsoft’s internal PKI infrastructure.
What Microsoft is doing to protect customers
As soon as we discovered the root cause of this issue, we immediately began building a update to revoke the trust placed in the “Microsoft Enforced Licensing Intermediate PCA” and “Microsoft Enforced Licensing Registration Authority CA” signing certificates. That update is available today through Windows Update and Automatic Updates. This update places three certificates into the Windows Untrusted Certificate Store.
We have also discontinued issuing certificates usable for code signing via the Terminal Services activation and licensing process.
Thumbprints of affected certificates
While we encourage all customers to apply the officially tested update to add the proper certificates to the Untrusted Certificate Store, as an alternative you can instead place the certificates there in another way. For example, it might be more convenient to use the certutil command or the Certificates MMC snap-in. Or you might instead choose to manage trusted and untrusted certificates in your enterprise via group policy. Here are the thumbprints of the certificates to be placed in the Untrusted Certificates Store.
| Certificate | Issued by | Thumbprint |
|---|---|---|
| Microsoft Enforced Licensing Intermediate PCA | Microsoft Root Authority | 2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70 |
| Microsoft Enforced Licensing Intermediate PCA | Microsoft Root Authority | 3a 85 00 44 d8 a1 95 cd 40 1a 68 0c 01 2c b0 a3 b5 f8 dc 08 |
| Microsoft Enforced Licensing Registration Authority CA (SHA1) | Microsoft Root Certificate Authority | fa 66 60 a9 4a b4 5f 6a 88 c0 d7 87 4d 89 a8 63 d7 4d ee 97 |
Connection to Flame malware
Components of the Flame malware were signed with a certificate that chained up to the Microsoft Enforced Licensing Intermediate PCA certificate authority, and ultimately, to the Microsoft Root Authority. This code-signing certificate came by way of the Terminal Server Licensing Service that we operate to issue certificates to customers for ancillary PKI-based functions in their enterprise. Such a certificate could (without this update being applied) also allow attackers to sign code that validates as having been produced by Microsoft.
Conclusion
We recommend that all customers apply this update.
- Jonathan Ness, MSRC Engineering