

Microsoft Certificate used to sign "Flame" - alister
http://isc.sans.edu/diary.html?storyid=13366&rss

======
yskchu
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...](http://blogs.technet.com/b/msrc/archive/2012/06/03/microsoft-
releases-security-advisory-2718704.aspx)

~~~
ajross
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?

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

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

~~~
rb12345
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...](http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html)),
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...

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

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

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

~~~
Retric
I doubt there is a single large company that has not been hacked at some
point. It's just most hacks don't get reported and most reported hacks don't
make the news.

------
techinsidr
A little more detail: [http://www.securityweek.com/microsoft-unauthorized-
certifica...](http://www.securityweek.com/microsoft-unauthorized-certificate-
was-used-sign-flame-malware)

------
SlipperySlope
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
[http://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-...](http://blogs.technet.com/b/srd/archive/2012/06/03/microsoft-
certification-authority-signing-certificates-added-to-the-untrusted-
certificate-store.aspx)

~~~
SlipperySlope
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?

~~~
eli
I guess there's no way to prove that isn't deliberate, but that smells like
the rather more common failure to implement crypto systems properly.

~~~
jness
Allowing code signing with a certificate that we generate for and hand out to
enterprise customers was certainly not something we intended to do at
Microsoft. It was sloppy and a mistake on our part that we rushed to address
as soon as we discovered the issue. Honestly, I think many of us are terribly
embarrassed by this failure and a little surprised that no one (us included)
had discovered this issue years ago. :(

~~~
rdl
I agree that is by far the most likely case, but if you wanted to give the USG
a backdoor to sign code, this is also exactly how you'd do it -- as a deniable
oversight, which, when found, could be explained as a simple oversight and
rapidly corrected.

~~~
eli
Frankly, if I were going to create a deliberate backdoor I'd make it harder to
find than this. I wonder when it was first discovered.

~~~
rdl
Yeah, so would I. It also got put in one ago, which is before putting back
doors into commodity OSes was such a useful thing for national security
(probably compromising crypto systems and specific RF hardware used in air
defense, etc was the primary goal back then).

I probably wouldnt rush to fix a convenient exploit once discovered, though,
if existing USG policies could protect against it (removing most CAs, using
DOD CAs) for government operations.

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

------
zmanji
Is this more serious than the signing for stuxnet?

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

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

~~~
semenko
F-Secure claims that this /would/ allow forgery of Windows Updates (!!):
<http://www.f-secure.com/weblog/archives/00002377.html>

"...Flame has a module which appears to attempt to do a man-in-the-middle
attack on the Microsoft Update system..."

~~~
marshray
Yep. It appears that, in fact, windows update has been pwned by these certs.

More info.
[https://www.securelist.com/en/blog/208193558/Gadget_in_the_m...](https://www.securelist.com/en/blog/208193558/Gadget_in_the_middle_Flame_malware_spreading_vector_identified)

