When looking at the certificates the Flame authors used to sign the malware in their Windows Update module one has to wonder what was different between a normal terminal services license certificate and the one they used.

Well getting at one of these certificates is a little awkward as they are kept in the registry vs. in the traditional certificate stores, thank goodness with a little due diligence you can find one.

So from this what can we learn? There are a few things:

1. Every subordinate CA has the same name “Microsoft LSRA PA”
2. Every terminal services license has the same name “Terminal Services LS”
3. The license appears to have a random serial number (even the CA certs did not!)
4. The license has a 512bit RSA key.
5. The license is signed with MD5.
6. No restrictions have been explicitly placed on this certificate.
7. This license is good for 257 days.
8. The CRL url is invalid.
9. The Certificate Issuer url is invalid.
10. It contains a proprietary extension (1.3.6.1.311.18)

As far as best practices go there are clearly a lot of problems here:

1. Same name for every CA – the point of a CA is to identify an entity, if every CA has the same name this can’t really happen.
2. Same name for every subject – while the certificates here are for authenticating entitlement to make a connection and not to authenticate an identity the subject should still be unique.
3. Over entitled– The certificate contains no Extended Key Usage or other restrictions, as a result this certificate is only as restricted as its issuers issuer is, namely it is good for:
   • Code Signing (1.3.6.1.5.5.7.3.3)
   • License Server Verification (1.3.6.1.4.1.311.10.6.2)
4. Weak keys – RSA 512 bit was factored in 1999, there should be no CA issuing 512 bit keys period especially in a PKI as powerful as this, especially for one that is good for code signing.
5. Weak hash algorithm – MD5 has been known to be weak since 1993 and has had increasingly effective attacks published against it ever since — There should be no CA issuing MD5 signed certificates in 2012.
6. Invalid URLs – This indicates that the CA was not actively managed, it also included internal only file references in the certificate also a no-no and a indicator of the same.
7. Poorly thought out proprietary extension – The extension is not well thought out, the OID (1.3.6.1.311.18) is an arc for Hydra (Terminal Services) and not a unique identifier (or shouldn’t be at least) for a specific extension. This isn’t harmful but a signal the design didn’t go through much review.

The other items are odd, like the 257 day validity window and the proprietary extension but they are not problematic – at least on the surface.

Well that’s what we know so far.