How to Break Microsoft Rights Management Services

In this post, we provide a security analysis of Microsoft Rights Management Services (RMS) and present two working attacks: 

1. We completely remove the RMS protection of a Word document on which we only have a view-only permission, without having the right to edit it. This shows that in contrast to claims made by Microsoft, Microsoft RMS can only be used to enforce all-or-nothing access. 
2. We extend this attack to be stealthy in the following sense: We show how to modify the content of an RMS write-protected Word document issued by our victim. The resulting document still claims to be write protected, and that the modified content was generated by the victim

This work is going to be presented at WOOT'16.

RMSs are used to enforce access control in a distributed environment, and to cryptographically protect companies’ asset by restricting access rights, for example, to view-only, edit, print, etc., on a per-document basis. One of the most prominent RMS implementations is Microsoft RMS.
It can be found in Active Directory (AD) and Azure.

Besides others, Microsoft claims IRM to help to do the following:

• "Prevent an authorized recipient of restricted content from forwarding, copying, modifying, printing, faxing, or cutting and pasting the content for unauthorized use"

How RMS Works

RMS makes use of a very complex PKI to protect files. We do not go into details here and give only the minimum information required to understand the attacks.

The picture above illustrates an RMS protected file. The process of protecting a Word file consists of three steps:

1. Alice’s client software (e.g., Word) generates a random content key (black key in PL) and uses it to encrypt the Word content (black lock).
2. Alice generates a Publishing License (PL), and a Use License (UL) for herself.
3. The protected word document consists of the PL for the server, the author’s public part of the Client Licensor Certificate (CLC) and the encrypted document.

There are a lot of technical terms in this description. What we need to know for the following attacks is:

• The content is encrypted using a random key (illustrated as a black key in the picture).
• The key itself is encrypted (blue lock). If someone else wants to decrypt the file, he has to get the black key. In RMS, he requests this key at a server (Active Directory or Azure), which basically sends it to him if he is allowed to get it.
• Most notably, there is no signature protecting the encrypted content. RMS uses AES in CBC or ECB mode, depending on the application using RMS.

Short Attack Summary

For those of you, who just want to have a brief overview on what we did, we summarize our attacks here. More details on Microsoft RMS and its complex workflows can be found in our research paper.

Prerequesites

For both attacks, we assume that an attacker has access to an RMS protected Word file. We have only tested Word files, but due to the nature of the attacks, arbitrary RMS protected files should work (Excel, Powerpoint, Txt, Binary,  ...).
We further assume that the attacker has the view access right only on the file. This is the minimal right that can be granted to some user.

Suppose that the attacker is working for some company A. He has received an evaluation of some important technology. Since he is an attacker, he wants to sell this information to some other company B. This is, where RMS protection takes places: the view access is restricted to himself and he cannot send this file, for example, via Email to company B, because they don't have the view right and therefor can not get access to the file.

This is, where our first attacks takes place.

Attack 1: How to Remove RMS Protection

For the first attack, we split the protected Word document (OLE compound file) into its components (RMS License and EncryptedPackage). We created an attack tool called DisARMS (Disabling Attacks on RMS) that can be executed by every user of the domain if he has the view right. DisARMS removes the protection automatically, without any further interaction  and creates a copy of the processed RMS protected file, which contains the same content, formatting, etc, but without the RMS protection. No administrative priviledges on the client are needed for running the attack.

DisARMS executed the following steps:

1. It reads in the publishing license (PL) and client licensor certificate (CLC).
2. It uses the certificates from the previous step to request the content key (from the use license) from the RMS server or the client licensor cache.
   Since we assume that our attacker has view access on the file, he receives the encrypted content key.
3. DisARMS reads the encrypted content bytes and
4. uses the RMS API function IpcDecrypt to decrypt the content bytes with the previously acquired content key.
5. The decrypted content bytes are written into a new unprotected file, which can later be opened, for example, by using Microsoft Word.

Basically, this attack is not very surprising. What we generally did, is that we decrypted an encrypted file for which we know the key. This is of course nothing that Microsoft wants us to do, so we had to implement DisARMS to perform all the steps.

You might say: "Hey, why couldn't I simple to screenshots of the file or retyping the content into a newly created file?". This is something that you can obviously do, although this might either loss the formatting (screenshot case) or take a long time (typewriting). This is also declared as out-of-scope by Microsoft.

But now comes the clue: we extended the first attack to an even more severe one. The second attack makes use of the first attack and goes one step further. After removing the protection, we modify the unprotected content of the file.
We then reprotect the file, so that it looks as it would have been created by the original author of the protected file, but contains the content that we have just modified.

Suppose that an angry employee gets some information by his boss. He can then use the second attack, to modify the content, and, for example, fire someone else or pretend to receive a salary increasement.

Attack 2: How to Modify RMS Protected Content

This attack has the same requirements as the first attack.
Suppose we have removed the protection of one file. We can modify the content arbitrarily, for example, by using Word. We then use DisARMS to re-protect the document as follows:

1. We use the originally protected file and extract the content key from it (black key).
2. DisARMS uses this key to encrypt the modified file.
3. We then replace the original "encrypted content" in the RMS protected file with the encrypted content of Step 2.

The tampered protected document can not be distinguished from the original protected document. It will look as it would have been created by the original author and only show the correct view access right for the attacker.

This basically neglects the idea of the view-only RMS protection.

Short Remarks:

The first attack is obviously nothing new. Such kind on attacks have been shown on, for example, DRM protected eBooks.

The really worse thing is the second attack: RMS does not use any integrity protection on the content (e.g. a signature). This allows us to change the content arbitrarily.

Microsoft Response:

“The type of attack you present falls in the category of policy enforcement limitations. Policy enforcement capabilities, such as the ability to prevent printing or modifying content to which the user has legitimate access, are not guaranteed by cryptography or other hard technical means“ - Microsoft Security Response Center <secure@microsoft.com>

While this is correct for the first attack, the second attack can be prevented by using digital signatures on the content. We proposed this to Microsoft. In fact, applying signatures is not as easy as one might expect due to the complex RMS PKI, but it is possible.

DisARMS at Github

Our attack source code can be found at Github:

https://github.com/RUB-NDS/MS-RMS-Attacks

Authors of this Post

Martin Grothe
Christian Mainka (@CheariX)