One of the greatest concerns of an information security person is doing something that inadvertently enables someone to have access or even take control of data or systems that they should not have access to. In reality this is exactly what FLAME is doing – taking advantage, in a very planned way, of a number of small vulnerabilities that exist in systems. How it does this is very creative and very dangerous. It exposes not just those systems that are infected today but demonstrates an attack vector that may be available for some time. This post will try to explore those ideas.
The FLAME malware has been dissected over the last few days and one of the most disturbing finds that has come out is the discovery of 3 certificates that appear to be rooted in the Microsoft Root CA. These certificates are used for many purposes, including code signing and CRL signing. We will get back to why that is important in a bit.
The big question for many is how did FLAME get into systems? The, apparently, fraudulent certificate seems to be the key to that. The creators of FLAME appear to have created a certificate that is trusted by the Microsoft Root CA. It appears that this was accomplished by taking advantage of a weakness in the hashing algorithm that was used to create the CA's certificate. The hashing algorithm that was used was MD5. This algorithm has been shown to have a weakness that allows an entity with enough computing resources to create a whole new certificate with the same hash. This is of course the working theory, as true confirmation will require more investigation, but this is not the first time a certificate has had its hash recreated using different data. In fact this was first done in 2005 leveraging networked PS3 Playstations. Once this certificate was created it was a matter of injecting it into a system and since it appeared to be trusted by the Microsoft Root CA most applications would automatically trust it, including the OS.
This is where the malware developers were very creative. In creating the certificate using the hash of existing Microsoft PCA and RA certificates they were able to be trusted for the same purpose, which included code validation and CRL signing. The CRL signing becomes important since the CRL issued by a CA is the list of certificates that were issued by the CA that are no longer trusted. Having the capability to sign a CRL meant that even if a bad certificate was found the perpetrators could easily just issue a CRL that did not have the certificate on it.
It appears that FLAME was intended to perform a similar function as to that of Duqu, an earlier piece of malware. There are similarities in that the intended purpose of both appears to be data collection. What is interesting is that Duqu did appear to collect certificates and, where possible, private keys. This may indicate some linkage between the two but right now that would be pure speculation. Duqu does have similarities to the earlier discovered Stuxnet malware code, which was very targeted in its actions. It performed some data collection activities, but its major purpose was to disable command and control systems in SCADA-like systems.
The question for most readers at this point is - "Why should I be concerned?"
Well the concern arising from this is a very real concern. It is not a concern that FLAME may affect you, even though it is possible that it could, but so far it has affected a very targeted set of systems. The greater concern is the attack vector that was used.
Much like Duqu and Stuxnet, FLAME leveraged vulnerabilities within the Microsoft platform. Duqu and Stuxnet leveraged zero-day vulnerabilities for code delivery, FLAME apparently took advantage of a weak hashing algorithm that was used on a set of certificates that had broad application use. This type of vulnerability also raises questions about processes within Microsoft when they create CAs and when they assign usage parameters. 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. One's 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.
Read the Venafi Security Alert: MD5 Vulnerability and learn more about how to identify your MD5 certificates.