Home / vulnerabilities AKLINK-SA-2008-002.txt
Posted on 02 April 2008
Source : packetstormsecurity.org Link
============================================
||| Security Advisory AKLINK-SA-2008-002 |||
============================================
HTTP over X.509 (S/MIME) - Microsoft Outlook
============================================
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-002.txt
(S/MIME signed:
https://www.cynops.de/advisories/AKLINK-SA-2008-002-signed.txt)
https://www.klink.name/security/aklink-sa-2008-002-outlook-smime.txt
Vendor: Microsoft
Product: Outlook
Type of vulnerability: design problem
Class: remote
Status: unpatched
Severity: moderate
Releases known to be affected: Outlook 2007 (12.0.4518.1014)
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, Outlook 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).
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 Outlook'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:
--
Dipl.-Math. Alexander Klink | IT-Security Engineer | a.klink@cynops.de
mobile: +49 (0)178 2121703 | Cynops GmbH | http://www.cynops.de
----------------------------+----------------------+---------------------
