My next class:

Imaging LUKS Encrypted Drives

Published: 2013-08-14. Last Updated: 2013-08-15 11:54:29 UTC
by Johannes Ullrich (Version: 1)
5 comment(s)

 

This is a "guest diary" submitted by Tom Webb. We will gladly forward any responses or please use our comment/forum section to comment publically. Tom is currently enrolled in the SANS Masters Program.

When imaging a live system there are several factors to be taken into account. But this post is going to cover encrypted Linux systems. Use of the logical drive for imaging encrypted systems is critical if you do not have the decryption password.
 
A couple of key commands to use on Linux systems are: mount and fdisk. The mount command will give you a list of devices that are currently available to the OS. These mappings are the logical mounts on the system.
 
When reading output from the mount command on the left side is the device/object that is mounted and on the right is the logical mount point (e.g. Folder name).
 
# mount /dev/mapper/tw--pc-root on / type ext4 (rw,errors=remount-ro,commit=0)
 
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
/dev/sda1 on /boot type ext2 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
vmware-vmblock on /run/vmblock-fuse type fuse.vmware-vmblock (rw,nosuid,nodev,default_permissions,allow_other)
gvfs-fuse-daemon on /home/twebb/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=twebb)
 
In the example above, I'm running whole disk encryption using LUKS. You can tell this by seeing the /dev/mapper being used for the mount point / instead of a hard drive device.
 
The boot mount points to a hard disk device /dev/sda1. This device is being directly mounted to a disk partition and is not encrypted. This is a typical setup for LUKS where the kernel is located in an unencrypted volume and all other volumes are encrypted.
 
Now we know what is mounted on the file system, lets look at the available disks and see if there are additional disks not mounted that we need to capture.
 
root@tw-pc:/tmp# fdisk -l
 
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes�
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
�Units = sectors of 1 * 512 = 512 bytes
�Sector size (logical/physical): 512 bytes / 512 bytes
�I/O size (minimum/optimal): 512 bytes / 512 bytes
�Disk identifier: 0x000edb98
 
Device Boot Start End Blocks Id System
�/dev/sda1 * 2048 499711 248832 83 Linux
�/dev/sda2 501758 1953523711 976510977 5 Extended
�/dev/sda5 501760 1953523711 976510976 83 Linux

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
�255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors�
Units = sectors of 1 * 512 = 512 bytes�
Sector size (logical/physical): 512 bytes / 512 bytes
�I/O size (minimum/optimal): 512 bytes / 512 bytes
�Disk identifier: 0x08020000
 
Disk /dev/sdb doesn't contain a valid partition table
 
Disk /dev/mapper/sda5_crypt: 999.9 GB, 999946186752 bytes�
255 heads, 63 sectors/track, 121569 cylinders, total 1953019896 sectors
�Units = sectors of 1 * 512 = 512 bytes
�Sector size (logical/physical): 512 bytes / 512 bytes
�I/O size (minimum/optimal): 512 bytes / 512 bytes
�Disk identifier: 0x00000000
 
Disk /dev/mapper/sda5_crypt doesn't contain a valid partition table
Disk /dev/mapper/tw--pc-root: 975.4 GB, 975435726848 bytes�
255 heads, 63 sectors/track, 118589 cylinders, total 1905147904 sectors�
Units = sectors of 1 * 512 = 512 bytes
�Sector size (logical/physical): 512 bytes / 512 bytes
�I/O size (minimum/optimal): 512 bytes / 512 bytes�
Disk identifier: 0x00000000
 
Disk /dev/mapper/tw--pc-root doesn't contain a valid partition table
 
Disk /dev/mapper/tw--pc-swap_1: 24.5 GB, 24461180928 bytes
�255 heads, 63 sectors/track, 2973 cylinders, total 47775744 sectors
�Units = sectors of 1 * 512 = 512 bytes
�Sector size (logical/physical): 512 bytes / 512 bytes�
I/O size (minimum/optimal): 512 bytes / 512 bytes
�Disk identifier: 0x00000000
 
Disk /dev/mapper/tw--pc-swap_1 doesn't contain a valid partition table
 
In the above output we see that /dev/sda has three partitions (sda1,sda2,sda5). We see that /dev/mapper is using sda5 and that tells us that partition is encrypted. We also have a /dev/sdb device that is not mounted and appears to not have a valid partition  This is likely an encrypted drive that is not currently mounted.
 
what options do you have?
�If you know the encryption password and the system is not RAID I would image the physical drive. The Physical drive were /dev/sda and /dev/sdb.
 
#dcfldd if=/dev/sda of=/mount/usb/system-sda.dd conv=noerror,sync bs=512 hash=md5,sha256 hashwindow=10G md5log=sda.md5 sha256log=sda.sha256
 
#dcfldd if=/dev/sdb of=/mount/usb/system-sdb.dd conv=noerror,sync bs=512 hash=md5,sha256 hashwindow=10G md5log=sdb.md5 sha256log=sdb.sha256
 
If you do not know the password, grab the logical volume (in this case / which is mapped to the device /dev/mapper/tw--pc-root ) of the first drive and the physical of the second. Also grabbing memory from the system maybe used to guess the password.
 
Test to see if you imaged the physical partition could you mount it
 
#mount -o ro,loop /dev/sda5 /tmp/mount/ mount: unknown filesystem type 'crypto_LUKS'
 
It appears that it is a LUKS encrypted
 
Test the logical partition and see if it looks correct
 
#dd if=/dev/mapper/tw--pc-root of=/tmp/usb/test.dd count=10
 
Use the file command to see if it will detect the test as a valid partition.
 
#file test.dd   test.dd: Linux rev 1.0 ext4 filesystem data, UUID=69cc19e5-5c81-4581-ac0b-9c8fac8f9d96 (needs journal recovery) (extents) (large files) (huge files)
 
Above, we can see that the file command successfully detected this as a valid partition.
 
Check and see if the partition is encrypted by running strings on the test image.
 
#strings test.dd
 
GNU GENERAL PUBLIC LICENSE�
Version 2, June 1991
�Copyright (C) 1989, 1991 Free Software Foundation, Inc.�
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
�Everyone is permitted to copy and distribute verbatim copies�
of this license document, but changing it is not allowed.
 
All signs appear to indicate that the logical image will work as we intend.
 
Collecting Logical Drive
 
#dcfldd if=/dev/mapper/tw--pc-root of=/mount/usb/logical-sda.dd conv=noerror,sync bs=512 hash=md5,sha256 hashwindow=10G md5log=logical-sda.md5 sha256log=logical-sda.sha256
 
Once collected you will need to use the following mount command, courtesy of Hal Pomeranz http://goo.gl/gdXhQk,  to access it.
 
#mount -o loop,ro,noexec,noload logical-sda.dd /tmp/mount/
 
-----
Tom Webb

 

 

 

5 comment(s)
My next class:

Comments

I *ALWAYS* image the physical drive. Always image it to a drive that is at least as big as the drive being imaged (use fdisk -l to see how big a drive is). That way, you know you will not loose any information. Once you have captured the images of all the drives in the system, then you can play around with them to see what you have gotten. Also, a drive need not be partitioned at all in a linux system; it can have LVM riding directly on the physical drive. I frequently set up systems this way if I do not need to boot from that drive. A very typical setup in my shop is a 3-way raid1 mirror, so that I can pull a drive (or have a drive fail) and still have redundancy. I run the raid directly on the physical drives, with no partitioning. I then start the raid and run LUKS encryption on the resulting raided device manager psuedo-device. Next, I impose LVM on the LUKS psuedo-device, and then I set up the result as an LVM physical volume. I then create my LVM volume group, and then my LVM logical devices. I typically boot from a USB stick. This setup allows me to run 3-way raid1 mirroring in a fully encrypted whole physical disk fashion, so the entire physical disk is encrypted. For laptops, I skip the raid part and boot from a USB stick that is only inserted when the system is booted. I use a USB stick with a rugged keychain carrier, so it can be carried about like any other key. That keeps the laptop itself unbootable if it gets lost or stolen.
Re-imaging really sounds like something from the Windows world. In GNU/Linux/LSB/UNIX/POSIX land, filesystems are much more neatly structured. Surely 'tar' could accomplish the same task faster by working at the file level, copying only the allocated data blocks; or 'rsync' could restore some or all filesystems to a previous state even more efficiently - incrementally - if the destination filesystems are still there. Otherwise, recreating partitions tables and fileystems first according to some template, is easily scripted, as well as rewriting the bootloader.
Ya gotta think like a crook! :->

Think un-allocated portions of a disk drive could contain malware, or the boot block is infected. You never know the whole story unless you have the whole story. Alway image a drive if you are interested in forensic information. If all you care about is some of the files, get a good backup system and recover from that.
Thanks for this great summary.
You shouldn't use dcfldd any more though, as it isn't be maintained any more (latest update is from 2006!) and contains known bugs: http://sourceforge.net/p/dcfldd/bugs/

Instead, dd would be sufficient for illustration purposes in this blogpost, or alternatively the much more versatile dc3dd would be a good choice.

Marek
Thanks for this great summary.
You shouldn't use dcfldd any more though, as it isn't maintained any more (latest update is from 2006!) and contains known bugs: http://sourceforge.net/p/dcfldd/bugs/

Instead, dd would be sufficient for illustration purposes in this blogpost, or alternatively the much more versatile dc3dd would be a good choice.

Marek

Diary Archives