Part 2, Steganography; Hiding from eDiscovery in plain sight


In my last blog I described a unique way of hiding incriminating data from eDiscovery queries in plain sight. In the example, I was able to hide obviously responsive information in a QR code attached as part of the signature to an email message.  The point was to show that ESI, especially email, can still be used to communicate with others and remain under the radar of the best eDiscovery search applications.

Now let’s look at another way to hide incriminating ESI from eDiscovery search applications.

The technique is called Steganography. Steganography is the art and science of writing hidden messages in such a way that no one, apart from the sender and intended recipient, suspects the existence of the message; a form of security through obscurity. The best known Steganography technique hides information in standard graphic images.

Graphic #1: Tree

The above image of a tree includes a steganographically hidden image. The hidden image (the image of the cat below) is revealed by removing all but the two least significant bits of each color component and a subsequent normalization. The hidden image is shown below.

Graphic #2: Cat

You can hide any electronically stored data in any graphic image. As in the example above, a picture can be hidden in another picture. But the technique is not limited to hiding pictures in pictures. A word document, a schematic, even a sound file can be embedded and hidden in any graphic.

There are several free steganography applications available on the internet. I found and tested two; Invisible Secrets 2.1 and Xiao Steganography. Both use JPEG images as the “carrier” device.

How can this technique be used to pass incriminating information to someone else? Using the email example from my previous blog, let’s look at the example email message below from Bill to Ken.

Email example #1

There is absolutely nothing out of the ordinary in this email and would not trigger an eDiscovery search application to flag it as suspicious. Look closely at the email signature especially the eDiscovery101 graphic. Now look at the email below:

Email example #2

The second email looks exactly the same. Again there would be no reason for an eDiscovery search application to flag it as suspicious. But, hidden in the second email’s eDiscovery101 graphic is the very incriminating Word document shown below:

Graphic #3: Incriminating letter

This raises the question; if you were conducting an eDiscovery investigation, how would you ever suspect that there is additional responsive data included in the in the “eDiscovery101” email signature graphic and if you did suspect hidden data, how could you prove it?

To answer the first question, we need to understand how steganography applications work. For this example I will use the Invisible Secrets 2.1 application.

The application includes a helpful wizard to quickly walk you through the process.

The first step is to decide which graphic file you will use as the “carrier” for the incriminating data. In this case I will use my standard JPEG file for my blog, eDiscovery101.

The next step is to select the source file or in this example the incriminating letter from above.

Next, a password for encryption of the incriminating letter is requested. This will insure the incriminating (hidden) data in the eDiscovery101 graphic cannot not be accessed, even if suspected.

Lastly, you need to give the application a destination file name. In this case I named it something obvious and familiar, eDiscovery101s.jpg, so as not to draw attention to it. At this point, after the “Next” button is pressed, the new graphic file is created and can be inserted into the email signature.

Detecting hidden data via automation is tough if not impossible. As I mentioned before, As far as I know, there is no eDiscovery application which can recognize and flag steganography. To have a chance, you must already suspect a custodian and then manually look for inconsistencies. For this example, the only way to tell if a given graphic contains hidden data is to compare the size of the images. The two eDiscovery101 images have different sizes. The original eDiscovery101 image is a 52KB JPEG file, while the second eDiscovery101 image is a 78KB JPEG file. Another clue to hidden data would be to search for know steganography applications on the custodian’s desktop or laptop (if they didn’t delete it after creating the hidden data). But remember, even if you find a suspicious image, without the encryption password you will never be able to open it.

To protect organizations from this type eDiscovery liability they can put some basic measures in place. Most importantly, include in your email system use policy a definitive statement about using these types of encryption applications on any organization owned assets, and audit custodians for enforcement. You could also forbid placing graphic images within the body of an email but this is not realistic. For example you could insert the same incriminating letter mentioned above into a table within a spreadsheet and convert that table to a JPEG. Below is a spreadsheet converted into a JPEG image file with the same incriminating letter embedded in it.

Spreadsheet #1

Would the above spreadsheet embedded into an email raise suspicions? Probably not… If custodians are determined to hide data in plain sight, they can with little chance of being caught.

Advertisements

Court Case Tests Right To Withhold Passwords


From an article Mathew J. Schwartz at InformationWeek

Does the constitutional right against self-incrimination give a criminal defendant the right to withhold computer passwords that law enforcement could used to decrypt a hard drive and obtain evidence against that defendant? That question is at the root of a Colorado court case centering on multiple mortgage fraud schemes, and a defendant’s encrypted laptop.

In particular, an indictment returned by a Denver grand jury on Oct. 1, 2010, charged Ramona Fricosu (aka Ramona Smith), 36, of Peyton, Colo., among other defendants, with multiple counts of bank fraud, wire fraud, money laundering, and making false statements to a financial institution.

As part of that investigation, law enforcement agents obtained a search warrant for Fricosu’s house, which she shares with her mother, two children, and formerly shared with Scott Whatcott (aka Michael Scott Smith), 36, also a defendant in the case. As part of that search, investigators seized multiple computers and storage devices, including a Toshiba Satellite M305 laptop.

After obtaining another search warrant to search the laptop, investigators found that the contents had been encrypted. Accordingly, prosecutors demanded that Fricosu enter her password into the laptop, enabling them to decrypt the drive, or else provide them with a complete copy of the decrypted data.

But her attorney, Philip L. Dubois, has argued that doing so would violate her Fifth Amendment rights against self-incrimination. Dubois himself is no stranger to encryption, having previously defended Philip Zimmermann, who created Pretty Good Privacy (PGP) encryption software in 1991. Shortly after its introduction, the software became available abroad, which led to a Customs Service investigation in which Zimmermann was accused of breaking the Arms Export Control Act, for exporting strong cryptographic software, which was then classified as munitions. The investigation ended after three years; no charges were filed.

The entire InformationWeek article can be read here

“Free to the public cloud storage” – Becareful…


In a recent blog posting titled “The coming collision of “free to the public cloud storage” and eDiscovery”. I mentioned some of the potential gotchas involved in storing your ESI with these cloud services. One of the cloud storage services I named was the Dropbox service.

On Friday the Dropbox cloud storage start-up announced changes to its policies, claiming it had rights to your data stored on its service.

The original section read: “You grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent reasonably necessary for the Service.”

This message obviously started a major reaction so the company has revisited its terms again, being forced to update its blog twice in order to try and calm the storm surrounding its policy.

The last two blog updates are below:

[Update – 7/2] – We asked for your feedback and we’ve been listening. As a result, we’ve clarified our language on licensing:

You retain ownership to your stuff. You are also solely responsible for your conduct, the content of your files and folders, and your communications with others while using the Services.

We sometimes need your permission to do what you ask us to do with your stuff (for example, hosting, making public, or sharing your files). By submitting your stuff to the Services, you grant us (and those we work with to provide the Services) worldwide, non-exclusive, royalty-free, sublicenseable rights to use, copy, distribute, prepare derivative works (such as translations or format conversions) of, perform, or publicly display that stuff to the extent reasonably necessary for the Service. This license is solely to enable us to technically administer, display, and operate the Services. You must ensure you have the rights you need to grant us that permission.

[Update 2 – 7/2] – An update based on your feedback:

One of the main reasons we updated our terms of service was to make them easier to read and understand. It seems we’ve mostly accomplished that, which we’re thrilled about.

Some of you have written us with very understandable concerns about the legal-sounding parts. In particular, our new TOS talks about the licenses we need to run Dropbox. We want to be 100% clear that you own what you put in your Dropbox. We don’t own your stuff. And the license you give us is really limited. It only allows us to provide the service to you. Nothing else.

We think it’s really important that you understand the license. It’s about the permissions you give us to run the service, things like creating public links when you ask us to, allowing you to collaborate with colleagues in shared folders, generating web previews or thumbnails of your files, encrypting files, creating backups… the basic things that make Dropbox safe and easy to use. Services like Google Docs and others do the same thing when they get these permissions (see, for example, section 11.1 of Google’s TOS).

We wish we didn’t have to use legal terms at all, but copyright law is complicated and if we don’t get these permissions in writing, we might be putting ourselves in a tough spot down the road. Not to bore you with the details, but please take a look at the license term in the TOS. We think it’s fair and strikes the right balance: “This license is solely to enable us to technically administer, display, and operate the Services.”

We want to thank everybody who wrote in, understanding your concerns helps us make Dropbox better.

Drew & Arash

It looks to me that they made a decent and honest attempt to come back from a really unsettling policy change. The main point here is that you have to understand the policies which manage your data on these services.

One practice I employ when using these services is to encrypt the data I upload to these services using applications such as TrueCrypt or PGP (see my blog on this topic). This practice does remove some of the capabilities such as indexing for search on the cloud service but the main reason I utilize these cloud storage offerings is to to be able to access my data anywhere from any computer.

Encrypted and hidden files put eDiscovery at risk


There are some pretty nice freeware applications available which allow a user to encrypt and hide files/data/electronic records in plain sight on their computers. Can this pose a problem for IT and corporate legal?  Let me put it this way…how would you find and place ESI that’s encrypted or is both encrypted and made to look like something else on a litigation hold?

Does the fact that encryption applications present in a corporate infrastructure make claims of spoliation if the files can’t be found or decrypted more likely? Is this a problem you should even worry about?

It’s a stretch but in some circumstances this capability could significantly raise your eDiscovery risk. To illustrate this problem further I will specifically talk about an application called TrueCrypt which is a free open-source disk encryption software application for Windows 7/Vista/XP, Mac OS X, and Linux.

TrueCrypt is an application for creating and maintaining an on-the-fly-encrypted volume (data storage device as opposed to a single file).This means that you can create an encrypted volume capable of storing many encrypted files which to casual observers, looks like a single file. On-the-fly encryption means that data is automatically encrypted or decrypted right before is loaded or saved, without any user intervention. No data stored on an encrypted volume can be read (decrypted) without using the correct password or correct encryption keys. There are several encryption algorithms available in the application but the most secure is the AES 256-bit key algorithm, the same one used by the federal government in many instances.

Files can be copied to and from a mounted TrueCrypt volume just like they are copied to/from any normal storage device (for example, by simple drag-and-drop operations). Files are automatically decrypted on-the-fly (in memory/RAM) while they are being read or copied from an encrypted TrueCrypt volume.  Similarly, files that are being written or copied to the TrueCrypt volume are automatically being encrypted on-the-fly (right before they are written to the disk) in RAM.

Now, to make matters worse (or better depending) TrueCrypt also can create a hidden encrypted volume within the visible encrypted volume.

The layout of a standard TrueCrypt volume before and after a hidden volume was created within it. (Graphic from the TrueCrypt manual)

The principle is that a TrueCrypt volume is created within another TrueCrypt volume. Even when the outer volume is mounted and visible, it would be impossible to prove there is a hidden volume within it or not, because free space on any TrueCrypt volume is always filled with random data when the volume is created and no part of the (dismounted) hidden volume can be distinguished from random data. Note that TrueCrypt does not modify the file system (information about free space, etc.) within the outer volume in any way.

So to put it another way, an employee trying to hide data from a discovery search could first create an encrypted volume on their hard disk or some other removable device such as a USB stick and store encrypted data on it. Even more diabolical, they could move some innocuous data to it as a decoy and store the real data on the hidden volume inside the original volume. This capability provides the employee plausible deniability in the case of corporate legal or IT forces the employee to decryption the volume they can see.

So the big question is this; how would you as a discovery auditor even know of or find these hidden and encrypted data volumes? In reality it’s not easy. You have to go into it looking for hidden and encrypted data. There are some forensics applications that will at least find and flag encrypted files and volumes including the TrueCrypt format. I am unable to determine if these forensics applications can find and flag hidden volumes.

As a test, I setup a 10 GB TrueCrypt encrypted volume on this computer and named it “Attorney Communication” in a folder I named “contracts”. To the casual observer all they see is a large file in a folder called “contacts” (see below).

Within that encrypted “Attorney Communication” file I copied four decoy files to make it look like those were the important files I was keeping encrypted just in case I am forced to open the encrypted volume by legal (see below).

As you can see above, you can’t tell by looking at it that it contains the hidden 8 GB volume I had also created. That hidden volume is accessible only by typing a totally different password.

The hidden 8 GB TrueCrypt volume on this computer

So how do you find these hidden volumes and files if the employee is not cooperating? If you suspect the employee has been using this technology the first obvious step would be to do a search of the employee’s hard disk looking for an application called “TrueCrypt”. This would be a dead give-away that the employee could have encrypted and hidden data volumes on their computer. This is not  certain because the employee could have installed the TrueCrypt application on a USB stick, which does not integrate with Windows, so when not plugged in to the computer, there would be no trace of the TrueCrypt application.

A second way to find potentially encrypted volumes would be to search for very large files. Usually encrypted volumes will be larger than normal files because they are just that, a large space to store many files. So you could do a Windows search for files over 10 MB and see what you get. An indication would be a large file with no applications associated with it. By this I mean that when you double click the file the system doesn’t recognize it as a standard Windows application and displays the “Open with” dialog box shown below:

That leaves the problem of discovering the hidden volume. A sure but very slow process to test this possibility would be to copy a bunch of files into the encrypted volume, if the employee has opened it, to see if the available storage space id equal to the volume size.  For example the file properties in Windows states my encrypted volume is 10 GB in size but in this example the employee only has 5 MB of files stored in it. To test to see if the volume contains a hidden volume, you could copy an additional 9.95 GB of data into it to see if you get a “volume full” message before all of the data was copied into it. If you could only copy an additional say 1.95 GB before the “volume full” message was received, that would indicate that a hidden 8 GB volume exists.

A faster way to get an indication of hidden volumes is to use a large file finder tool. I found one called “Largefiles3” which had a surprising capability. In this case I ran the application looking for files larger than 10 MB on the C drive.

The interesting capability here is that it found the encrypted volume I named “Attorney Communication” but it determined its size to be 2.147 GB not the 10 GB shown in the Windows file system data. This is because I had created an 8 GB hidden volume inside the “Attorney Communication” volume thereby only leaving 2 GB for the original volume. This is a huge red flag if you are looking for it. Now, without the password you still can’t access the original encrypted volume or the hidden volume but at least you would know it exists and can apply pressure to the employee.

So how do you prevent these encryption applications from putting your eDiscovery processes at risk? The most obvious one is to include in your employee computer use policy a statement prohibiting the use of these types of applications with stated punishments if not followed. This will stop general employees from using this kind of application but will not deter those employees bent on breaking your rules. The obvious next step is to sample and audit your employees to see if these applications are being used. For corporate legal, the main thing you want to establish is your “good faith intent” to make sure your eDiscovery processes are defensible.