============================================ ||| Security Advisory AKLINK-SA-2008-003 ||| ============================================ HTTP over X.509 (S/MIME) - Windows Live Mail ============================================ Date released: 01.04.2008 Date reported: 11.01.2008 $Revision: 1.1 $ by Alexander Klink Cynops GmbH a.klink@cynops.de https://www.cynops.de/advisories/AKLINK-SA-2008-003.txt (S/MIME signed: https://www.cynops.de/advisories/AKLINK-SA-2008-003-signed.txt) https://www.klink.name/security/aklink-sa-2008-003-live-mail-smime.txt Vendor: Microsoft Product: Windows Live Mail Type of vulnerability: design problem Class: remote Status: unpatched Severity: moderate Releases known to be affected: 2008 (Build 12.0.1606) Releases known NOT to be affected: none +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Background: S/MIME (Secure / Multipurpose Internet Mail Extensions) is a standard for public key encryption and signing of e-mail based on X.509 certificates. X.509 certificates allow a number of extension which specify URIs for additional information regarding the certificate - for example a location where to download the issuer certificate(s). For details see RFC 3851/3850. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Overview: When receiving an S/MIME-signed email, Windows Live Mail attempts to use the additional URIs contained in the certificate to download information relevant for the verification of the certificate. It will automatically send out HTTP requests to any location that is reachable from the client - which might include networks previously unreachable to an attacker. Results are unnoticed access to both external or internal webservers, which in turn could be attacked using other vectors and - in the simplest case - a "reading confirmation", which is often undesired by the recipient as well (for example if the sender is a spammer). For an overview of this class of attacks, see the »HTTP over X.509« whitepaper at https://www.cynops.de/techzone/http_over_x509.html. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Technical details: For an introduction to the technical details, please see the whitepaper. In this particular case, Microsoft Crypto API handles the authorityInfoAccess caIssuers extension. The HTTP requests are sent out as soon as the e-mail is opened in the preview pane. The Microsoft Crypto API accepts up to five CA Issuer URIs in the given certificate which may be up to 8 kibibit each (so there is enough space for a potential attack payload). Contrary to the RFC, it only accepts HTTP URIs. The Crypto API connects to arbitrary TCP ports (both privileged and unprivileged) specified in the HTTP URI. In one test, the attempt to connect to a running machine (more or less regardless whether the particular requested port is open or not) took about 3 seconds and attempting to connect to an unreachable machine took about 10-16 seconds. If this could be confirmed to be always the case (some preliminary tests indicated otherwise), this would allow one to scan for internal hosts via mail (at the great speed of two hosts per opened mail - it is not as fast as PortBunny, granted). In yet undetermined intervals, it also seems to occasionally try to get the CA issuer certificates again, leading to more HTTP requests. Also to be noted is that the certificate validation takes place even if the S/MIME signature itself is invalid - this means than a clever spammer would not even have to burn CPU cycles on creating correct signatures. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Proof of Concept: To receive such an S/MIME-signed email that triggers a HTTP request and to verify that this request reaches an outside server, send a blank email to smime-http@klink.name. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Communication: 11.01.2008, 17:20 UTC: Contacted secure@microsoft.com with information, advisory draft (in an S/MIME-encrypted mail) and an example mail. 11.01.2008, 18:30 and 18:49 UTC: The example mail triggers HTTP requests from 131.107.0.[104|75] with a user agent of "Microsoft-CryptoAPI/5.131.3790.3959". 11.01.2008, 21:54 UTC: Nate from Microsoft replies with case number (7897) and case manager (Geoff). The original mail is fullquoted in this unencrypted reply - why did I bother to install their certificate again? 14.01.2008, 17:33 UTC: The example mail triggers more HTTP requests from 131.107.0.103, this time with a user agent of "Microsoft-CryptoAPI/5.131.2600.2180". 31.01.2008/01.02.2008: The example mail regularly triggers HTTP requests from 207.46.55.29, with user agents of "Microsoft-CryptoAPI/5.131.2600.2180" "Microsoft-CryptoAPI/5.131.2600.3285", "Microsoft-CryptoAPI/5.131.2600.3297", "Microsoft-CryptoAPI/5.131.3790.1830", "Microsoft-CryptoAPI/5.131.3790.3959" and "Microsoft-CryptoAPI/6.0", 01.02.2008, 00:14 UTC: Geoff replies to let me know they are working on it (yes, I can see that :-). Dave and a few additional teams are assisting with the investigation of the issue, no requests for additional information, they will stay in contact within the next few weeks to provide me with an update. The original report is again sent along unencrypted and fullquoted. February/March 2008: The occasional Microsoft HTTP request appears in the webserver logfiles 18.03.2008: Requested update on the issue, informed them that Office 2007 is vulnerable to the same problem as well (as are signed executables, but the signature is not checked automatically) and IPSec does not seem to be vulnerable. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Solution: None so far. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Workarounds: - limit Live Mail's ability to do HTTP requests, for example by setting an invalid proxy in the internet options. If possible, filter outgoing HTTP requests with a user-agent matching "Microsoft-CryptoAPI/*" +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Why this advisory has no CVE ID: Normally, I make sure every advisory I release has a CVE ID to ensure that the issue can be identified without doubt. In the past, I have been assigned CVE IDs directly and promptly by Steve Christey of MITRE. The communication in this case went like this: 17.01.2008: contacted Steve Christey with the question on how to handle CVEs for a generic issue in an RFC that is vulnerable in a specific implementation. 01.02.2008: contact Steve again to ask for an update 01.02.2008: Steve replies saying that he must have missed the first email and says: | This can be a tough one for CVE, but if it's a fundamental design problem | in a single RFC, and *any* conformant implementation will have the issue, | then it gets a single CVE. 02.02.2008: Updated Steve with details on the vulnerability 07.02.2008: Contacted Steve again for an update 26.02.2008: Contacted Steve again with the explicit wish for CVE IDs for the issues in Outlook, Windows Live Mail and Office 2007 28.02.2008: Contacted Steve again asking for the assignment of the CVE IDs 28.02.2008: Contacted cve@mitre.org as well in case Steve is no longer the correct contact From what I read on the CVE website, it looks like Microsoft assigns the CVE IDs for their own issues themselves, but they don't talk to me very much either. I like the CVE idea and would like to use CVE IDs whenever possible, but someone would have to answer my mails for that. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Credits: - Alexander Klink, Cynops GmbH (discovery) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Thanks to: - Philipp Südmeyer for the help in trying out the first attacks using Outlook