I think you missed reading a part of that Wikipedia article:
… Flame was signed with a fraudulent certificate purportedly from the Microsoft Enforced Licensing Intermediate PCA certificate authority. The malware authors identified a Microsoft Terminal Server Licensing Service certificate that inadvertently was enabled for code signing and that still used the weak MD5 hashing algorithm, then produced a counterfeit copy of the certificate that they used to sign some components of the malware to make them appear to have originated from Microsoft.…
In simpler words this means that the malware author(s) didn’t need to apply for a certificate himself/herself/themselves. Instead, the malware author(s) used a genuine Microsoft certificate he/she/they found and created a fake certificate based on that. That way, it seems as if Microsoft itself has signed some files – which Microsoft (of course) didn’t.
So, your …
thus the only way to get a fake cert is to generate the fake cert when applying for a legitimate cert.
… is partly correct, but it’s only one side of the coin. The other way to get a fake certificate is to find a legitimate but weak and exploitable certificate from someone else – like one from Microsoft in this case.
Having said that, let’s answer your two questions:
- Isn't it too dangerous for the malware author(s) to do this? (We can check who applied for the legitimate cert and catch him)
No, since the fake certificate was based on a Microsoft certificate the malware author(s) got his/her/their hands on. That way, the fake certificate points to Microsoft (just like the genuine certificate it was based on), not the identity of any malware author(s).
- If he can apply for a legitimate cert, why bother making a couterfeit cert? Why don't use the legitimate cert to sign anything he like?
Not being Microsoft, the malware author(s) would hardly have had a chance to apply for a legit Microsoft certificate… and a certificate on his/her/their own name(s) would indeed have been pretty useless for his/her/their intended purposes as that would have added his/her/their name(s) to the equation.
Applying for his/her/their own legitimate certificate would have been a pretty stupid move while having the option to impersonate a trusted company like Microsoft. Remember the fact that the malware author(s) had access to a genuine Microsoft certificate with code signing enabled. (see first quote of my answer)
All in all you could say the malware author(s) found "a pot full of gold at the end of some rainbow" (read: a weak and exploitable Microsoft certificate with code signing enabled) and used what he/she/they found to his/her/their fullest malicious advantage.
Microsoft dropped a ball, and the malware author(s) picked it up. It was that simple for them. After Microsoft became aware of the situation, they handled the situation accordingly.
Quoting "Microsoft releases Security Advisory 2718704" dated June 3, 2012:
We are taking several steps to remove this risk:
- First, today we released a Security Advisory outlining steps our customers can take to block software signed by these unauthorized certificates.
- Second, we released an update that automatically takes this step for our customers.
- Third, the Terminal Server Licensing Service no longer issues certificates that allow code to be signed.
These actions will help ensure that any malware components that might have been produced by attackers using this method no longer have the ability to appear as if they were produced by Microsoft.
But how did they do it?
Quoting an article from “nakedsecurity” – Sophos‘ blog:
In the Flame case, the attackers took a legitimate Microsoft certificate using MD5 for its hash and RSA-2048 for its public-key encryption. They then generated a similar-but-different certificate with the same MD5 hash. This means that the RSA-2048 signature from Microsoft’s genuine certificate could be grafted into their forged certificate to make it appear valid.
Obviously, the above quote doesn’t really provide any real details.
In fact, explaining all the details would be a bit too broad to post as an answer here, but if you really want to dive deeper into an analysis of the Flame MD5 case, check the PDF: “Analyzing the MD5 collision in Flame”. Those 40 pages/slides walk you through details with screenshots etc.
Long story short: For Flame, a chosen-prefix collision attack against MD5 has been used. Its malware author(s) used a new variation of a chosen-prefix collision attack to spoof code signing of its components by a Microsoft root certificate that still used the compromised MD5 algorithm.