Comment by yskchu | Hacker News Reader

Comment by yskchu | Hacker News Reader

More details in the MS technet post: <quote> We have discovered through our analysis that some components of the malware have been signed by certificates that allow software to appear as if it was produced by Microsoft. We identified that an older cryptography algorithm could be exploited and then be used to sign code as if it originated from Microsoft. Specifically, our Terminal Server Licensing Service, which allowed customers to authorize Remote Desktop services in their enterprise, used that older algorithm and provided certificates with the ability to sign code, thus permitting code to be signed as if it came from Microsoft.

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. </quote>

http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft...

This doesn't seem to make a lot of sense. On one hand they say that it's an "older algorithm" which presumably implies that the vulnerability is a simple software implementation bug. On the other they point out that the provided certs had "the ability to sign code", which is a straight up authorization failure (and a staggeringly bad one given the regime). Which is it?

Another alternative... a virus which looks a lot like being coded by the NSA or a similar agency is now found and in the open to be analyzed by everyone. It turns out that it's using a Microsoft signature. Microsoft needs some explanation which isn't completely pissing off all it's customers in the middle east, or wait - let's make that any state-customers worldwide. Yeah, crazy conspiracy theory stuff, I'll put on my tin foil hat now.

If they were going to make this up, they would simply say it was stolen, or the NSA would have had a front company setup for years with some plausible reason for having access to the certificates.

The trick is to make it plausible. You believe this one it seems - mission succeeded :-)

Either that or there never was a mission.

No, I think the MD5 collision hypothesized by rb12345 above makes a lot more sense. Someone went out and audited the full set of code-signing certs, discovered this oddball one, and exploited it. There's no secret in the process that couldn't have been discovered by a suitably determined attacker. It was a very understandable MS process goof that allowed this oddball cert to live.

Yeah, the strange part is just that we're talking about a virus which according to all reports is mostly used for attacks on the middle east. And according to the Kasperksy guys it has a complexity that hints a lot at state sponsorship. We just learned this week that the US has a cyberwar program and works there together with Israel - and that's not even some crazy conspiracy theory but officially acknowledged. Also an Israeli minister hinted that they would use such tools hours after the flame news got reported. The question is - would such an agency rather try to hack the Microsoft certificates or simply ask and tell Microsoft to prepare a good excuse once it blows up? I mean if flame was written by anyone else I'm pretty sure they hacked Microsoft, but that would mean there's someone out there now writing viruses at a level which makes virus experts from Kaspersky think that it can't be done without state sponsorship. Or we have the NSA hacking Microsoft now - well, that would be at least some fun.

If I were a spook, "asking microsoft" would seem like a huge compartmentalization and classification risk. If you were already sitting on an exploitable cert already in the wild, why bother?

As far as I can tell from the patch, the "Microsoft Enforced Licensing Intermediate PCA" certificate had code signing enabled. This is a little silly, but not an issue as long as the corresponding private key is kept safe. Unfortunately, the certificates were signed using MD5(-RSA), which is broken. I believe that what happened is that someone found a collision for this certificate and used the resulting fake certificate with known keys to sign Flame.

Interestingly, one of the revoked certificates expires in 2017 and used SHA-1. This one had certificate signing enabled! It's possible that either the private key for that certificate escaped, or it's being revoked as a precaution to remove the unnecessary capabilities.

Ah, OK. My read was that the certs granted by the Enforced Licensing thing were able to sign code. Your explanation makes a ton of sense to me. They just forgot to audit for MD5-based keys and left this alive in the wild.

Though MD5 is considered utterly broken for cryptographic purposes, AFAIK there are as of yet no known practically viable preimage attacks. Finding a collision for an already signed certificate would require a preimage attack.

There are very cheap collision attacks, which let you to generate two values that hash to the same MD5 signature; an attacker can exploit that by making you sign one object, and then swapping it out with another with the same hash.

That's true. However, it's possible to do it with two co-created certificates (http://www.schneier.com/blog/archives/2008/12/forging_ssl_ce...), and depending on how the licensing process works, that could easily have been done. I would imagine that the creators of Flame have more than enough computing power to do that.

The articles though seem to be suggesting that the "real" certificates were being granted with too many powers. Microsoft's advisory seems to suggest that both were potentially used (MD5 collisions and overly-broad purposes on real certificates). It's hard to tell what really happened here...

At first I imagined that was just a gargled description of the certificates being insufficiently large to prevent a brute-force attack.

Update: others say its that the certificate was mis-configured to allow those fetching the cert to sign themselves as MS... oops.

Most info I can get on this is through a reverse engineer done in 2004 of the RDP (http://efod.se/media/thesis.pdf), it was established that when terminal services set up in Application Server Mode(i.e. corporate environments) its configured to sign requests using the x509 protocol. Wouldn't be much of a stretch to extract the certificates used if they were configured incorrectly. My guess is that due to this being engineered as a licensing issue (i.e. DRM added after the fact and not as a trust issue) corporates weren't issued with specific certs, theres very little that could be done to trace down the point where this leaked.

Worth adding this new link: http://blog.cryptographyengineering.com/2012/06/flame-certif...

So both the code-signing bit and a real life collision! Get the popcorn :)

Am I reading it wrong or did someone spoof a request to the terminal server licensing service? Or was it because they were relying on old compromised SHA1 algorithms?

Reply on news.ycombinator.com