HTTP over X.509 - Office 2007

[Alexander Klink <a.klink () cynops de>]

============================================
||| 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)

--
Dipl.-Math. Alexander Klink | IT-Security Engineer |    a.klink () cynops de
mobile: +49 (0)178 2121703 |          Cynops GmbH | http://www.cynops.de
----------------------------+----------------------+---------------------
     HRB 7833, Amtsgericht | USt-Id: DE 213094986 |     Geschäftsführer:
    Bad Homburg v. d. Höhe |                      |      Martin Bartosch

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/