Threat Level: green Handler on Duty: Johannes Ullrich

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2013-08-14 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

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)

How to get sufficient funding for your security program (without having a major incident)

Published: 2013-08-14
Last Updated: 2013-08-15 01:37:16 UTC
by Johannes Ullrich (Version: 1)
6 comment(s)

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

The primary reason your security program is struggling is not your lack of funding. You must find a better excuse than not having the budget you are convinced you need in order for your security program to succeed. Do not blame poor security on poor funding. Blame bad security on the REAL reason you have bad security. I hope to encourage you to take a new look at what you are doing and determine if it is working. If not, I encourage you to make a change by using the tools and capabilities you currently have to help tell an accurate story of your security program - with much needed and overdue metrics.

Every person can improve their overall security posture by clearly articulating the current state of their security program. Think creatively and start somewhere. Do not just sit by and wish for a bucket of money to magically appear. It will not. What can you do today to make your world better without spending any money? With some thoughtful effort, you can begin to measure and monitor key metrics that will help articulate your story and highlight the needs that exist in your security program.

When you do start recording and distributing your metrics, make sure they are delivered on a consistent schedule. Consider tracking it yourself for several weeks to make sure trends can be identified before it is distributed to others. Consider what this metric will demonstrate not only now, but also three months from now. You do not want to be stuck with something that does not resonate with your audience or even worse, provides no value at all.

Do not hide behind the security details of your message. Ask yourself why would someone who is not the CISO care about what is being communicated? How would you expect them to use this information? Start planning now for your response ahead of being asked. Think about what you want the recipient to do with this information and be prepared with some scenarios of how you will respond they ask for your plan. Never brief an executive without a plan.

Develop and rehearse your message in advance. Look for opportunities to share your message with others during the course of your day. Every day. Practice delivering your "elevator pitch" to make sure you are comfortable with the delivery and timing of the content. Ask your non security friends if your message is clear and can be easily understood. Often those who are not as close to the message can provide much more objective feedback. Resist the urge to tell every single thing you know at your first meeting. Give enough compelling facts that the recipient wants to know more, in a manner in which they can understand (without having to be a security professional). 

I recognize this behavior every time I see it because I used to be guilty of the very same thing. I am certain that I was the worst offender. It takes no effort to sit by and complain. That only serves to make things worse. It takes commitment to conquer the problem. Unfortunately, only a few do that very well. Change your paradigm from why will no one listen to me to what is my plan to communicate the current situation in an effective manner. Have you found yourself guilty of admiring the problem? Do you stop working on problems when you realize that it is going to be simply too hard? Think beyond the current state and look to how things could be with focused effort. 

Do not ask for everything at once. Seek an initial investment in your security program and demonstrate with metrics the value of that investment. Show how you have been a good steward with the initial investment and can be trusted with incremental investments. Be open, honest and transparent about the use of the resources. Pay particular attention to schedule, scope and budget. The people you are asking for financial support sure will.

The primary reason your security program is failing is not your lack of funding. Start developing your plan today. Maybe the executives say that they think there must not be a problem, since they are not hearing from you. By using the data you already have, start to use it to tell your story about the current state of your security program. This information, properly communicated can become the catalyst for increased awareness and funding.

Here are a few ideas to get you started:

  • Monitor the percentage of systems sending their logs as compared to the total number of log sources in use
  • Monitor the percentage of blocked traffic on the firewall versus what that was permitted
  • Monitor the percentage of changes that occur outside the approved change control process
  • Monitor the percentage of findings on your risk register that have remain unchanged over the last quarter


What metrics have you found to be useful when communicating the needs and the effectiveness of your security program?

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords:
6 comment(s)

.GOV zones may not resolve due to DNSSEC problems.

Published: 2013-08-14
Last Updated: 2013-08-14 16:25:39 UTC
by Johannes Ullrich (Version: 1)
2 comment(s)

Update: looks like this has been fixed now. Of course bad cached data may cause this issue to persist for a while.

Currently, many users are reporting that .gov domain names (e.g. fbi.gov) will not resolve. The problem appears to be related to an error in the DNSSEC configuration of the .gov zone.

According to a quick check with dnsviz.net, it appears that there is no DS record for the current .gov KSK deposited with the root zone.

dnsviz.net Screen Shot

(excerpt from: http://dnsviz.net/d/fbi.gov/dnssec/) 

DNSSEC relies on two types of keys each zone uses:

- A "key signing key" (KSK) and
- A "zone signing key" (ZSK)

The KSK  is usually long and its hash is deposited with the parent zone as a "DS" (Digital Signing) record. This KSK is then used to sign shorter ZSKs which are then used to sign the actual records in the zone file. This way, the long key signing key doesn't have to be changed too often, and the DS record with the parent zone doesn't require too frequent updates. On the other hand, most of the "crypto work" is done using shorter ZSKs, which in turns improves DNSSEC performance.

I am guessing that the .gov zone recently rotated it's KSK, but didn't update the corresponding DS record witht he root zone. 

This will affect pretty much all .gov domains as .gov domains have to be signed using DNSSEC. You will only experience problems if your name server (or your ISP's name server) verifies DNSSEC signatures.

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: dnssec gov
2 comment(s)
Diary Archives