Cyber Security Awareness Month - Day 26 - Sharing Office Files

Published: 2010-10-26
Last Updated: 2010-10-27 12:47:14 UTC
by Pedro Bueno (Version: 1)
8 comment(s)

Cyber Security Awareness Month - Day 26 - Sharing Office Files

Today's CSAM topic is Sharing Office Files.

There are some good points of attention when doing this.

1) Sharing inside the company.

Most companies have shared drives where people use to store documents that can be accessed by
one or several groups.

It is very important that you know who is on the list of Trusted people that can access those documents.

It is also necessary that the shares are included on the Anti-Virus scan and Backup process.

If you are not using a shared drive, but a web-based internal service like MS Sharepoint, the same check
should be done regarding the access control.

Sharing internal documents using external providers such as Google Docs, or Online Fileservers may be a
risk and very likely an internal policy violation even if they provide some level of authentication, so those should
be avoided at any cost.

2) Sharing Outside the company

Sometimes we need to share documents with third party and this can be a difficult task when it comes to security.

When not being able to use some kind of public/private key encryption method between the email exchange,
what I recommend is to use a common key and compact the file with a strong crypto algorithm such as AES.

Most compressors, like WinZip, WinRAR and 7-ZIP offer this option, so in this way you can ensure that even if the
email or file goes to the wrong hands, they may not be able to open the document.

3) Sharing inside the company with removable drives

Sometimes we need to share a document inside the company via removable drives.

At this point you can't really trust what it inside the thumb drive besides the document you need, and today it is very
common to find malware inside them, that will execute via Windows Autorun feature.

If your IT policy allows, you should really disable it this feature.

One thing that I usually do is to check them on my Linux box, and remove autorun.inf file from it before insert on my
Windows box.

4) Receiving Office Documents from outside the company

When receiving documents from outside the company, those will mostly be PDF or MS Office (.DOC, .XLS, .PPT).

Sometimes they may be legit documents, sometimes they may be part of a target attack :) .

There are a couple of ways to check those files. Our fellow handler Lenny Zeltser put together a very nice Cheat Sheet,
called...Analyzing Malicious Documents Cheat Sheet :) You can find the PDF here ( Don't worry, it is not malicious ) :)

It contains several tools that you can use to help the identification of malicious documents when you don't want
to send them to external websites such as VirusTotal or Wepawet due some possible confidentiality issues.
As a last resource, create a VM image with Office and open the documents there :)

Pedro Bueno (pbueno /%%/ isc. sans. org)


8 comment(s)


Pedro, I've also used zip AES256 encryption to share confidential documents.

However, what worries me is the fact that within such zip files, filenames are not encrypted (e.g. Hence the following question to any of you crypto-experts who happen to be reading this.

Without knowing the password, anyone with access to the zip file can observe that, for example, an MS Word .doc file is included. Furthermore, .doc files I create seem always to begin with the following 16-byte sequence:

D0 CF 11 E0 A1 B1 1A E1 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 3E 00 03 00 FE FF 09 00

Considering , does anyone know what the practical risk is of using AES256 encrypted zip files to share confidential office files?

My guess is that nesting once (e.g., even while using the same password for both levels, could somewhat increase security because the number of known bytes is reduced (probably to 4). Is this assumption correct, or is zip-compression fundamentally broken?

If so, (free) alternatives exist, such as Truecrypt and . Opinions on those or practical alternatives are quite welcome!
Re the comment above, about ZIP files showing the filenames of the encrypted content... I just read this about 7Zip on Wikipedia, so perhaps that commentor would like to look into 7Zip:

The 7z format supports encryption with the AES algorithm with a 256-bit key. The key is generated from a user-supplied passphrase using an algorithm based on the SHA-256 hash function. The SHA-256 is executed 219 (524288) times[3] which causes a significant delay on slow PCs before compression or extraction starts. This technique is called key strengthening and is used to make a brute-force search for the passphrase more difficult. The 7z format provides the option to encrypt the filenames of a 7z archive.

[And while we're at it, can someone remove the SPAMmy first post...]
Good artilce, thanks.

The PDS link to Lenny's cheat sheet appears to be broken. Here is the URL I picked up on Lenny's site.

Thomas Reardon
It's been a while since I've worked with zip files in this context, but IIRC the plain-text attack doesn't work on newer versions. I think the mitigating factor is AES-256. Older zip files used only AES-128, which made them vulnerable.
> You can find the PDF here ( Don't worry, it is not malicious ) :)

Seriously - for years now I've been wondering why security researchers still use PDF. I can't be the only one that normally takes a pass as a result.
@PHolder: indeed encrypted filenames are an improvement.

However, an advantage of zip is the compatibility with other tools (WinZip in particular). Chances are that people are not even permitted to install 7-Zip.

Furthermore my guess is that most shared document formats are .pdf and .doc. An attacker might simply assume it's .doc.

What I'm actually interested in is whether encrypting compressors (zip, 7z, rar, ...) implement countermeasures for known-plaintext-attacks. For example, one can imagine that a file is prepended with a random length block filled with random data before encrypting it (the first 4 bytes or so could contain a mangled representation of said block length). Does anyone know whether something like this is used in recent encrypting compression algo's such as zip+AES256?

PS Gary C. Kessler maintains a nice list of "file signatures" here:
"today it is very common to find malware inside them, that will execute via Windows Autorun feature. If your IT policy allows, you should really disable it this feature."

I would suggest something a bit stronger.
Disable the ability to run any software from a thumb drive; force the user to copy the file to the hard drive.

It is almost just as bad when a user opens explorer, double clicks on the disk drive, and the special program indicated by autorun.inf to explore the disk runs, or when they click on a program named to disguise it as a document file.

I suggest turn on the default windows software restriction policies, to allow programs to be run only with certain directories, remove ".LNK" from the list of restricted program file extensions.

Enable users to run programs in the standard directories, their desktop, the system boot drive, and profile directory places other than the default directory that downloaded files are placed in.

7-Zip also supports encryption with AES-256 algorithm. This algorithm uses cipher key with length of 256 bits. To create that key 7-Zip uses derivation function based on SHA-256 hash algorithm. A key derivation function produces a derived key from text password defined by user. For increasing the cost of exhaustive search for passwords 7-Zip uses big number of iterations to produce cipher key from text password.


Diary Archives