Email Security

Bug Caused Microsoft Outlook to Send Emails in Cleartext

A vulnerability that that was recently addressed by Microsoft as part of the October 2017 Patch Tuesday could result in Outlook sending emails in cleartext when S/MIME encryption was supposed to be used.

<p class="MsoNormal"><span><span><strong>A vulnerability that that was recently addressed by Microsoft as part of <a href="http://www.securityweek.com/microsoft-patches-office-zero-day-used-deliver-malware">the October 2017 Patch Tuesday</a> could result in Outlook sending emails in cleartext when S/MIME encryption was supposed to be used.</strong></span></span></p>

A vulnerability that that was recently addressed by Microsoft as part of the October 2017 Patch Tuesday could result in Outlook sending emails in cleartext when S/MIME encryption was supposed to be used.

Discovered by SEC Consult researchers, the bug impacted Outlook’s S/MIME functionality and was supposedly introduced about six months ago. Both Microsoft Outlook 2016 32-bit and 64-bit editions are affected.

The S/MIME standard is used for end-to-end encryption and for the signing of emails, and is supported by most popular mail clients, including Microsoft Outlook, Mozilla Thunderbird, Apple Mail, and mail clients for mobile devices. However, mail clients need to be configured to use S/MIME through installing a personal certificate and exchanging certificates with communication partners.

Even the United States Department of Defense uses S/MIME, but there isn’t much information available on other organizations that use the standard, SEC Consult says.

Tracked as CVE-2017-11776, the Outlook flaw resulted in emails not being encrypted as expected when S/MIME encryption was in use. Because of this issue, the contents of S/MIME encrypted mails would show in Outlook Web Access (OWA), which led to the vulnerability’s discovery, the researchers say.

No action is required from an attacker looking to trigger 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,” SEC Consult explains.

The vulnerability is difficult to spot by the sender, as there is no indication of it in the “Sent Items” folder. In fact, Outlook would display the message as if it was properly encrypted, the researchers explain.

Advertisement. Scroll to continue reading.

Because the vulnerability impacts the mail body S/MIME encryption and not transport level security (TLS), only emails sent from Outlook are impacted. The issue has no effect on incoming S/MIME encrypted mails, where Outlook acts as the recipient.

The security researchers also explain that only messages sent in “Plain Text” format are affected by the vulnerability. What should be noted, however, is that Outlook formats mails in “Plain Text” by default when replying to “Plain Text” formatted emails.

According to SEC Consult, most security conscious organizations only use “Plain Text” formatted emails, and even DoD recommends the exclusive use of “Plain Text” formatted emails (PDF).

Depending on the used transport protocol, the scope of the vulnerability differs. In Outlook with Exchange, plaintext leaks one hop only if the recipient and sender are in the same domain. In Outlook using SMTP, the plaintext leaks to all mail servers along the path and the recipient.

The vulnerability was addressed in both Microsoft Outlook 2016 editions on October 10, 2017, as part of Microsoft’s regular set of monthly patches.

“The much harder problem is to determine the actual impact and remediate the legacy of affected mails containing confidential data,” SEC Consult notes.

Related: Microsoft Patches Office Zero-Day Used to Deliver Malware

Related: Hackers Can Execute Code on Windows via DNS Responses

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version