How one typically verifies code comes from Microsoft

1 Reply

Microsoft signs all code that ships from it (that is except for the case when it doesn’t); so how does one verify that the code came from them vs. anyone with a fraudulent certificate claiming to be them?

Well the answer is pinning, but the pinning for the most part does not happen at the signing certificate level as those keys change to frequently to be pinned. The pinning happens at the certificate issuer level, much like has been proposed by CAA.

So to understand how this happens in code you need to understand code signing in Windows a little. There are two types of signatures those that are “embedded” and those that are “attached”.

Authenticode would be an example of an embedded signature; Catalog Files on the other hand are detached signatures. There are other examples of both of these but in general these other formats have the same abstract properties.

So when do you use one vs. the other? Well if a user will download your binary directly (ActiveX, Setup, etc.) you would typically embed a signature.

If that’s not the case you would use a detached signature because a single signature can be placed on a list of binaries without increasing the package size (it’s one signature on n hashes). You produce these signatures with SignerSignEx.

For the two signature formats I mentioned you do your signature verifications using an API called WinVerifyTrust. You can also use this API to get information out of a signature (who signed it, when, etc.).

With that information you do a certificate validation that is accomplished with the CertGetCertificateChain API, that gives you a CERT_CHAIN_CONTEXT which you can use to call CertVerifyCertificateChainPolicy.

This API is used to do application specific verifications, for example in the case of TLS the CERT_CHAIN_POLICY_SSL provider is used – this is where the name and EKU verification logic for Windows exists.

The providers we care about for our story today are:

  • CERT_CHAIN_POLICY_AUTHENTICODE – Is this certificate appropriate for code-signing?
  • CERT_CHAIN_POLICY_AUTHENTICODE_TS – Is this certificate appropriate for time stamping code?
  • CERT_CHAIN_POLICY_MICROSOFT_ROOT – Is this certificate ultimately issued by a Microsoft Product Root?

The last one is the one in has an array of hashes in it, I don’t recall if they are key hashes or thumbprints of the certificate. In essence what it does is look at the top of the chain to see if the Root matches one of these hashes if it does it passes, if it doesn’t it fails.

Applications may choose to do additional “pinning” also, for example in the case of Windows Update Services a manifest is exchanged between the client and server, that manifest comes down over SSL they may choose to also do pinning to a set of certificates for the SSL session or apply digital signatures to the manifest and do pinning for the keys that are used to do signing.

I do not know personally for a fact that any such pinning takes place but I have been told by several people I respect that it does.

It looks as if Windows Update was not doing pinning but as of this week it will, this is of course  a best practice and I am glad to see them doing it now.

So now you know how to validate that code is coming from Microsoft, or at least how it’s supposed to work.

Issues like represented in MSRC 2718704 / Flame put some of these assumptions in question, it’s clear that pinning is an important concept though and one that should be supported more broadly.

Ryan

The tale of two (Microsoft) PKIs

Leave a reply

As you know I used to work at Microsoft on areas surrounding cryptography, certificates, protocols and other such things.

While I can’t talk about the internal workings of things I can explain the high level roles the two sets of PKIs Microsoft maintains.

The first PKI is the Microsoft “Product Roots”; these are the keys and certificates that are managed with the sole purpose of being used for product scenarios. You can see the names and serial numbers of these CAs here.

The next is the “IT Root”, that is the one folks see associated with a S/MIME email from a Microsoft employee, some of the corporate websites have SSL certificates from this hierarchy and if you were to inspect the badges of an employee you would see a certificate from here that is used for smart card login and other related scenarios.

The “Product Roots” are trusted only by Windows and applications that have either built on the Windows CryptoAPI or simply imported the roots from the Microsoft Root Program.

The “IT Root” is trusted by third-party browsers because it has been cross signed with a public CA, currently that CA is Verizon the certificate is labeled “GTE CyberTrust”.

I hope that helps clarify for people,

Ryan

MSRC 2718704 and the age of the rogue certificates

Leave a reply

One of the things I love about security is how security researchers are so passionate about their jobs; they for the most part respect their peers and enjoy learning about attacks so they are willing to share information.

As a result of this dynamic over the past few days I have had a chance to look at a number of details about the #Flame malware as well as the rogue certificates it used as part of the its Windows Update attack.

With that said the raw data having already been published here quite a long time ago I think it’s OK to go into details on this now (Another interesting data point is that this link is discussing how to bypass the Terminal Services license mechanism).

This certificate chain gives us some insights into the age of the solution Microsoft was using to license Terminal Server Clients, for example one certificate chain I received shows us the following:

   
   
   
   
 

 

From this we can tell a few things, including:

  1. The licensing solution has been in use since at least 1999 – Its issuance date is ‎Thursday, ‎April ‎15, ‎1999 12:00:00 AM, we can assume this is the case if we assume the “Microsoft Enforced Licensing Intermediate PCA” is in a Microsoft vault (very safe to assume).
  2. The “Licensing Server” was built to include unverified information in each license originally – We can assume this since the other certificates we saw included no organization details in the subject name while this one has a DN of  “CN = Terminal Services LS, L = Stradella, S = PVC =  IT, E = ater**@libero.it”
  3. The PKI was rebuilt in around 2004 – In the first certificates we saw the Microsoft operated CA that issued the “licensing server” (Microsoft Enforced Licensing Registration Authority CA) expired in 2009, in the most recent certificate the chain is a one leaf shorter but same logical entity expires in ‎2004.
  4. The format of the certificates changed around 2004 – In the first certificates we saw only a single proprietary extension, in this one we see four. This suggests that there was a code change in how licenses were validated around this time. This also approximately aligns with when one might expect the Windows Server development to begin for the next version (at the time development cycles were 3-4 years).
  5. Attackers were using this in combination with other attacks even then – In 2003 there was a security defect in the way Windows handled Basic Constraints (see MS 02-050). This allowed certificates that were not CAs to be trusted to issue CA certificates.

In this most recent certificate chain we can see that a Terminal Services LS (a license) has issued another certificate, the validity of this certificate was based on a combination of two factors:

    • The root CA being trusted by the entity validating the certificate.
    • The license certificate being able to issue other certificates.

This combination allowed the attacker to simply have access to a CAL, not even the License Server and produce a certificate that could be used to attack another system – I will do a post about this later.

  1. Terminal Services doesn’t do full certificate validation on its licenses – The post I got this certificate from states it works on machines as recent as 2008 but the “Terminal Services LS” expires in in 2004, the certificate that was minted bellow it (the evil “PORTATILE” one) is good until 2038. This would not pass the CryptoAPI certificate validation logic on those platforms due to the BasicConstraints restrictions on the certificate and the date issues alone.

So in summary, this issue has been around a very long time, much longer than Flame or Stuxnet. There are a few very interesting conclusions I come to as I write this:

  1. Even without the Basic Constraints issue no collision attack would have been needed to make use of this original Licensing PKI .
  2. Despite the changes in the client behavior in Windows Vista in how Critical Extensions are handled, the weak cryptography made it practical to continue to use this PKI maliciously.
  3. Those who knew about this tried to keep it a secret as long as possible as it was very valuable.
  4. Despite developing a world-class security program over the last decade this issue managed to fly under the radar until now.

MSRC 2718704 and Terminal Services License Certificates

1 Reply

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.

 

MSRC 2718704 and Nested EKU enforcement

Leave a reply

There are a number of technical constraints a Certificate Authority can put into place on a subordinate Certificate Authority; the general concept is referred to as Qualified Subordination.

One of the most important ways to constrain a certificate is through by restricting what it can be good for.

The foundation for such a constraint is provided by PKIX in the Extended Key Usage extension (RFC 5280), this extension can be put into a certificate to restrict what it is trusted for – for example a certificate might be OK for SSL Server Authentication but not for S/MIME.

The problem is the RFC provides no practical guidance on how to act when this certificate is encountered in a CA certificate, all it says is:

In general, this extension will appear only in end entity certificates.

One can interpret this to mean that its semantics are the same in issuer or subscriber certificates, this makes sense but isn’t very useful as a CA is not very likely to ever perform “application tasks” like S/MIME or SSL Server authentication with its signing key, so why would you put it in a CA certificate?

Also if you look back at the history this extension was really one of the first that was introduced, it came into existence in a time where PKIs were only one level deep – the absence of guidance on how to handle this could easily be seen as an omission.

Microsoft saw it this way and decided to have their implementation treat this extension as a constraint, in other words if no EKU is present in the chain then the chain is considered good for all usages. But once a single EKU is added into the path nothing bellow it can be considered good for a non-listed EKU.

In Windows applications validate certificates using the CertGetCertificateChain API takes a number of control parameters via the PCERT_CHAIN_PARA structure, one can specify what EKUs they want to make sure a certificate is good for via the RequestedUsage parameter.

This logic (frankly almost all of the certificate validation) is all wrapped into this one call.

So what does this have to do with MSRC 2718704? Well it has reduced the risk of this mess up in a meaningful way I thought I would explain but before I do let me explain that I am not trying to downplay the significance of this issue I am just trying to clarify where the risks are.

As we know now the “licensing solution” deployed for terminal services has put a signing CA that is trusted for Code Signing in ever enterprise that uses the product.   But how is it restricted to just Code Signing, that’s really what this post is about.

Let’s look at the EKUs included in the offending “MS” certificate, in that chain we see:

  • Microsoft Root Authority
    • No EKUs
  • Microsoft Enforced Licensing Intermediate PCA
    • EKUs = Code Signing, Key Pack Licenses, License Server Verification
    • Effective EKUs = Code Signing, Key Pack Licenses, License Server Verification
  • Microsoft Enforced Licensing Certificate Authority CA
    • EKUs = Code Signing, License Server Verification
    • Effective EKUs = Code Signing, License Server Verification
  • Microsoft LSRA PA
    • EKUs = None
    • Effective EKUs = Code Signing, License Server Verification
  • MS
    • EKUs = None
    • Effective EKUs = Code Signing, License Server Verification

You will notice that the “Microsoft LSRA PA” certificate lists no EKUs but the Effective EKUs are listed as “Code Signing” and “License Server Verification”, this is because of the Nested EKU behavior I describe above.

The same thing happens in the end “MS” certificate; even though it has no EKUs listed I can only be used to validate licenses and sign-code because that’s all it’s issuers are entitled to bestow onto its subordinates.

OK so what does all of this mean to you and me? It basically means as long as the application is written using CryptoAPI in the intended way (and all do that I am aware of in this context) those CAs out there cannot be used to issue SSL certificates (or any other usages not listed) that would be “valid”, they can of course sign code as Microsoft which is a larger issue in my book.

Anyway over the years I have proposed in IETF that this same behavior be adopted, it was always rejected as an evil Microsoft conspiracy (I was at Microsoft at the time) it of course was nothing of the sort but in the end I gave up. Recently I have started trying to convince the browsers directly to implement this same behavior as I feel it is beneficial, for example here is a NSS bug tracking the same request, if implemented that would take care of Chrome and Firefox, that still leaves Safari and Opera but it’s a step in the right direction.

 

Additional Resources

http://lists.randombit.net/pipermail/cryptography/2012-June/002966.html

MSRC 2718704 and the Terminal Services Licensing Protocol

3 Replies

There has been a ton of chatter on the internet the last few days about this MSRC incident; it is an example of so many things gone wrong it’s just not funny anymore.

In this post I wanted to document the aspects of this issue as it relates to the Terminal Services Licensing protocol.

Let’s start with the background story; Microsoft introduced a licensing mechanism for Terminal Services that they used to enforce their Client Access Licenses (CAL) for the product. The protocol used in this mechanism is defined in [MS-RDPELE].

A quick review of this document shows the model goes something like this:

  1. Microsoft operates a X.509 Certificate Authority (CA).
  2. Enterprise customers who use Terminal Services also operate a CA; the terminal services team however calls it a “License server”.
  3. Every Enterprise “License server” is made a subordinate of the Microsoft Issuing CA.
  4. The license server issues “Client Access Licenses (CALs)” or aka X.509 certificates.

By itself this isn’t actually a bad design, short(ish) lived certificates are used so the enterprise has to stay current on its licenses, it uses a bunch of existing technology so that it can be quickly developed and its performance characteristics are known.

The devil however is in the details; let’s list a few of those details:

  1. The Issuing CA is made a subordinate of one of the “Microsoft Root CAs”.
  2. The Policy  CA  (“Microsoft Enforced Licensing Intermediate PCA”) on the Microsoft side was issued “Dec 10 01:55:35 2009 GMT”
  3. All of the certificates in the chain were signed using RSAwithMD5.
  4. The CAs were likely a standard Microsoft Certificate Authority (The certificate was issued with a Template Name of “SubCA”)
  5. The CAs were not using random serial numbers (its serial number of one was 7038)
  6. The certificates the license server issued were good for :
    • License Server Verification (1.3.6.1.4.1.311.10.6.2)
    • Key Pack Licenses (1.3.6.1.4.1.311.10.6.1)
    • Code Signing (1.3.6.1.5.5.7.3.3)
  7. There were no name constraints in the “License server” certificate restricting the names that it could make assertions about.
  8. The URLs referred to in the certificates were invalid (URLs to CRLs and issuer certificates) and may have been for a long time (looks like they may not have been published since 2009).

OK, let’s explore #1 for a moment; they needed a Root CA they controlled to ensure they could prevent people from minting their own licenses. They probably decided to re-use the product Root Certificate Authority so that they could re-use the CertVerifiyCertificateChainPolicy and its CERT_CHAIN_POLICY_MICROSOFT_ROOT policy. No one likes maintaining an array of hashes that you have to keep up to date on all the machines doing the verification. This decision also meant that they could have those who operated the existing CAs manage this new one for them.

This is was also the largest mistake they made, the decision to operationally have this CA chained under the production product roots made this system an attack vector for the bad guys. It made it more valuable than any third-party CA.

They made this problem worse by having every license server be a subordinate of this CA; these license servers were storing their keys in software. The only thing protecting them is DPAPI and that’s not much protection.

They made the problem even worse by making each of those CAs capable of issuing code signing certificates.

That’s right, every single enterprise user of Microsoft Terminal Services on the planet had a CA key and certificate that could issue as many code signing certificates they wanted and for any name they wanted – yes even the Microsoft name!

It doesn’t end there though, the certificates were signed using RSAwithMD5 the problem is that MD5 has been known to be susceptible to collision attacks for a long time and they were found to be practical by December 2008 – before the CA was made.

Also these certificates were likely issued using the Microsoft Server 2003 Certificate Authority (remember this was 2009) as I believe that the Server 2008 CA used random serial numbers by default (I am not positive though – it’s been a while).

It also seems based on the file names in the certificates AIAs that the CRLs had not been updated since the CA went live and maybe were never even published, this signals that this was not being managed at all since then.

Then there is the fact that even though Name Constraints was both supported by the Windows platform at the time this solution was created they chose not to include them in these certificates – doing so would have further restricted the value to the attacker.

And finally there is the fact that MD5 has been prohibited from use in Root Programs for some time, the Microsoft Root Program required third-party CAs to not to have valid certificates that used MD5 after January 15, 2009. The CA/Browser Forum has been a bit more lenient in the Baseline Requirements by allowing their use until December 2010. Now it’s fair to say the Microsoft Roots are not “members” of the root program but one would think they would have met the same requirements.

So how did all of this happen, I don’t know honestly.

The Security Development Lifecycle (SDL) used at Microsoft was in full force in 2008 when this appears to have been put together; it should have been caught via that process, it should have been caught by a number of other checks and balances also.

It wasn’t though and here we are.

P.S. Thanks to Brad Hill, Marsh Ray and Nico Williams for chatting about this today 🙂

Additional Resources

Microsoft Update and The Nightmare Scenario

Microsoft Certificate Was Used to Sign “Flame” Malware

How old is Flame

Security Advisory 2718704: Update to Phased Mitigation Strategy

Getting beyond 1% — How do we increase the use of SSL?

2 Replies

Today about 1% of the traffic on the Internet is protected with SSL (according to Sandyvine), there are a few key issues keeping this number so small and I thought I would put together a quick post on what I think those issues are.

 

Interoperability

For over a decade we have been working towards migrating to IPv6, despite that we have made little progress, in-fact they say that at the end of 2012 we will run out of IPv4 addresses.

As far as I know not one of the top 10 CAs support IPv6 yet (yes, not even GlobalSign though were working on it). This means it is impossible to host a pure IPv6 SSL solution today (because of the need for revocation data).

This is also interesting because today many sites are hosted on virutal hosting solutions that share the same IP address — this is primarily because IP addresses are a scarce resource, it has the side effect of making it hard (sometimes impossible) to deploy SSL on these hosts.

In 2003 an extension to TLS was proposed to address this problem it’s called Server Name Indication (SNI – now defined RFC 6066).

Today the server support for this extension is quite good but the same can not be said for client support (due to the lingering XP population and influx of mobile devices).

In my opinion this is the #1 issuing holding back the adoption of SSL everywhere.

 

Complexity

It is amazing to me but very little has changed in the CA industry since it’s birth in the mid 90s, certificates are still requested and managed in essentially the same way – it’s a shame, it’s wasteful.

One of the reasons I joined GlobalSign is they have been trying to address this issue by investing in both clients and APIs (check out OneClick SSL and CloudSSL) — with that said that there is still a lot more that can be done in this area.

Then there is the problem of managing and deploying SSL, the SSL Pulse data shows us it’s hard to get SSL configured right; we are getting better tools for this but again there is still a ton of room for improvement.

 

Performance

There has been a bunch of work done in this area over the years; the “solutions” relating to  performance of SSL seem to be broken up into:

  1. Protocol improvements (SPDY, FalseStart, OCSP Stapling, etc.)
  2. Using different cryptography to make it faster (Smaller keys, DSA, ECDSA, etc.)
  3. Using accelerator products (F5 BigIP, NetScaller, SSL Accelerators, etc.)

I won’t spend much time on protocol improvements as I think it gets a ton of coverage from the likes of Google who have made several proposals in this area over the last few years. I do have concerns with these protocol changes introducing interoperability issues, but I can’t argue with the performance benefits they offer.

You will notice I also included OCSP Stapling in this group, I think this is a great way to improve revocation checking but it’s not about security, it’s about performance and reliability – you should just use this today, it’s safe and very likely supported by your servers already.

The use of different cryptography is an interesting one, however again the issue of compatibility rears its ugly head. Though every implementation of an algorithm will perform differently the Crypto++ benchmarks are a nice way to get high level understanding of an algorithms performance characteristics.

There is a lot of data in there, not all of it related to SSL but one thing definitely is the performance characteristics of RSA vs DSA:

Operation Milliseconds/Operation Megacycles/Operation
RSA 1024 Signature 1.48 2.71
RSA 1024 Verification 0.07 0.13
DSA 1024 Signature 0.45 0.83
DSA 1024 Verification 0.52 0.94

 

You will notice that with RSA it is more expensive to sign than it is to verify, you will also notice that with DSA the opposite is true (it is also faster in this sampling).

Since in the case of SSL it is the server doing the signature and the client doing the verify this is an important fact, it means a server using a DSA certificate will spend less time doing crypto and more time doing other stuff like serving content.

On the surface this sounds great, there are of course problems with this though – for one because of the work researchers have done to “break” RSA over the last few years the browsers are moving CAs to not issue 1024bit RSA keys (by 2013) an effort which CAs have also applied to DSA.

Another not-so trivial factor is that Microsoft only supports DSA keys up to 1024 bits in length which means the larger DSA keys are not viable on these platforms.

So what of the new ciphers like AES and ECDH-ECDSA? This will represent a very large performance boon for web server operators but they too like SNI are not supported by legacy browsers.

What this means for you is for the next few years we have to make do with the “legacy cipher suites” as a means to facilitate TLS sessions.

Miscellaneous

Not everything fits neatly into the above taxonomy, here are a few common topics that don’t:

  1. Increased cost of operation
  2. Inability to do “legitimate” packet inspection

Increased cost of operation can be summerized needing more servers for the same load due to the increased SSL computational costs.

Inability to do “legitimate” packet inspection can be summarized as limiting he practical value of existing security investments of technologies like Intrusion Detection and Network Optimization since once the traffic is encrypted they become totally innefective. To work around this issue networks need to be designed with encryption and these technologies in mind.

 

Summary

I personally think the biggest barriers is ineroperability, the biggest part of this being the lingering XPs installations; the silver lining being the last few years XP has lost market share at about 10% per year, at the current rate we are about three years from these issues being “resolved”.

In the mean time there is a lot the industry can do on the topic of complexity, I will write more on this topic another time.

Always On SSL (AOSSL) Whitepaper Published

Leave a reply

Did you know about 1% of the traffic on the internet is protected with SSL (see the Sandyvine Report)?

Or than many of the sites responsible for this traffic do not require SSL, they instead just make it available as an option?

This unfortunately this means users are exposed to risks that are otherwise would not be present.

There is a trend to move to protecting all site content with SSL, this effort has been dubbed Always On SSL; the OTA has just recently published a whitepaper on this topic that I had a chance to contribute to.