Published in Editorials

Flame Authors Used A Vulnerability in MD5 that Microsoft Knew About in 2008

by on15 June 2012 3775 times

broken-lockAs I was wandering the internet today and looking for something interesting to write about I stumbled upon an article that made me laugh a little. The article was talking about the Flame virus and how the methods used to crack open Microsoft’s certificates (called a collision) is a big issue. Now do not get me wrong, the entire Flame malware was a big deal and not just the ability to spoof Microsoft’s certificates to make the code seem legitimate.

The problem (to be perfectly honest) all falls into Microsoft’s lap here. We have been criticized for our take on the dangers of cloud computing, but here is a very nice example of what can happen (another is the recent outage to Amazon’s Web Services). In this case Microsoft failed to update a certificate service that was using an old and already broken encryption scheme (MD5). MD5 should never have been in the mix at all and considering the side spread use of Microsoft systems in the world the fact that it was (and still is) is a serious issue.

Sure the creators of the malware had to develop a very sophisticated method to re-issue a valid looking certificate, but outside that any certificates issued were not secure in the first place. Microsoft first warned that their own MD5 hash was broken in 2008! At the time they stated in their vulnerability bulletin (MSA961509);

Microsoft is aware that research was published at a security conference proving a successful attack against X.509 digital certificates signed using the MD5 hashing algorithm. This attack method could allow an attacker to generate additional digital certificates with different content that have the same digital signature as an original certificate. The MD5 algorithm had previously shown a vulnerability, but a practical attack had not yet been demonstrated.  

Why in the world was Microsoft still using this type of hash for certificates of any type? So the most worrisome revelation of 2012 is that even with warnings and foreknowledge of security flaws and issues we still have insecure software and systems in operation on the internet. Now at the time the flaw only related to X.509 certificates, but considering the MD5 hash was shown as flawed it was only a matter of time before they all fell. It was less than four years from the time that someone found a single flaw in the MD5 hash until they managed to exploit the whole certificate system. Considering the fact that the original flaw was in 2008 we have a feeling that some of the claims of needing a massive computer to accomplish this might be overrated. There are several pieces of software that leverage the power of a GPU to break encryption strings so the system used might not have been much more than a system with a few graphics cards thrown into it. Now add into the mix the fact that MD5 was already at least partially compromised and you can see how little effort it might have actually taken to get in.

But if 2008 is not far enough back for you to be annoyed about how does 1996 grab you? In 1996 researchers found a way to produce a partial hash collision in MD5 and it was no longer recommended for use in SSL certificates or as a digital signature for code… In 2004 the full hash collision was demonstrated, it was almost a year later (2005) than someone showed how to generate fake certificates thought the use of a hash collision in under one minute ON A STANDARD NOTEBOOK and Microsoft knew about it.

It is a common practice to use SHA-1 or the more secure SHA-2 for certificates and for better encryption as even SAH-1 has been partially broken (back in 2004).

Remember, when you hear about attacks, exploits, hacks and now massive nation sponsored malware it is not through complex and intrusive measures that people are getting in. You always look for the path of least resistance which in many cases is the thing that should have been patched, fixed or updated that was not.

Discuss this in our Forum

Last modified on 15 June 2012
Rate this item
(0 votes)

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.