Office 365 leaks BCC domains

Microsoft hosted Exchange, part of the Microsoft Office 365 suite, is found to leak the domain name of bcc addresses to all recipients. This leak may cause unintended disclosure of recipients of an email message.

Mailhardener was able to reproduce and confirm the leak. In this article we'll perform an in-depth analysis.

The leak

On May 3rd 2021, a report was published on Reddit by user 'botje_nl' claiming to have discovered a data leak in Microsoft's Office 365 products where under specific circumstances the domain of a Bcc receiver may be leaked to all recipients of the email.

In the Reddit thread, it is reported that Microsoft Exchange adds the Authentication-Results header to all outgoing email messages sent with Office 365. In this Authentication-Results header, the domain name of the first receiver's email address is disclosed. In email messages where no to or cc address is used, this results in the domain name of a bcc address to be disclosed unintentionally in the header.

Mailhardener was able to reproduce, and confirm the reported behavior within a hosted Exchange instance.

For email messages that exclusively use bcc recipients (where the to and cc addresses are left empty) this results in unintended disclosure of the bcc domain name to all recipients.

For example:

From: info@mydomain.com
To: [empty]
Cc: [empty]
Bcc: someone@amnesty.com, reporter@newyorktimes.com
Subject: Some information you'd be interested in...

As shown in the report, the following Authentication-Results header is then added to the outbound email, exposing the Bcc domain (amnesty.com):

authentication-results: amnesty.com; dkim=none (message not signed)
header.d=none;amnesty.com; dmarc=none action=none header.from=mydomain.com;

If we analyze the header in the example above, we see that the bcc domain (amnesty.com in the example) actually occurs twice in the header.

• As the authenticator identification (known as the 'authserv-id' value), this is the first value after the authentication-results header name.
• In the header.d value. Though the value is malformed as none;amnesty.com.

The result is that the receiver at reporter@newyorktimes.com can see that a copy of this email was also sent to an amnesty.com address.

The leak appears to only happen in hosted Exchange services (part of the Office 365 suite), Microsoft's other hosted email service live.com and hotmail.com appear unaffected.

Analyzing this issue

At Mailhardener we were successful in reproducing the behavior as reported on the original Reddit thread.

This header in question is not supposed to be added to outbound email by Exchange, nor is it supposed to contain any information on the receivers (whether it is to, cc or bcc).

In total, we were able to identify four distinct issues:

1. The Authentication-Results header is normally added by the receiving SMTP service on inbound email. It isn't supposed to be added by the sending system to outbound email.
2. The Authentication-Results header reports the authentication results on the sender (from) address, the receivers addresses (whether it is to, cc or bcc) are not supposed to be used in the Authentication-Results header.
3. The Authentication-Results header (optionally) identifies which party performed the authentication, known as the authserv-id. This should be the name of the email service that added the header. Exchange adds the domain of the Bcc receiver here, which is also incorrect.
4. The Authentication-Results header is malformed, the header.d=none;amnesty.com will cause parsing issues.

Though these are 4 separate issues, they are probably all due to the same bug, that is that the software routine that creates the header is erroneously called on outbound email.

The Authentication-Results header is defined in RFC7601. The RFC uses the term 'producer' for the service that adds the header to the email.

Simply put, a transfer from the producer of the header field to the
consumer must occur within a context that permits the consumer to
treat assertions by the producer as being reliable and accurate
(trustworthy).  How this trust is obtained is outside the scope of
this document.  It is entirely a local matter.

The sender cannot be considered 'trustworthy', as the whole point of the header is to verify the authenticity of the sender.

Exchange is adding Authentication-Results to outbound email, which should be considered a bug.

The domain that is used in the header (amnesty.com in the example above) is known as the authserv-id value in the RFC.

Every Authentication-Results header field has an authentication
service identifier field (authserv-id above).  Specifically, this is
any string intended to identify the authentication service within the
ADMD that conducted authentication checks on the message.  This
identifier is intended to be machine-readable and not necessarily
meaningful to users.

The authserv-id should contain the name of the service that performs the authentication within the Administrative Management Domain (ADMD). As seen in the example above, Exchange uses the (bcc) domain name as authserv-id, which is incorrect. With correct usage, the receiver should have added the header, and should have used their own identity (for example mx.google.com for G-suite users) as the authserv-id.

Microsoft's response

According to the original reporter 'botje_nl' on the Reddit forums, Microsoft responded with the following statement:

Thank you for reporting this issue to the Microsoft Security Response Center (MSRC).
Unfortunately we were unable to reproduce your findings following the steps outlined in your report.
As such, this email thread has been closed and will no longer be monitored.

Source

Mailhardener has since re-issued a disclosure to Microsoft, we have yet to receive a response.

Workaround

The following workaround is proposed by the reporter:

As an admin, you should add the following rule to remove such headers on outbound e-mail:
1. Open Exchange Admin Center
2. Go to mail flow, rules
3. Add new rule:
    Apply to all messages
    Remove header: Authentication-Results.

When applied to the outbound email this rule should not affect email functionality, as the Authentication-Results is not supposed to be added to outbound email anyway.

Conclusion

At Mailhardener we have been able to reproduce this bug, and we can confirm that cloud-hosted variant of Microsoft Exchange (part of the Office 365 suite) does indeed leak the domain name of a bcc address when no other addresses (to, cc) are used. This can result in unintended disclosure of recipients.

Microsoft's hosted Exchange service seems to suffer from 4 separate bugs in production:

• The Authentication-Results header is erroneously added to outbound email, where it should be added by receivers on inbound email.
• The receiver domain is erroneously used in the Authentication-Results header, where it is intended to verify the authentication of the sending party.
• The receiver domain is also erroneously used as the 'Authserv-ID' value in the Authentication-Results header, where this should be the identifier of the party that added the header.
• The Authentication-Results header that is (erroneously) added to outbound email is malformed and likely rejected by any receiver.

Mailhardener advises users of Microsoft hosted Exchange (part of the Office 365 suite) to use bcc recipients with caution until Microsoft addresses this issue. If true separation of receivers of an email is desired, consider sending the messages separately with one recipient each.