- 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.
- 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
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 WorksRMS 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.
- 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).
- Alice generates a Publishing License (PL), and a Use License (UL) for herself.
- 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.
- 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 SummaryFor 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.
PrerequesitesFor 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
- It reads in the publishing license (PL) and client licensor certificate (CLC).
- 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.
- DisARMS reads the encrypted content bytes and
- uses the RMS API function IpcDecrypt to decrypt the content bytes with the previously acquired content key.
- The decrypted content bytes are written into a new unprotected file, which can later be opened, for example, by using Microsoft Word.
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.
Attack 2: How to Modify RMS Protected Content
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:
- We use the originally protected file and extract the content key from it (black key).
- DisARMS uses this key to encrypt the modified file.
- We then replace the original "encrypted content" in the RMS protected file with the encrypted content of Step 2.
This basically neglects the idea of the view-only RMS protection.
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.
DisARMS at Github
Authors of this PostMartin Grothe
Christian Mainka (@CheariX)