Distilling 'Flame':
Windows Update spoofing, Flame malware, and MD5 collisions

Jem Berkes
June 29, 2012
jem@berkes.ca


It has been reported that the Flame malware can covertly install malicious code delivered through Windows Update [1]. By using a man-in-the-middle (MITM) attack and a certificate which appears to be digitally signed by Microsoft, the malicious code is accepted by Windows with no warning. Amazingly, the certificate is a forgery — created using an MD5 hash collision [2].

Media hype about the Flame malware's MD5 attack [3] have confused and overshadowed, to some extent, the more serious problem which made these attacks possible: Microsoft's poorly engineered security architecture. Flame is the first instance of malicious certificate forgery in the wild, but practical certificate forgery using MD5 hash collisions was demonstrated years ago [4]. Flame represents a malware milestone, but is not a new class of crypto attack.

This threat boils down to two distinct security issues. Either of these on its own can compromise Microsoft code-signing and Windows Update on many systems. Issue 1 provided the basis for the attack, and Issue 2 extended the attack to all Windows platforms. It's likely that Issue 1 simplified the hash collision problem.

Issue 1: Microsoft's certificate trust architecture was flawed (new issue)

Microsoft has a Terminal Services product, and a 'license server' for Terminal Services. Anyone can run a license server. During the internet-based activation process, the license server creates a public/private key pair and asks Microsoft to sign its certificate. It is automatically granted a certificate that is signed by a Microsoft certificate authority [2]. The resulting legitimate certificate is meant to be used for Terminal Services.

However, it turns out this certificate doesn't have extended key usage restrictions and allows code-signing, inherited from the authority's certificate. This means that anyone who activates their license server has a certificate that allows them to sign code as Microsoft! This appears to have been the case since at least 2010. No hash collision or crypto attack is needed on Windows XP; the certificate is instantly valid for signing any arbitrary code you present to Windows Update.

It's worth noting that this is a critical bug in Microsoft's trust architecture, with many forgery and intrusion consequences.

Vista and Windows7 include an extension in the certificate that safeguards against use for code-signing [2]. To make the certificate work on those platforms, the attacker had to modify/forge the certificate to remove that extension. Cryptographic hashes like MD5 and SHA-1 protect a certificate from tampering. Luckily for the attacker, Microsoft used the weaker MD5 hash (see Issue 2).

Issue 2: Certificates using MD5 hashes are vulnerable to forgery (known issue)

Certificates hashed with MD5 alone are vulnerable to forgery and can result in spoofing attacks. This is true for any application, any operating system.

So what's new, what changed after Flame?

Recommendations

Concluding thoughts on the certificate forgery attack


References

[1] http://www.techspot.com/news/48886-flame-malware-subverts-windows-updates-infects-networked-pcs.html

[2] http://trailofbits.files.wordpress.com/2012/06/flame-md5.pdf

[3] http://arstechnica.com/security/2012/06/flame-crypto-breakthrough/

[4] http://www.win.tue.nl/hashclash/rogue-ca/

[5] http://www.schneier.com/blog/archives/2005/06/more_md5_collis.html

[6] http://technet.microsoft.com/en-us/security/advisory/961509

[7] http://technet.microsoft.com/en-us/security/advisory/2718704