Monday, June 4, 2012

It did not take long ... FLAME on

OK - I promise no further Marvel references.


I do know it has been a while since I have updated this blog but there have been a few changes going on so I sat back and took it all in first. That being said I could not sit back and not comment on the latest discoveries that have come out of the FLAME discussions given how it touches so much of what I have been doing and now what I am doing.


So if you are reading this you likely know what FLAME is - or at least you know what has been published. I suspect that there is still a lot to discover but I wanted to highlight some very important things that come out of what we know so far.



The FLAME malware has been dissected over the last few days and one of the most disturbing finds that has come out, in my view, is the discovery of 3 certificates that appear to be rooted in the Microsoft Root CA.

The certificates in question are:

Microsoft Enforced Licensing Intermediate PCA (2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70) - Issued by Microsoft Root Authority 
Microsoft Enforced Licensing Intermediate PCA (3a 85 00 44 d8 a1 95 cd 40 1a 68 0c 01 2c b0 a3 b5 f8 dc 08) - Issued by Microsoft Root Authority
Microsoft Enforced Licensing Registration Authority CA (fa 66 60 a9 4a b4 5f 6a 88 c0 d7 87 4d 89 a8 63 d7 4d ee 97) – Issued by Microsoft Root Certificate Authority 

The disturbing part of this is that the PCA certs were generated using MD5 as a hashing algorithm. This created an ideal environment against which to attack since MD5 is known to have weaknesses.
Now, of course, we are not yet certain that it was MD5 that was the vector of attack but there certainly is suspicion based on the purported parties behind FLAME (Nation State suspected), along with the fact that the delivery of code was done using these certificates. These facts combined with the fact that the MD5 attacks have been published since 2005 raises the suspicion level even greater.

The fact that the creators/designers took advantage of this attack to go after the MSUpdate service and the MS license registration process is powerful. This style of attack creates a number of vulnerabilities:
  • Raises the risks when performing the required MS registration of any product that may have been officially registered. Today it appears it was only against the Terminal Services environment but the complete story may be different than this.
  • The attack creates a Man-in-the-middle (MITM) risk for any machine where these certs were injected.
  • The PCA certs have a broad use base defined within their extended key usage including code signing and possibly more worrisome CRL signing. The extended uses for these certificates were critical in allowing the attack to happen (code signing usage) and potentially for preventing discovery with the fact that they also have CRL signing capabilities.

The CRL signing risk is significant since as long as a system has these certs in the trusted store the CRLs are inherently untrusted. The timeframe for these certs to have been in place and the certificates that may have been trusted through the path defined by these certs also raises the potential of further down stream risk.

This of course was a directed attack against the system using known vulnerabilities but it also raises questions/concerns with processes within Microsoft. These concerns include:
-       Use of MD5 for signature hashing
-       Broad definition of key usage for given certificates
-       Lifetime of intermediate CAs given the ever changing technology environment

So outside of the obvious issues for anyone that was impacted directly by FLAME this does highlight a number of weaknesses in managing environments. Ones own environment may be greatly influenced by those you deal with. In this case an injection occurred, likely, through a software registration process. It was achievable due to poor management of signature algorithms and certificate usage settings. This attack demonstrates that these types of attacks are achievable and likely have been for at least 5 years.

So if you were not paying attention to what certificates were in your stores before I hope you will now. You need to:
  • Look for known bad ones;
  • Evaluate what roots you trust, and why;
  • Look at what signing, hashing and key lengths are used and;
  • Look at what certificate lifetimes are indicated
This area of Certificate and Key management is becoming more critical as it no longer just touches how I secure my running shoe purchase on Zappos but now it affects how I get software and how I trust that and in todays cloud-based world that is a potentially disconcerting issue.

No comments: