HTTP over X.509 — a whitepaper
Abstract
This whitepaper describes a security issue inherent in RFC 3280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile). If a certain feature (the authority information access caIssuers extension) is implemented as proposed by the RFC, unauthenticated users can potentially send arbitrary HTTP requests from the machine parsing a sent certificate. The whitepaper describes the issue in depth, provides information on which applications are vulnerable and which are not and looks at potential mitigation paths.
Background
To understand the vulnerability, we first have to understand how (non-trivial) certificate chains work. In a typical setting with one root certificate authority (CA) and one intermediate CA, there are basically three different ways on how to handle the validation of the certificate path.
Different ways of handling intermediate CA certificates
|
|
|
||||||
|
|
|
The images above show the different methods that the intermediate CA certificate can be included in the certificate verification. In the first version, the intermediate CA certificate(s) are stored on the server. This has the disadvantage of having to roll out the intermediate CA certificates on the server. Alternatively, the client can also send the intermediate CA certificate, which similarly has the disadvantage of having to install it on the client (and additional overhead in the messages from client to server). The most elegant solution is to use the authority information access extension as defined in section 4.2.2.1 and specify the URI of the intermediate certificate within the end-entity certificate itself. The server then fetches the intermediate certificate from the given URI and uses it for the certificate chain validation. It can also cache the intermediate certificate, so that it does not have to fetch it again.
The issue
However, elegant does not usually mean secure. The problem in this case is that until the certificate chain is verified, the user sending the certificate is usually untrusted. This means that the specified URI has to be treated as potentially evil input from an unauthenticated user. This simple fact is missing from the »Security Considerations« section of the RFC and thus implementors have gotten it wrong.
When implemented naively, this means that an unauthenticated user can embed arbitrary URIs within a certificate and can thus force the verifier to send out arbitrary HTTP requests on its behalf — for example to networks formerly unreachable to an attacker. The response itself is not forwarded to the attacker, so he is limited to blind attacks. A specific case of this can be used to gain information about the verifier — for example whether he has opened a certain email or office document. As more than one URI can be embedded in the certificate, it would also theoretically be possible to gain information on internal networks using timing information. For this, one would create a certificate with one URI controlled by the attacker, one URI internal to the attacked, one URI controlled by the attacker and measure the timing distance between the two accesses to the attacker-controlled URIs. In practical experience, this is still theoretical, though.
Vulnerable applications
We have looked at a number of different applications that use certificates and how they deal with the authority information access extension. Currently, three vulnerable applications have been identified, Microsoft Outlook, Windows Live Mail and Microsoft Office 2007. Below you will find an abstract of the vulnerabilities, links to the corresponding advisories as well as proof of concepts.
Microsoft Outlook & Windows Live Mail
Microsoft Outlook and Windows Live Mail (the successor of Outlook Express) both support the S/MIME standard for signed and encrypted emails. When opening an S/MIME-signed email (even using just the preview pane), the applications will try to fetch the URIs specified in the certificate using the Microsoft CryptoAPI. This vulnerability could for example be used by spammers to verify email addresses and that their email has not been filtered by a spam filter on the mail server. Note that this is computationally cheap for the spammer, as the S/MIME signature does not even have to be valid. Combined with IP geolocation, the spammer could also learn where the user fetches his mail from, which could be used in targeted advertising or phishing attacks.
To verify whether you are vulnerable to this attack, send a blank email to smime-http@klink.name. You will be sent an S/MIME-signed email with a link to verify whether HTTP requests have been received.
Detailed information about the vulnerability is contained in the advisories: Microsoft Outlook, Windows Live Mail
Microsoft Office 2007
The Microsoft Office 2007 suite offers the possiblity to sign documents using X.509 certificates. Similarly to the email case, when opening a document, the application tries to verify the certificate chain. Contrary to the S/MIME case, the signature has to be correct for this to work. This vulnerability could for example be used by someone who wants to track when and by whom his document has been opened.
To verify whether you are vulnerable to this attack, you can download the PoC Word 2007 document. The document includes a link to a page that lists the last 10 HTTP requests received by the server — you are vulnerable if your IP is on this list shortly after opening the document.
Detailed information about the vulnerability can be found in the advisory.
Applications which are not vulnerable
Several other applications have been tested and have proven not to be vulnerable. This is mostly because they (or rather their respective crypto libraries) do not implement the caIssuers extension.
The following S/MIME applications are not vulnerable to this attack:
- Lotus Notes 8
- Mozilla Thunderbird (or anything based on the NSS library)
- Apple's Mail.app
- OpenSSL-based mail clients
Theoretically, IPSec gateways could be vulnerable as well, but both the IPSec implementation in Microsoft Server 2003 and on a Cisco ASA 5540 running IOS 7.2.3 have proven to be not vulnerable. Smartcard-based Windows logon has also proven not to be vulnerable to this attack.
Potentially vulnerable applications
Potentially, anything that parses certificates and implements the authority information access caIssuers extension could be vulnerable to this attack. The following instances should provide for some interesting research:
- S/MIME gateways
- EAP/TLS
- Applications which use TLS client authentication
If you want to test whether your S/MIME infrastructure is vulnerable to this issue, you can send a blank email to smime-http@klink.name. You will be sent an S/MIME-signed email with a link to verify whether HTTP requests have been received.
Mitigation
As of April 2008, no fixes for the vulnerabilities found in the Microsoft products are available. Currently, blocking the corresponding network traffic somewhere is the only option you have. The easiest fix would be to set an incorrect proxy in the internet options, but this of course breaks Internet Explorer, etc. as well. Alternatively, one could filter outgoing user agents of "Microsoft-CryptoAPI/*" on a proxy or application level gateway.
Similar attack vectors
RFC 3280 specifies some more extensions which contain URIs:
- CPS Pointer (section 4.2.1.5)
- CRL Distribution Points (section 4.2.1.14)
- Authority Information Access OCSP (section 4.2.2.1)
CRL Distribution Points and OCSP URIs are only accessed once the rest of the certificate validation succeeds, i.e. the root CA certificate has to be trusted already. This largely decreases the people who can attack you, but still leaves a hole — if you trust a business partner's CA to issue certificates correctly, do you also trust him to do arbitrary HTTP requests within your network?
Credits
The vulnerability was found by Alexander Klink of Cynops GmbH. Thanks to the following people who helped with verifying or disproving certain scenarios:
- Jaromir Likavec and Alexander Opel at Fraunhofer Institute for Computer Graphics Research IGD, for going out of their way in providing me with a Cisco and Microsoft test environment. Alexander Nouak for asking around about who was willing to help
- Philipp Südmeyer helped in trying out the first attacks using Outlook
Updates
This section lists updates to the information above which was known to us only after the initial publication of this whitepaper.
- 03.04.2008: Simon Josefsson, the maintainer of the GnuTLS project informs us that GnuTLS is not vulnerable to this problem either (as they do not implement the caIssuers extension).