The purpose of the collision attack used in the Flame malware

Title: The purpose of the collision attack used in the Flame malware
Alternative title: Why did the Flame malware use a hash collision?

When news about the Flame malware broke out, a lot of information became available, including that Flame used an executable signed by a code-signing certificate and that this certificate worked (in spite of being fraudulent) because it was crafted so as to produce an MD5 hash collision.

When I read about it, I thought I understood everything. Obviously, I thought at the time, the executable needed to be signed with a code-signing certificate, in order to appear legit. But if someone were to even casually examine the executable, she would immediately see who the certificate was issued to. This is why code-signing certificates exist: to show who wrote the software that is signed by them. So, by trivial examination of the executable’s certificate, the malware authors would be discovered. So the malware authors needed to sign their executable with a specially crafted certificate. The authors would craft the certificate in such a way so as to produce a valid hash signature, although the certificate’s information would not include their identity. Thus, to produce a valid certificate with false or no identity information, a hash collision has to be used. So, I thought that this was the reason why the malware authors used a collision attack technique.

But I was incorrect.

In fact, the malware authors did not need to use a hash collision for any such purpose, because the certificate they used was allowing them to sign any software as if they were Microsoft itself. Let me restate this, in order to make it absolutely clear: any code that was signed by the certificate appeared to have been signed by Microsoft.

Microsoft had been handing these all-powerful certificates to its customers. Actually, the certificates’ only use was to license access to Terminal Servers and Remote Desktop Servers. They were all-powerful by mistake. So, any customer with a licensed TS or RDS environment had the ability to sign any executable as if they were Microsoft itself. Any such certificate that was issued for licensing TS or RDS environments had this dangerous capability.

So, all the malware authors had to do was obtain such a certificate and they could have used a legal way of obtaining it, i.e. from Microsoft. The act of signing any executable with the certificate would not expose their identity. The executable would appear to have come from Microsoft.

This is one of the rare cases where malware authors do not have to use a hash collision technique. And this is because an oversight (from the part of a certificate issuer) as major as that is rare.

So why did the malware authors use a collision attack, if their identity was not exposed by the original certificate? The reason is that the original certificate failed to validate on newer operating systems. They wanted to craft the certificate in a way that would make it valid in all operating systems.

For more information, please refer to the following blog posts:

About Dimitrios Kalemis

I am a systems engineer specializing in Microsoft products and technologies. I am also an author. Please visit my blog to see the blog posts I have written, the books I have written and the applications I have created. I definitely recommend my blog posts under the category "Management", all my books and all my applications. I believe that you will find them interesting and useful. I am in the process of writing more blog posts and books, so please visit my blog from time to time to see what I come up with next. I am also active on other sites; links to those you can find in the "About me" page of my blog.
This entry was posted in Security. Bookmark the permalink.