Steganography with ooXML (zip) - abusing zip structures

Here is an interesting excercise for the people on this forum;

Requirements Office 2007 (maybe 2010 works too)
Document download; http//www.mediafire.com/?4xsp2fw24alhxp7

Open the linked document named joakim.docx and open it. It is encrypted by Office's built-in functionality and the password is "joakim". If everything goes well, you will successfully decrypt and open the docx, just to find an empty document. Ohh, what a crappy excersise!

Hehe. Now comes the interesting part

Open the file in a hex editor and locate offset 0x1010, which is the beginning of the actual encrypted part. Now remove 16 bytes of 00's prior to that so that the start of the encrypted data is at 0x1000, and save the file. Reopen the document…

Ooops! 😯

If everything goes well, you should see 2 different documents within the same docx! Point is, there is no empty document, but Word interprets it as empty when the header is modified! So if you remove the 16 bytes at 0x1000, Word should see the actual and non-empty document. On my side it works on Office 2007 SP2 norwegian.

Would be nice if those that try it, could report what happened.

I feel very convinced that it is a flawed implementation in Word 2007 and 2010, when handling encrypted documents. evil I have tried with norwegian Office/Word 2007 SP2 and english Office/Word 2010 and it behaves similarly. Instead of trowing an error for corrupted header or corrupted data, it will decrypt the document (if pass is correct though), but will show an empty document without any indication of any possible issue/error! 😯 That's a pretty nice trick to hide your secret docx. The issue seems not affect Excel or Powerpoint. A little note though The docx must first be created/encrypted by Word 2007. The encryption scheme changed in 2010 and the trick will most likely not work. But one can create an encrypted docx in 2007 and then continue working in 2010 with it, and the method will still work (with a tiny extra modification needed in header). roll

As mentioned a few posts ago, stuff can be added at EOF on encrypted docx, xlsx and pptx. In Office 2010 with the new encryption scheme, this really turned into a nightmare from a CF examiners point of view. In 2007, 00's where used to fill up data to a 0x200 page alignment. In 2010, the data behind the encrypted data, is still not evaluated, but now random data is written instead of 00's. So in 2010, one can't really distinguish between default generated data and hidden data. ? At least you could so in 2007. Btw, the page alignment in not evaluated anyway. I guess the good MS guys has a few things to improve here..

And I guess it's time for another PoC.. wink

Here is another one to think about

A signed docx (with a digital signature) can be further tweaked/modified by abusing the package signature implementation (or its specification), because the signature only protects a fraction of the xml files.

That means you can add files to the docx as you would with a regular zip file. You can even modify all the metadata (for instance the author and timestamps) without invalidating the signature!

With all these bugs, there is enough content for a book now.

Hi Joakim

Downloaded the file, ran through your steps and everything worked as it should! Nice little experiment! D

As the 'encryption' of a .docx/xlsx/pptx file basically turns the file into the old .doc/xls/ppt format, would be interesting to know if this same trick works on old 'encrypted' Office files too?

Regards
Paul

In January I gave a presentation (http//www.slideshare.net/rzirnste/dark-data-hiding-in-your-records-opportunity-or-danger) that talked about places that data can be hidden. On slide 12, I talked about adding files to an MS Word 2007 document without causing errors. Here are the slide notes

Step 1 Rename the file to be smuggled to ‘document.xml’ (I used a simple text file)
Step 2 Rename Word.docx to Word.zip
Step 3 Open Word.zip with WinZip
Step 4 Add the new smuggled ‘document.xml’ to Word.zip (in the root)
Step 5 Rename Word.zip to Word.docx

The key was to pick a filename that normally appears in a .docx file, but put it in a different folder so that it isn't read by MS Word. MS Word appears to watch for invalid filenames but not for invalid file locations. The point of this exercise was to show how simple it is, for even novice users, to hide data in an MS Office document.

We've found that 50+ file types are using the Zip format to store their data. You can find a list of these file types at http//www.forensicinnovations.com/formats-fe.html They are the entries that use our 'archive' library.

There are many file types that can use these methods for steganography.

@ForensicRob
The board software parsed the final full stop as part of the url, so the link is NOT clickable, here it is corrected
http//www.forensicinnovations.com/formats-fe.html

@joakims
Congratulations ) , you made me do something I would have never been possible 😯 actually regret (temporarily and ONLY for this particular instance) that I don't use the 2007 or 2010 version of MS Office, and I cannot test your nice approach.

jaclaz

@paulandrewsfca
The encryption header is created differently on previous versions, and I have not managed to reproduce it on 2003 or earlier.

@ForensicRob
That is one of those things Initially excluded from the thread as it's already "widely" discussed. But it now catches my interest again when bringing digital signatures into the case. Ideally, I would say, the signatures purpose would be for the verification of the integrity of the whole document (or at least as much as possible). The way the signing of documents in Office 2007/2010 have been implemented, is flawed by design. The 2 main issues as I see it;

1. The signature does not protect all files in the ooXML document (and most importantly [Content_Types].xml).
2. The signatures is applied before the final packaging (and not after).

Because of these 2 points, there exist too many ways to hide data in signed documents. However, the actual heart of the document (document.xml for docx), is of course still protected and can't be modified. Unless, you manage to implement 2 sets of .rels files, something I've already tried without success. The unprotected [Content_Types].xml is a potential big issue here.

Comparing against Authenticode signed executables (which also can contain hidden data), the signing of documents certainly has a few shortcomings.

I wrote 2 applications to prove the point I made about the signature in sig1.xml. Try it out and see. Strange that the signature is still valid right..

A good explanation is in the included readme. Download; http//www.mediafire.com/?yo61dckenb1dxeo

The only way to identify it is by carefully evaluating the XML tags. Strange that these tags don't trigger any alert message;

Internal zip timestamps will not tell much;

The data is compressed and encoded, and the extracter will autodetect content (since the custom tags are hardcoded).

I also whipped together more code to perform the "invisible docx trick"; http//www.mediafire.com/?6e6y4vxb4tou5fo

From the readme;

These tools implements a tiny nice trick that fools Word when opening encrypted documents. Specifically there appears to be a flaw in Word 2007/2010 that fails to identify certain erronous crypt headers. This flaw will decrypt the docx and open what appears to be an empty document, when the actual document is kept "invisible". And of course no error message is presented with any indication that anything might be wrong. The flaw affects Word 2007 and 2010, and I have tried both norwegian and english versions. The document must be first encrypted in 2007 for the trick to work. In 2010 the crypt header changed and the trick no longer works. That means;

- A docx encrypted in 2007 will have the trick work in both 2007 and 2010.
- A docx encrypted in 2007 and later saved/modified in 2010, will have the trick work in both 2007 and 2010.
- A docx encrypted in 2010 will not have the trick in either 2007 or 2010.

Excel and Powerpoint seems not affected by the flaw.

So what is the trick?
It is simply a matter of injecting 00's right before the crypted data. Testing reveals that a minimum of 8 bytes must be injected (ie 7 bytes will trigger an error message).

For what use?
Hide your original docx. If asked for password, give it and an empty document is all that shows up.. Anyways, a funny trick.

Note
If you open and save the "empty" document, the original document will be lost. If the encrypted docx is also digitally signed, the trick will not work.

Usage
The hider is console compiled and can take 2 parameters. First is a valid docx file path, and the second is the number of bytes to inject. If not used from command line, just double click and a fileopen dialog will be presented (a default of 16 bytes is injected if params are not used. Example

CryptedDocxHider.exe "%CD%\mytest.docx" 32
CryptedDocxHider.exe D\tmp\mytest.docx 8

The unhider is similarly compiled, but does not take a second parameter. Ie 1 param is needed and must the full path to your docx. Or just double click the exe and a fileopen dialog will be opened. Example

CryptedDocxUnHider.exe D\tmp\mytest.docx

Just note that any error messages will not be seen if the exe's are not run from command line.