MSRC 271804 (Woops)
In light of MSRC 2718704, released by Microsoft in mid-June, brings to light a glaring, obvious and known problem with current SSL certificate validation and its overarching deployment and implementations across just about every enterprise in the world.
During just about every single software or service I’ve ever reviewed that uses SSL, 99% of the time I can automatically copy and paste 3 findings which I have generally been screaming into dead ears about for years.
- Lack of enterprise, software or team specific SSL certificate chain validation
- Lack of specific CNAME level SSL certificate validation
- Lack of issuer SSL certificate validation
Like I said, 99% of applications and developers trust API based certificate validation to be “good enough” and “appropriate” for their uses. The problem is that this NOT good enough in any sense of the term. To get that, though, we have to take a trip down memory lane to the historically known broken part of SSL. I’ll assume you already understand the general idea behind SSL certificates and how it works – the main unsolvable problem is the issue of certificate revocation. If a certificate is compromised, it’s a pretty damn complex process to revoke permissions on this certificate. On top of that, because of certificate chains of trust, no one seems to consider lateral certificate compromise or the amount of trust you’re ACTUALLY putting into the verification process.
Let’s take the MSRC case as an example first – then we can also walk through some other issues that make it obvious that current default SSL validation is usually woefully inadequate, when we think about most of the scenarios SSL is required.
| Certificate |
Issuer |
Thumbprint |
| Microsoft Enforced Licensing Intermediate PCA |
Microsoft Root Authority |
2a 83 e9 02 05 91 a5 5f c6 dd ad 3f b1 02 79 4c 52 b2 4e 70 |
| Microsoft Enforced Licensing Intermediate PCA |
Microsoft Root Authority |
3a 85 00 44 d8 a1 95 cd 40 1a 68 0c 01 2c b0 a3 b5 f8 dc 08 |
| Microsoft Enforced Licensing Registration Authority CA (SHA1) |
Microsoft Root Certificate Authority |
fa 66 60 a9 4a b4 5f 6a 88 c0 d7 87 4d 89 a8 63 d7 4d ee 97 |
These were both intermediate certificates – but there is a glaring problem with the way that 99% I was talking about do their default validation and, conversely, the way default validation is done in API’s. The problem here is that these certificates still existed within the root Microsoft CA chain of trust. Let’s take a step back, again, and look at how the default “standard” SSL validation occurs:
- Walk the chain of trust backwards, and determine whether I trust the issuer.
- If I do, does the CNAME match the domain name or address I am requesting?
That’s it. Most people think there is crypto black magic happening under the hood here – whenever crypto becomes involved, people tend to turn dumb and completely ignore the voodoo that is the magically secure crypto.
So, we know then – we can create a certificate for anything, and use it, as long as we can compromise a certificate that is trusted by the client or server. This is where the case of the intermediate compromised Microsoft certificates and why it’s a total pwnage comes into play.
Why? Because I don’t need to compromise the update.microsoft.com certificate itself to push updates – I just need to compromise a certificate that is trusted by Windows Update on a windows system. In the case of Windows Update, it did perform #3 mentioned at the beginning of this post – it validated that Microsoft was the root issuer of the certificate. In the case of these Intermediate certificates, this meant:
Microsoft Root CA -> Intermediate CA -> Our generated certificates
Therefore, since we owned that intermediate CA, we owned the world.
Default SSL Validation Behavior (You’re doing it wrong)
The above, checking the issuer, is not default behavior. Default behavior is ANY certificate present in the trusted store of the local Windows system (of which include a bunch of Certificate Authorities, including state-sponsored entities… guess no one noticed that). So, let us break this down to what we actually need to do to basically compromise 99% of SSL communications on a Windows network, with any Windows-based application:
- Compromise any certificate in the trusted certificate store
This, like I said, includes many small time CA shops (due to the requirements of allowing many CAs), of which some are state-sponsored, while others are of known or unknown quality. Basically it comes down to the fact that:
YOUR ENTERPRISE TRUSTS ANY ENTITY WITHIN THE TRUSTED STORE BY DEFAULT
This means that as long as I can compromise anything in there, I now totally own all SSL communications on any windows system as well as many (most?) enterprise applications. In simple terms: I own the world.
Microsoft also maintains a list of their Root CA Members. You can read details about their program and what the hell it is on their website as well. Lots of governments in there – nifty.
Anyone involved in the security industry will, par for the course, tell you we know this and this is why certificate revocation exists (although it basically sucks). However, all this security rests on two major, glaringly stupid assumptions:
- We will know a certificate is compromised
- We trust a lot of people by default
This means, inherently, you trust a lot of people – and if any of these people are compromised, I own the entire world of encrypted SSL communications.
Validation in Enterprise Software (your still doing it wrong)
Now – we have covered the area of why default SSL validation inherently sucks, and even have a wonderful example from Microsoft on why it sucks. To re-iterate – if I can compromise any trusted CA, I can now take over the world. This means I have compromised the following:
- All web-based HTTPS/SSL communications relying on domain name/CNAME validation
- All enterprise software that uses default SSL validation routines
- All PCI (credit card) related transactions and communications (SSL is required right?)
- All SSL-based internal communications between servers in a network
- All client certificate validation that uses default validators
You can see, then, that this basically means I own the internet. Now – same organizations internally will implement their own root authority for whatever reasons, creating a security model that looks something like this:
Hilariously enough, this was the case with Windows Update and the intermediate certificates – as long as it was signed by the Root Authority, no one cared WHAT issuer it had – as long as the top of the chain was Microsoft. This means that even if you check “Is my company the root?” – you trust everything further down the chain. In this specific circumstance of enterprise networks, this means that if any team, application, business unit or otherwise has their certificate compromised than the entire enterprise has now been compromised. Essentially, the broken model being used globally on the interwebs is internally repeated.
Stay tuned for Part 2, which will included guidance on how to properly check a certificate!
