what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New


Posted Apr 2, 2008
Authored by Alexander Klink | Site cynops.de

Windows Live Mail has a design flaw that allows outbound HTTP requests to be made via a simple preview of a mail that is S/MIME-signed.

tags | advisory, web
systems | windows
SHA-256 | 4d5511e520d30bf9ecbbdb40513e02a8b285c8a0a0062c017da8916a99f7afc5


Change Mirror Download
||| 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
(S/MIME signed:

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


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.


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

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.


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,
this time with a user agent of "Microsoft-CryptoAPI/5.131.2600.2180".

The example mail regularly triggers HTTP requests from,
with user agents of
"Microsoft-CryptoAPI/5.131.3790.3959" and

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

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.


None so far.


- 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.


- Alexander Klink, Cynops GmbH (discovery)

Thanks to:

- Philipp Südmeyer for the help in trying out the first attacks using

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

Login or Register to add favorites

File Archive:

March 2023

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    13 Files
  • 3
    Mar 3rd
    15 Files
  • 4
    Mar 4th
    0 Files
  • 5
    Mar 5th
    0 Files
  • 6
    Mar 6th
    16 Files
  • 7
    Mar 7th
    31 Files
  • 8
    Mar 8th
    16 Files
  • 9
    Mar 9th
    13 Files
  • 10
    Mar 10th
    9 Files
  • 11
    Mar 11th
    0 Files
  • 12
    Mar 12th
    0 Files
  • 13
    Mar 13th
    10 Files
  • 14
    Mar 14th
    6 Files
  • 15
    Mar 15th
    17 Files
  • 16
    Mar 16th
    22 Files
  • 17
    Mar 17th
    13 Files
  • 18
    Mar 18th
    0 Files
  • 19
    Mar 19th
    0 Files
  • 20
    Mar 20th
    16 Files
  • 21
    Mar 21st
    13 Files
  • 22
    Mar 22nd
    5 Files
  • 23
    Mar 23rd
    6 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    0 Files
  • 26
    Mar 26th
    0 Files
  • 27
    Mar 27th
    0 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By