============================================ ||| Security Advisory AKLINK-SA-2008-004 ||| ============================================ HTTP over X.509 - Microsoft Office 2007 ======================================= Date released: 01.04.2008 Date reported: 18.03.2008 (a similar issue was reported on 11.01.2008) $Revision: 1.1 $ by Alexander Klink Cynops GmbH a.klink@cynops.de https://www.cynops.de/advisories/AKLINK-SA-2008-004.txt (S/MIME signed: https://www.cynops.de/advisories/AKLINK-SA-2008-004-signed.txt) https://www.klink.name/security/aklink-sa-2008-004-office2007-signatures.txt Vendor: Microsoft Product: Office 2007 Type of vulnerability: design problem Class: remote Status: unpatched Severity: moderate Releases known to be affected: 12.0.6212.1000 SP1 MSO (12.0.6213.1000) Releases known NOT to be affected: none +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Background: Microsoft Office 2007 allows a user to sign documents using 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). +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Overview: When opening a document with a digital signature, Office 2007 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 - an "opening confirmation", which is often undesired by the recipient as well (as it can be used to track who opened which document at what time). 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 document is opened. 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). Contrary to the vulnerabilities in Microsoft Outlook and Windows Live Mail, the certificate is only verified if the signature is intact. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Proof of Concept: A signed Word 2007 document that triggers an HTTP request is available at http://www.klink.name/security/HTTP_over_Office_2007_PoC.docx The document contains a link which shows the last 10 HTTP requests triggered by this document. By verifying whether you are on the list, you can verify if you are affected by this vulnerability. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Communication: 18.03.2008: As part of a communication on a similar issue in Outlook and Windows Live Mail, informed them that Office 2007 is vulnerable as well. For details on the earlier communication, see AKLINK-SA-2008-002 or AKLINK-SA-2008-003. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Solution: None so far. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Workarounds: - limit Office'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)