Fake Crypto: Microsoft Outlook S/MIME Cleartext Disclosure (CVE-2017-11776)

vulnerability

We discovered a vulnerability in Outlook’s S/MIME functionality. The short version: If you used Outlook’s S/MIME encryption in the past 6 months (at least) your mails might not have been encrypted as expected. In the context of encryption this can be considered a worst-case bug.

S/MIME screen cropped - SEC Consult

This has been a rather unusual vulnerability discovery. Unlike other cases we kind of stumbled upon the first indications of this vulnerability by pure coincidence (we did not search for Outlook vulnerabilities). We knew something was seriously wrong when we noticed that the contents of S/MIME encrypted mails were shown in Outlook Web Access (OWA).

 

The Basics: S/MIME

S/MIME is an IETF standard for end-to-end encryption and signing of mails. Most popular mail clients, including Microsoft Outlook, Mozilla Thunderbird, Apple Mail, and the Mail Clients on Apple iOS and Samsung Knox devices, support S/MIME. Along with similar technologies like PGP/GPG, it is used by security/privacy conscious individuals and organizations to protect the mail communication. To use S/MIME the mail client has to be configured, this includes installing a personal certificate and exchanging certificates with communication partners.

In an environment where mail servers or network hops between sender and recipient are compromised, S/MIME will still protect the mail’s body against unauthorized access (confidentiality) and manipulation (integrity, authenticity).

 

The Vulnerability

There is a bug in Outlook that causes S/MIME encrypted mails to be send in encrypted and unencrypted form (within one single mail) to your mail server (and the recipient’s mail server and client and any intermediate mail servers). The impact is that a supposedly S/MIME encrypted mail can be read without the private keys of the recipient. This results in total loss of security properties provided by S/MIME encryption.

In the sender’s “Sent Items” folder, there is no indication of the problem whatsoever. The message is displayed in Outlook as if it was properly encrypted.

To trigger the vulnerability, no active involvement by an attacker is required. An attacker might remain completely passive.

Note: This vulnerability affects mails where Outlook is used as the sender and has no impact on incoming S/MIME encrypted mails – where Outlook acts as the recipient. This is about mail body S/MIME encryption not transport level security (TLS).

 

Affected Mails and Scope

We observed this vulnerability only triggers with mails that are formatted in “Plain Text”. Microsoft confirmed this observation.

Speaking about “Plain Text” formatting in the context of encryption might be confusing, the screenshots below will clarify it. Outlook formats mails in “Plain Text” by default when replying to “Plain Text” formatted mails.

When composing a new mail “HTML” is the default format (unless the default has been changed). We did not observe any negative impact on attachments, Microsoft shares this observation.

The scope of this vulnerability differs depending on the used transport protocol:

a) Outlook with Exchange (impact limited to first hop)

The plaintext leaks one hop only (to the sender’s MTA) and to the recipients mailbox if the recipient and sender are in the same domain. When sending mails to external recipients Exchange seems to remove the plaintext part from the message.

b) Outlook using SMTP (impact on the entire mail path)

The plaintext leaks to all mailservers along the path and the recipient.

We do not have information regarding how the vulnerability manifests in Office 365, Outlook.com, etc.

Encrypt and sign message - SEC Consult

Example walk-through: Alice and Bob

Alice replies to Bob’s mail. Note that the “Encrypt” and “Sign” S/MIME options are selected:

S/MIME plain text highlight - SEC Consult

 

If Alice would switch to the “Format Text” tab she would see that the “Plain Text” format is pre-selected because Bob’s mail was “Plain Text” formatted:

S/MIME Sent items - SEC Consult

 

When Alice checks her “Sent Items” folder to confirm that she actually encrypted the mail she just sent, the mail shows the encrypted and signed icons (no indications of any problem with S/MIME):

S/MIME no preview content encryption - SEC Consult


This is where the attacker comes in: An attacker who can access Bob’s mailbox through Outlook Web Access (OWA) can see the contents of the message in OWA’s message preview, although he/she does not have Bob’s private S/MIME key:

S/MIMIE No preview of message image - SEC Consult


Please note, this is not an OWA vulnerability – OWA should not be able to see and display the data in the first place. OWA just happens to interpret and show the unencrypted part of a mail in the message preview.

In our environment Outlook Web Access shows the first 255 characters of the mail in the preview but an attacker with access to the MTA gets to see the entire message.

For reference, below is how an S/MIME encrypted mail is supposed to look like in OWA (note the “No preview is available.” text). This is an example of an HTML formatted and S/MIME encrypted mail:

S/MIME version of plain text - SEC Consult

Bob does not use OWA – he uses IMAP to fetch mails from the server and he only gets the encrypted part of the message and can not detect the problem either. When fetching the mail via IMAP, only the encrypted part of the message is returned. When sending mails to external recipients Exchange seems to remove the plaintext part from the message:

S/MIME plain text - SEC Consult

If Alice sends another mail via SMTP, the IMAP server returns an mail that contains both the encrypted and unencrypted part of the message. Below is how an affected mail looks like when fetched via IMAP. “SECRET” is the first (and only line) in the mail’s body:

Possible Exploitation Vectors (examples)

In the case of Outlook via Exchange (a):

  • Attacker has access to the network traffic between Outlook and Exchange server and no TLS is used (or arbitrary certificates are accepted by the MUA).
    or
  • Attacker has access to the Exchange server of the sender (e.g. compromised mail server administrator).
    or
  • Attacker has access to the sender’s or recipient’s mailbox (if the recipient is on the same domain).

In the case of Outlook via SMTP (b):

  • Attacker has access to the network traffic at any point along the mails path through the network and no transport level encryption is used.
    or
  • Attacker has access to an MTA along the path.
    or
  • Attacker has access to the sender’s or recipient’s mailbox.

Affected Outlook Versions

We observed the first affected mail on May 2nd 2017.

It is also important to note that even if you or your organization is not using Outlook at all you might be affected if someone is sending you S/MIME encrypted mails using Outlook.

 

Fixed Version

The following Outlook Version fix this vulnerability (CVE-2017-11776):
Deferred Channel: Version 1705 (Build 8201.2200) – released on 2017-10-10
Monthly Channel: Version 1708 (Build 8431.2107) – released on 2017-10-10

The much harder problem is to determine the actual impact and remediate the legacy of affected mails containing confidential data.

 

Remediation of affected mails

Microsoft does not release detailed affected version information “to avoid giving clear directions that could make it easier for those interested in conducting nefarious activity.”

Unfortunately there is no easy solution to remediate the impact of this vulnerability (we are still waiting for Microsoft to release detailed information and update the blog).

In cases where mails have been send to third parties (recipient is outside of the sender’s organization) remediation is not possible by the sending party, since the sender has no authority over the recipient’s mail infrastructure.

It is the responsibility of the vendor (Microsoft) to provide guidance to remediate the risk of unintentionally unencrypted past mails.

Note: During publishing of this advisory we noticed a user called RSec (R. Schröppel) posted the same issue on the Microsoft Community Forums on June 2nd 2017.

Back