Tag Archives: X509

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

Browser Revocation Behavior Needs Improvement

6 Replies

Today the best behaving client for revocation behavior is that of Windows, in the case of browsers that means IE and Chrome.

With that said it has a very fundamental problem, if it reaches a CA’s OCSP responder and it provides an authoritative “that’s not mine” (aka Unknown) clients built on this platform treat the certificate as good.

You got that right; it treats a certificate that is clearly invalid as good! This unfortunately is a common behavior that all the browsers implement today.

The other browsers are even worse, Firefox for example:

  1. Do not  maintain a cache across sessions – This is akin of your browser downloading the same image every time you opened a new browser session instead of relying on a cached copy.
  2. Does OCSP requests over POST vs. GET – This prevents OCSP responders from practically utilizing CDN technology or cost-effectively doing geographic distribution of responders
  3. Do not support OCSP stapling – IE has supported this since 2008, Firefox even paid OpenSSL to add support around the same time but they have yet to get support in themselves.

These each seem like fairly small items but when you look at all these issues as a whole they significantly contribute the reality we face today – Revocation Checking isn’t working.

There are other problems as well, for example:

In some cases browsers do support GET as a means to do a OCSP request but if they receive a “stale” or “expired” response from an intermediary cache (such as a corporate proxy server) they do not retry the request bypassing the proxy.

All browsers today do synchronous revocation checking, imagine if your browser only downloaded one image at a time in series; that’s in-essence what the browsers are doing today.

These and other client behaviors contribute to reliability and performance problems that are preventing Hard Revocation Checking from being deployed. These issues need to be addressed and the browser vendors need to start publishing metrics on what the failure rates are as well as under what conditions they fail so that any remaining issues on the responder side can be resolved.

 

OCSP Responder Performance Needs Improvement

2 Replies

Recently I set up a PingDom monitor to track the overall performance of the various OCSP responders out there, PingDom is limited to doing GETs and cannot parse the responses from the responders but it’s a fair mechanism to look at response time.

These tests run from a number of different global locations and are averaged together, the locations change but the same locations are used for each set of tests so again this seems fair.

I decided to use the Google logo as my control test, as it is about the same size as a larger OCSP response, after about a month of monitoring this is what I saw:

Test Avg. Response time
Google Logo (3972 bytes)

44 ms
GoDaddy OCSP

186 ms
GlobalSign OCSP

228 ms
Digicert OCSP

266 ms
Comodo OCSP

268 ms
TrustCenter OCSP

273 ms
TrustWave OCSP

315 ms
Startcom OCSP

364 ms
Entrust OCSP

371 ms
Geotrust OCSP

432 ms
VeriSign OCSP

510 ms
CyberTrust OCSP

604 ms
Certum OCSP

776 ms

As you can see the fastest responder is over four times slower than the Google logo, far from acceptable.

When looking at the individual responses and their responses this is what I saw:

  • Very few responders are using CDNs, AnyCast or other techniques to globally distribute responses.
  • Only a handful of responders have multiple DNS entries for failover scenarios.
  • Quite a few responders are not following the HTTP caching header requirements in RFC 5019.
  • Most responders are not sending CA signed responses which reduce the response size significantly (down to 471 bytes), in my opinion a OCSP responder should do this for all pre-produced responses.
  • Some responders are returning Unknown for out of scope responses, this really isn’t safe for unauthenticated requests as it exposes the responder to resource consumption denial of service for against the signing keys.
  • Response freshness ranges from 6 hours to 14 days, I am quite sure the six hour responses are failing for a very large % of the internet community due to time skew; 4 days appear to be optimum.

These are all fairly easy things to address and I believe it’s reasonable for responders to get down to response times that are consistent with the control test above.

How to do OCSP requests using OpenSSL and CURL

9 Replies

 

It pretty easy, the OpenSSL and CURL manuals make it fairly easy but I thought I would put it all here in a single post for you.

First in these examples I used the certificates from the http://www.globalsign.com site, I saved the www certificate to globalsignssl.crt and its issuer to globalsignssl.crt.

Next you will find a series of commands used to generate both POSTs and GETs for OCSP:

1. Create a OCSP request to work with, this also will produce a POST to the OCSP responder

openssl ocsp -noverify -no_nonce -respout ocspglobalsignca.resp -reqout ocspglobalsignca.req -issuer globalsigng2.cer -cert globalsign.com.cer -url "http://ocsp2.globalsign.com/gsextendvalg2" -header "HOST" "ocsp2.globalsign.com" -text

2. Base64 encode the DER encoded OCSP request

openssl enc -in ocspglobalsignca.req -out ocspglobalsignca.req.b64 -a

3. URL Encode the Base64 blob after removing any line breaks (see: http://meyerweb.com/eric/tools/dencoder/ for a decoder)

4. Copy the Base64 into the URL you will use in your GET

http://ocsp2.globalsign.com/gsextendvalg2/{URL encoded Base64 Here}

5. Do your GET:

curl --verbose --url http://ocsp2.globalsign.com/gsextendvalg2/MFMwUTBPME0wSzAJBgUrDgMCGgUABBSgcg6ganxiAlTyqPWd0nuk87cvpAQUsLBK%2FRx1KPgcYaoT9vrBkD1rFqMCEhEhD0Xjo%2FV7lgq3ziGoWG69rA%3D%3D

 

If you like you can also re-play the request that was generated with OpenSSL as a POST:

curl --verbose --data-binary  @ocspglobalsignca.req -H "Content-Type:application/ocsp-request" --url http://ocsp2.globalsign.com/gsextendvalg2

Hard revocation checking and why it’s not here yet.

Leave a reply

If you follow discussions around x.509 and SSL you have likely heard that “Revocation Checking is Broken”, you might even hear it will never work therefore we should start over with a technology that isn’t dependent on this concept.

There are some merits to these arguments but I don’t agree with the conclusion, I thought I would summarize what the problems are in this post.

Fundamentally the largest problem is that, as-deployed, all x.509 revocation technologies introduce a communication with a third-party (the Certificate Authority).

This isn’t necessarily a deal breaker but it does have consequences, for example in the case of SSL:

  1. It can slow down the user’s experience.
  2. It introduces a new point of failure in a transaction.

These issues can be mitigated through intelligent deployments and engineering but unfortunately this really has not happened, as a result Browsers have implemented what is called “Soft-fail revocation checking”.

With soft-fail revocation checking browsers ignore all conditions other than an authoritative “revoked” message, in the case of OCSP that means if they reach the responder and it says “I don’t know the status” or if it fails to reach the responder it assumes it is “good”.

This behavior is of course fundamentally flawed, the Browsers say they have no choice (I disagree with this conclusion but that’s a topic for another post) other than to behave this way, but why?

The rational is as follows:

  1. Revocation repositories are not reliable.
  2. Revocation repositories are slow.
  3. Revocation repositories are not always available (captive portals).
  4. Revocation messages are too large to be returned in time.
  5. There are too many revocation messages to be returned in time.

These are all legitimate concerns, ones that are unfortunately as true today as they were almost a decade ago.

They are not however insurmountable and I think it’s time we as an industry did something about it.

Using OpenSSL to create a test Qualified Subordination PKI hierarchy

1 Reply

The other day posted about “Least Privilege and Subordinate Certificate Authorities”, this post talked about how you can delegate only a limited set of rights to a subordinate CA. I thought you might find a set of configuration files and batch files I put together to test these scenarios useful, here you go.

I threw this together on a Windows machine that had the Shinning Light OpenSSL distribution on it, it has several batch files:

  • CleanPKI.bat – Remove all generated content
  • MakePKI.bat – Make a new PKI

Then there is the OpenSSL configuration files, most of this is straight forward but for the stuff that is not check out the OpenSSL documentation.

Least Privilege and Subordinate Certificate Authorities

3 Replies

One of the most fundamental design principals when designing a secure system is that of least privilege, in the case of CAs one scenario where this can be applied is the subordination of another CA.

The application of this concept in this scenario is referred to as qualified subordination,  it was first formalized in the IETF standards for X.509 in 1999 in RFC 2459 through the introduction of the Basic Constraints, (see section 4.2.1.10), Name Constraints (see section 4.2.1.11) and Policy Constraints (see section 4.2.1.11).

Unfortunately broad product support did not begin to emerge until the RFC 3280 was released in 2002.

The development and deployment of these concepts was primarily driven by the US Federal Government’s deployment of PKI as a foundational technology for their security infrastructure. One of the many benefits of the government adopting these concepts was that NIST published a robust Test Suite to validate conformance with their interpretations of RFC 3280 which included extensive coverage of Qualified Subordination.

When these concepts are used together a Root CA is able to delegate the right to issue certificates to another CA while restricting them from creating other CAs or issuing certificates for names they are not authoritative for.

The Federal Bridge made extensive use of these concepts; they were able to do so through the mandate to use software that met the published guidelines. Adoption on the Internet however took much longer given the historically slow adoption rates for browsers, that gladly has changed and there is now sufficient browser support to deploy these restrictions.

In addition Microsoft introduced another mechanism to restrict the scope in which a CA is trusted for, they did this by treating the Extended Key Usage (see section 4.2.1.13) extension as a means to delegate only certain issuance capabilities to a Certificate Authority.

It accomplishes this by using the same logic specified in RFC 3280 for Certificate Policies (see section  4.2.1.5), more specifically it assumes when an issuer lists an Extended Key Usage (such as the one for S/MIME encryption) in a CA certificate that its issuer intended to restrict the usage of that CA to the EKUs present in the certificate. A simplified version of this logic was also adopted by OpenSSL for SSL certificates.

Given the Microsoft behavior is more restrictive than the behavior specified in RFC 3280 it does not break applications that do not support it and allows a CA to restrict behavior even further for clients that use the Windows certificate validation logic (nearly 70% of the deployed browsers today).

 

Client Compatibility

Most browsers and email clients support these concepts, however unfortunately not all of them support Name Constraints.

Despite that that they all do support honoring the RFC 3280 behavior for critical extensions (see section 4.2), which states:

A certificate using system MUST reject the certificate if it encounters a critical extension it does not recognize

This means by marking the Name Constraints extension Critical those implementations that do not support the concept will “fail-closed”.  This means it can be used as an effective way to technically enforce that CAs are not trusted for names they are not authoritative for, it also means that there will be cases where they may be authoritative but clients cant trust the certificates they issue.

This issue can be addressed by not marking the extension Critical, when this is done the clients that understand Name Constraints will continue to honor the policies expressed in it and those that do not will simply ignore the extension.

This is of course a trade-off of security in exchange for compatibility, with that said one with far more positive trade-offs than negative ones.

Specifically this approach means users of clients that do not support the extension are no-worse off than they are without its use and those with support get the additional protection from cases where a subordinate CA has been compromised or is willfully issuing certificates that it is not authoritative for.

With that said, support for Name Constraints is actually quite good as the following table illustrates.

 

Honor Criticality Support Basic Constraints Supports DNS Name Constraints Supports RFC 822 Name Constraints Supports Policy Constraints Supports constrained EKU Successfully enforces
IE [1] Yes Yes Yes N/A Yes Yes Yes (Open)
Outlook [1] Yes Yes Yes Yes Yes Yes Yes (Open)
Firefox [1] Yes Yes Yes Yes Yes No Yes (Open)
Thunderbird [1] Yes Yes Yes Yes Yes Yes Yes (Open)
Opera [1] Yes Yes No[2] No[2] No[2] Yes (SSL only) [3] Yes (Closed)
Windows / Safari [1] Yes Yes Yes Yes Yes Yes Yes (Open)
OSX / Safari[4] Yes Yes No[5] No[5] No[5] No Yes (Closed)

 

What this table shows is:

  1. It is possible to rely on the Name Constraints extension as an effective enforcement technique if the extension is marked as critical.
  2. It is possible to rely on the Basic Constraints extension as an effective enforcement technique.
  3. In the case of Safari and Opera that this success is due to these browsers support of honoring the semantics for critical extensions vs. understanding the Name Constraints extension.

For customers this means if you must interoperate with Opera or Safari (yes even on iPad and iPhone) the use of a certificate with a “Critical” “Name Constraints extension” in it will result in the certificate chain looking invalid.

Thankfully according to StatCounter these represent less than 6% of all browsers on the Internet and antidotal evidence shows almost no use in the enterprise.

With that said most environments business requirements will not allow them to fail even for such a small number, in these environments deploying Name Constraints as a non-critical extension will be required, not 100% of the security benefits are realized with this approach but it does significantly reduce the risk.

In such cases it is recommended that once the remaining legacy clients that do not support Name Constraints have been replaced with more recent versions that do the CAs be re-issued with the extension marked as critical.

 

[1] Tests on Windows were completed with Windows 7, IE 9.0, Outlook 2007, Safari 5.05, Opera 11.61, Firefox/Thunderbird 10.0.2.

[2] OpenSSL supports name constraints for both name forms as well as policy constraints, Opera has chosen not to enable thee capabilities until demand was present. This work was done in OpenSSL in 2008 as part of a contract to Google.

[3] Opera uses OpenSSL which supports restricting a CA from issuing valid SSL server certificates if it’s parent did not place the SSL EKU  in it’s certificate.

[4] Tests on OSX were completed with Lion and Safari 5.05

[5] Safari on the Mac uses the PKITS tests so they are aware of the deficiency in their validation logic, they have not publically stated they will support them but we expect support in the future.

 

Server Compatibility

If you have server that accepts or validates client certificates you will also care about their support for validating certificates that have these constraints.

Each environment is a little different and the number of server choices one sees in these cases feels limitless at times, as such we are only able to provide more abstract guidance here.

In the case of Windows servers such as IIS the important factor is what version of Windows you are running on as the support for PKI is built into the Windows platform. Applications are most commonly built on this platform when they are designed for Windows and is always the case for Microsoft applications.

The concepts discussed here were all supported since Windows 2003, though there were significant improvements in the 2008 release.

The net of the above is that if your server platform is built on this API you gain support for these concepts, on other platforms it of course depends on which libraries they chose to use for support for certificate validation.