Microsoft Certificate used to sign "Flame"

http://isc.sans.edu/diary.html?storyid=13366&rss

by alister • 14 years ago

160 47 14 years ago

isc.sans.edu

SlipperySlope2• 14 years ago

It would be useful to solve the mystery of how the chain of trust was compromised.

Was a Microsoft employee involved?

Can't we have some sort of chain of trust beyond the reach of sovereign governments?

yuhong• 14 years ago

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

SlipperySlope2• 14 years ago

From the link ... How did this happen?

"When we [Microsoft] initially identified that an older cryptography algorithm could be exploited and then be used to sign code as if it originated from Microsoft, we immediately began investigating Microsoft’s signing infrastructure to understand how this might be possible. What we found is that certificates issued by our Terminal Services licensing certification authority, which are intended to only be used for license server verification, could also be used to sign code as Microsoft. Specifically, when an enterprise customer requests a Terminal Services activation license, the certificate issued by Microsoft in response to the request allows code signing without accessing Microsoft’s internal PKI infrastructure."

Interesting. The Microsoft Terminal Services CA has the corporate identity, but not the corporate trust chain. Is this a deliberate back-door provided to the US government, or simply an ordinary vulnerability?

We need some sort of certification, an independent audit, of X509 certificate authorities and their trust chains. Agreed?

zmanji• 14 years ago

Is this more serious than the signing for stuxnet?

Fire30• 14 years ago

I think it is due to whose signature it is. Stuxnet was signed by Realtek, while Flame had Microsoft's signature.

semenko2• 14 years ago

Maybe:

1. The certificate appeared to be available to anyone who was looking hard enough. Microsoft provided the misconfigured certificate to anyone activating their Terminal Services product (!). Pretty embarrassing.

2. It's not evident what the signing requirements are for Microsoft Automatic Updates code (at least I can't find them). Presumably they validate an explicit Windows Update chain, but if they don't, this could perhaps enable an attacker to auto-install the Flame virus as an update. I doubt that would be the case, but their security announcements aren't very forthcoming.

marshray2• 14 years ago

The Windows Update signing requirements are, AFAICT, not documented and they do require a special chain. Whether having Microsoft in the root is special enough is another question.

Regardless, it appears that a signed driver is enough to pwn any modern Windows box via USB. "The system is installing driver software for your device..."

EDIT: What it most likely would work for over the network would be a man-in-the-middle attack on users who "Always trust ActiveX controls from Microsoft". Not to mention plain old impersonating websites for users of MSIE and Chrome.

A scary but plausible possibility is that an attacker with such a cert could forge client certificate credentials to obtain remote access via RDP, MS Terminal Services Gateway, ISS certificate mapping, etc.

yskchu• 14 years ago

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

ajross4• 14 years ago

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?

coffeeaddicted3• 14 years ago

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.

rb123452• 14 years ago

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.

dmboyd2• 14 years ago

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?

willvarfar2• 14 years ago

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.

dmboyd2• 14 years ago

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.

techinsidr• 14 years ago

A little more detail: http://www.securityweek.com/microsoft-unauthorized-certifica...

Maxious• 14 years ago

Aren't you glad Microsoft is the de facto code signer for UEFI Secure Boot now? ;)

mtgx• 14 years ago

It's just one of many reasons why Microsoft alone shouldn't decide what operating systems can work on UEFI machines. If the future is UEFI, then we need an industry body like the W3C or something to work with OS vendors, not just Microsoft.

carey• 14 years ago

It doesn't really seem like something the W3C would be involved with. The IEEE isn't perfect, but should be able to look after something like this.

nl2• 14 years ago

The idea that an industry body would be more secure than the security department of major software company is something I don't see a lot of evidence for. Apart from the root DNS servers I can't think of any.

There are plenty examples of companies keeping something secure. There aren't many of industry bodies.

I'd trust a bank (well, some banks) before I'd trust either the W3C or IETF with the keys to the universe.

recoiledsnake2• 14 years ago

Maybe you can propose a better signer? The OEMs seem willing to add keys for Red Hat and probably anyone else that can come up with a trustworthy solution that can keep rogue malware at bay.

It's not like other software projects or companies didn't have grave security failures.

http://www.theregister.co.uk/2008/05/21/massive_debian_opens...

dmayle• 14 years ago

I'm going to jump out of the woodwork to answer this one, because the solution is really obvious.

If secure boot were about securing your computer from third parties (e.g. malware, rootkits cough) installing unauthorized software, then the correct implementation would generate a private key on each machine at the time of 1st boot, used to sign all software before running. This would ensure that the only software that could run on a machine was specifically authorized by the user. In addition, there would be no worry with regards to leaked keys, because the risk of key exposure is a single machine.

Unfortunately, secure boot is not about preventing the spread of malware. It's about securing the computer from you, the owner. It's about DRM, and ensuring that the code running on a computer (e.g. Blu-Ray player) is controlled and trusted by a third-party, who is then able to dictate how certain information available to the machine is processed.

Don't let the name fool you.

gouranga• 14 years ago

Doesn't surprise me.

Certificate signing is only as good as the weakest points which are 1) humans, 2) code, 3) maths respectively.

You can't trust (1), ever.

(2) is flawed by the fact that (1) made it.

(3) is pretty good but relies on a few assumptions which we appear to arrogant enough to assume will always stand.

Microsoft Certificate used to sign "Flame"

Related Stories