Researchers Worry About Office 365 Message Encryption

But Practical Considerations Make Potential OME Weakness Not Worth Worrying About

I don’t quite know what to make of the October 14 WithSecure Labs report that Office 365 Message Encryption (OME) uses “a Broken or Risky Cryptographic Algorithm.” I also don’t know why Microsoft continues to use Electronic Codebook (ECB) to cipher message content.

OME, or rather “Microsoft Purview Message Encryption” is included in Office 365 E3 and E5 and other Microsoft 365 plans. An advanced form of OME is also available, but its functionality is not pertinent to this discussion. OME allows Exchange Online users to send encrypted email to literally any other email recipient, no matter what server their mailbox connects to. OME is built on top of Azure Rights Management, so users can protect messages with the default Do Not Forward and Encrypt-Only templates, or they can use custom rights management templates published to Outlook email clients as sensitivity labels.

Inferring Message Content

The problem discovered by the researchers is that a “Malicious 3rd party gaining access to the encrypted email messages may be able to identify content of the messages since ECB leaks certain structural information of the messages.” That certainly sounds like a problem, but the fact is that third parties can only dictate some structural information about emails and not the actual content. Their demonstration of an image extracted from an encrypted message is impressive, but only until you consider that the researchers had full control over the message content and were able to insert the necessary blocks to create the image they displayed. Exposing an image in a protected file makes a nice demo, but it is not the same as being able to extract information from a “real” file selected at random from a set of protected messages.

The practical implications of being able to intercept messages protected by OME is less certain. The researchers say that “an attacker with a large database of messages may infer their content (or parts of it) by analyzing relative locations of repeated sections of the intercepted messages.” The important thing here is that an attacker needs to acquire a large database of messages before they can move to a point where they can infer what the content of any specific message might be. Whether you consider this a practical and potential attack in the wild is up to your judgement. I don’t think it is something to worry about in the real world.

Little Likelihood of Exploitation

My experience is that relatively few messages created by Office 365 tenants use OME protection. Admittingly, even a small percentage of protected messages is a large volume when you consider that Exchange Online processes 9.2 billion messages daily. The counterargument is that the number of protected messages sent by individual tenants or users is usually small.

Some years ago, a conversation with the Microsoft Information Protection team indicated that the percentage of protected messages was in the low single digits. Of those messages, a large number probably remain inside Office 365 and are therefore impervious to interception unless an attacker can comprise the Microsoft 365 infrastructure. If that happens, being able to analyze some protected email to detect patterns that might reveal some potential content is the least of an Office 365 tenant’s problems.

We’re then left with a relatively small amount of messages protected by OME flow out of Office 365 to other mail systems. A potential attacker must therefore work out how to acquire “a large database of messages” to begin inferring what the messages content. Or “Even if specific message would not directly leak information in this way, an attacker with a large body of messages is able to perform analysis of the relation of the repeated patterns in the files to identify specific files. This may lead to ability to infer (parts of) clear text of encrypted messages.” The obvious fact here is that if an attacker can sit on a transmission path from Office 365 to another mail system, they’re likely to capture a vast quantity of unprotected email that can be analyzed and interrogated without any need to decrypt, infer, or otherwise go near protected content.

Microsoft’s Use of ECB

According to the researchers, even though Microsoft paid a $5,000 bounty for discovering the vulnerability, Microsoft’s response was “The report was not considered meeting the bar for security servicing, nor is it considered a breach.” Perhaps Microsoft believes that the practicality of exploitation is so low that the flaw doesn’t merit changing their code.

Interestingly, the researcher points out that the Microsoft Information Protection (MIP) ProtectionHandler::PublishingSettings class has a SetIsDeprecatedAlgorithmPreferred method which says that it “Sets whether or not deprecated crypto algorithm (ECB) is preferred for backwards compatibility.”

The researchers speculate that OME uses this flag to enable ECB rather than the more secure Cipher Block Chaining (CBC) mode.

They also point out that Microsoft’s FIPS 140-2 Compliance documentation explicitly states that “Legacy versions of Office (2010) require AES 128 ECB, and Office docs are still protected in this manner by Office apps.”

What’s weird here is that Office 365 hasn’t supported Office 2010 for years. At first glance, it doesn’t make sense for Microsoft to configure OME to support an ancient legacy version of Office. It would seem to make sense for Microsoft to move from ECB to CBC, but that’s without the benefit of understanding what this would mean in practice for end users. My understanding is that OME uses CBC for non-Office files because there is no reason to support backwards compatibility.

It’s clear from the Open XML format documentation that Office applies compression (Lempel-Ziv) to store documents. The RPMSG “wrapper message” generated by OME is also compressed (I believe that OME uses the Deflate algorithm for this purpose). Logically, compression occurs before encryption. The way compression works ensures that no repetitive patterns or fixed length sequences exist in the file, so the Office documents processed by ECB can’t exhibit the kinds of patterns reported by the researcher. If an attacker captures Office documents, there’s little hope of them being able to infer anything from the document content.

The Net Result

Given the lack of support for Office 2010 within Microsoft 365, it’s logical to ask why Microsoft has not upgraded OME and removed the use of ECB for Office documents. That step might make security researchers happier, but the use of compression in the existing implementation means that it might not make any real practical difference. Overall, the potential for a successful attack on OME-protected email in the wild seems low and the overwhelming percentage of unprotected email seems like a much more lucrative target for attackers.

WithSecure are certainly within their rights to recommend that Office 365 tenants should ignore OME until something better comes long. I disagree. It seems to me that increased use of OME would stop attackers being able to compromise the huge quantity of unprotected email that Office 365 tenants currently send. It’s wonderful to worry about an edge case; the real issue is to protect email in general. And that’s why it still remains so much better to protect confidential email with OME.

---

Learn about protecting Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.