Security Ripcord

I mentioned in Gathering Hard Drive Serial Number and Information that I wanted a method to automatically document a hard drive’s information in Linux. I did come across a solution called Automated Image and Restore (AIR) that provides a GUI front-end to DC3DD and DD. I haven’t tested this as I really would prefer a command line utility that provides this functionality (let us know your comments on your experiences with AIR). Also, I thought that I preferred DCFLDD. I actually did until I started developing this script and I discovered some “unwanted functionality” which I will cover at the end of this post.

With all of this in mind, the Forensic Acquisition Information and Drive Data Script (faidds) was born. FAIDDS (available at Google Code) leverages the Python subprocess methods to run parted, hdparm, and sdparm to gather information about a specified hard drive (Python subprocess runs other executables, so MIND your file integrity). Once this information is gathered the hard drive is acquired using either DC3DD (default) or DCFLDD. The start and end times are recorded. All of the acquisition information is written to a log file. The script also generates a hash file associated with the acquired image leveraging the acquisition tool’s hashing functionality.

faidds.py -h

faidds.py [-h] [-D] [-dcfldd] [-m hash0,hash1] [-c size in G (1024*1024*1024)] [-s \"serial number\"] -d \”drive location\”‘
-h: help’
-D: debug information’
-s: user specified serial number. Default is to find serial number in drive info.’
-d: device file to acquire’
-c: size to split file in G (1024*1024*1024)’
-dcfldd: use dcfldd (default: dc3dd)’
-m: list of hash algorithms to use. Comma separated with no spaces. (default: md5)’

Here is how I use the script.

First I locate the hard drive I want to acquire. For this example I will attach a USB thumb drive to my system simulating that I am attaching a hard drive to the system using a write-blocker connected with a USB cable. To detect the newly attached drive I run the “dmesg | tail” command:

cutaway> dmesg | tail
[526855.404692] scsi 21:0:0:0: Direct-Access     LEXAR    JUMPDRIVE SECURE 2000 PQ: 0 ANSI: 0 CCS
[526855.406731] sd 21:0:0:0: Attached scsi generic sg6 type 0
[526855.409391] sd 21:0:0:0: [sdf] 502880 512-byte logical blocks: (257 MB/245 MiB)
[526855.415142] sd 21:0:0:0: [sdf] Write Protect is off
[526855.415152] sd 21:0:0:0: [sdf] Mode Sense: 43 00 00 00
[526855.415159] sd 21:0:0:0: [sdf] Assuming drive cache: write through
[526855.418722] sd 21:0:0:0: [sdf] Assuming drive cache: write through
[526855.418737]  sdf: sdf1
[526855.471513] sd 21:0:0:0: [sdf] Assuming drive cache: write through
[526855.471520] sd 21:0:0:0: [sdf] Attached SCSI disk
cutaway>

As you can see, I attached a 256 MB LEXAR USB thumb drive and it was assigned the device file “sdf”. Next, I move into the directory where I want to acquire the drive image. This could be the local hard drive but more than likely it will be some other media such as an external USB hard drive or a shared drive. To acquire this drive I decided to have it output the MD5 and SHA1 hashes of the drive I am acquiring.

cutaway> sudo python ../faidds/trunk/faidds.py -D -m md5,sha1 -d /dev/sdf
[sudo] password for cutaway:
Enter YES to acquire/dev/sdf: YES
/sbin/parted /dev/sdf print
/sbin/hdparm -I /dev/sdf
/usr/bin/sdparm –inquiry /dev/sdf
_ �Nk
System Time Zone Is: CDT
Start Time: March 18 2012 17:49:36 UTC
Acquisition command: /usr/bin/dc3dd log=./_ �Nk_20120318174936_hash.txt rec=on if=/dev/sdf hash=md5 hash=sha1 of=./_ �Nk_20120318174936.dd
[!!] opening log `./_\001 \205N\024\027k_20120318174936_hash.txt’: Invalid or incomplete multibyte or wide character
Try `/usr/bin/dc3dd –help’ for more information.
dc3dd aborted at 2012-03-18 12:49:36 -0500

Stop Time: March 18 2012 17:49:36 UTC
Traceback (most recent call last):
File “../faidds/trunk/faidds.py”, line 192, in <module>
ONF = open(onf,’w')
IOError: [Errno 84] Invalid or incomplete multibyte or wide character: ‘drive_data__dev_sdf__\x01 \x85N\x14\x17k_20120318174936.txt’
cutaway>

Lucky for me I selected this thumb drive for testing. Apparently, LEXAR did not set up the serial number properly (easily readable). In this case it appears that the device returns serial number information that is “multibyte or wide character.” This situation is not unique for this USB thumb drive and could occur when acquiring older USB and Flash drives. Thus the “user specified serial number” option was born.

cutaway> sudo python ../faidds/trunk/faidds.py -D -m md5,sha1 -d /dev/sdf -s testing
Enter YES to acquire/dev/sdf: YES
/sbin/parted /dev/sdf print
/sbin/hdparm -I /dev/sdf
/usr/bin/sdparm –inquiry /dev/sdf
System Time Zone Is: CDT
Start Time: March 18 2012 18:03:07 UTC
Acquisition command: /usr/bin/dc3dd log=./testing_20120318180307_hash.txt rec=on if=/dev/sdf hash=md5 hash=sha1 of=./testing_20120318180307.dd

dc3dd 7.0.0 started at 2012-03-18 13:03:07 -0500
compiled options:
command line: /usr/bin/dc3dd log=./testing_20120318180307_hash.txt rec=on if=/dev/sdf hash=md5 hash=sha1 of=./testing_20120318180307.dd
device size: 502880 sectors (probed)
sector size: 512 bytes (probed)
257474560 bytes (246 M) copied (100%), 30.2548 s, 8.1 M/s

input results for device `/dev/sdf’:
502880 sectors in
0 bad sectors replaced by zeros
eaa52cfb7b1b37d2b94b8d371e0e47a8 (md5)
602c713c00c9a05c8f0ec76f9c3f2f7581da7edd (sha1)

output results for file `./testing_20120318180307.dd’:
502880 sectors out

dc3dd completed at 2012-03-18 13:03:37 -0500

Stop Time: March 18 2012 18:03:37 UTC
cutaway> ls -al
total 251452
drwx—— 1 cutaway cutaway       328 2012-03-18 13:03 .
drwx—— 1 cutaway cutaway      4096 2012-03-18 12:18 ..
-rwx—— 1 cutaway cutaway      2529 2012-03-18 13:03 drive_data__dev_sdf_testing_20120318180337.txt
-rwx—— 1 cutaway cutaway 257474560 2012-03-18 13:03 testing_20120318180307.dd
-rwx—— 1 cutaway cutaway       643 2012-03-18 13:03 testing_20120318180307_hash.txt
cutaway>

DC3DD provides us with an excellent record of  our acquisition method and the hash values for the acquisition.

cutaway> cat testing_20120318180307_hash.txt

dc3dd 7.0.0 started at 2012-03-18 13:03:07 -0500
compiled options:
command line: /usr/bin/dc3dd log=./testing_20120318180307_hash.txt rec=on if=/dev/sdf hash=md5 hash=sha1 of=./testing_20120318180307.dd
device size: 502880 sectors (probed)
sector size: 512 bytes (probed)
257474560 bytes (246 M) copied (100%), 30.2548 s, 8.1 M/s

input results for device `/dev/sdf’:
502880 sectors in
0 bad sectors replaced by zeros
eaa52cfb7b1b37d2b94b8d371e0e47a8 (md5)
602c713c00c9a05c8f0ec76f9c3f2f7581da7edd (sha1)

output results for file `./testing_20120318180307.dd’:
502880 sectors out

dc3dd completed at 2012-03-18 13:03:37 -0500

cutaway>

Of course, if you prefer (as I thought I did) you could use DCFLDD. The command line options are the same with the exception that the user needs to include the “-dcfldd” option.

cutaway> sudo python ../faidds/trunk/faidds.py -D -m md5,sha1 -d /dev/sdf -s testing -dcfldd
Enter YES to acquire/dev/sdf: YES
/sbin/parted /dev/sdf print
/sbin/hdparm -I /dev/sdf
/usr/bin/sdparm –inquiry /dev/sdf
System Time Zone Is: CDT
Start Time: March 18 2012 18:07:00 UTC
Acquisition command: /usr/bin/dcfldd hashlog=./testing_20120318180700_hash.txt conv=noerror,sync if=/dev/sdf of=./testing_20120318180700.dd
7680 blocks (240Mb) written.
7857+1 records in
7858+0 records out
Stop Time: March 18 2012 18:07:31 UTC
cutaway>

You can run this command in the same directory as the other acquisition because the output files are all time stamped. The hashlog file for DCFLDD is not as robust as DC3DD, but don’t worry, I capture similar information in the drive acquisition data file.

cutaway> ls -al
total 502913
drwx—— 1 cutaway cutaway       328 2012-03-18 13:07 .
drwx—— 1 cutaway cutaway      4096 2012-03-18 12:18 ..
-rwx—— 1 cutaway cutaway      2529 2012-03-18 13:03 drive_data__dev_sdf_testing_20120318180337.txt
-rwx—— 1 cutaway cutaway      2519 2012-03-18 13:07 drive_data__dev_sdf_testing_20120318180731.txt
-rwx—— 1 cutaway cutaway 257474560 2012-03-18 13:03 testing_20120318180307.dd
-rwx—— 1 cutaway cutaway       643 2012-03-18 13:03 testing_20120318180307_hash.txt
-rwx—— 1 cutaway cutaway 257490944 2012-03-18 13:07 testing_20120318180700.dd
-rwx—— 1 cutaway cutaway        46 2012-03-18 13:07 testing_20120318180700_hash.txt
cutaway> cat testing_20120318180700_hash.txt
Total (md5): eaa52cfb7b1b37d2b94b8d371e0e47a8
cutaway> tail drive_data__dev_sdf_testing_20120318180731.txt
Integrity word not set (found 0x7c3c, expected 0x91a5)

/usr/bin/sdparm –inquiry /dev/sdf
/dev/sdf: LEXAR     JUMPDRIVE SECURE  2000

System Time Zone Is:CDT

Start Time: March 18 2012 18:07:00UTC
Acquisition command: /usr/bin/dcfldd hashlog=./testing_20120318180700_hash.txt conv=noerror,sync if=/dev/sdf of=./testing_20120318180700.dd
Stop Time: March 18 2012 18:07:31UTC
cutaway>

Okay, who sees what I see? Notice anything different? What about the MD5 sums recorded for the captured data (the files with the “.dd” extension)? They are the same: eaa52cfb7b1b37d2b94b8d371e0e47a8. Hmm. Okay, what about the file sizes? The image created by DC3DD is 257474560 and the image created by DCFLDD is 257490944. Interesting. Let’s run the MD5SUM command against these files.

cutaway> md5sum testing_20120318180307.dd testing_20120318180700.dd
eaa52cfb7b1b37d2b94b8d371e0e47a8  testing_20120318180307.dd
a3aa87600be5559117c7450b5475cd0c  testing_20120318180700.dd
cutaway>

Wait a minute!!!! That is not right. And it is not the same hash value recorded by DCFLDD during acquisition. What could be the issue here? Could the second image be corrupted? Let’s check their similarity using SSDEEP (space added in the following output to prevent the stupid emoticon).

cutaway> ssdeep testing_20120318180307.dd testing_20120318180700.dd
ssdeep,1.1–blocksize:hash:hash,filename
6291456:Io/uDcy8TiPJY+Mj7C6llllllllllllaG3KfJh8rliaS6H: DOcrTiPJY+Mj7CGKfJolNH,”/media/InG-Storage/Research/Dev/data_acquisition_test/testing_20120318180307.dd”
6291456:Io/uDcy8TiPJY+Mj7C6llllllllllllaG3KfJh8rliaS6: DOcrTiPJY+Mj7CGKfJolN,”/media/InG-Storage/Research/Dev/data_acquisition_test/testing_20120318180700.dd”
cutaway>

These files appear to be exactly the same except for something at the end of the file. What could that be?

Ahh, it does appear to be exactly the same except that there are 16,384 null bytes attached to the end of the file created by DCFLDD. Well, we could remove those if we REALLY needed to. I am guessing that this was caused by the fact that I used the “conv=noerror,sync” option to handle bad blocks during acquisition. To test I simply ran the command by itself without this option.

cutaway> sudo /usr/bin/dcfldd hashlog=./testing_20120318180700_hash_noerror.txt if=/dev/sdf of=./testing_20120318180700_noerror.dd
7680 blocks (240Mb) written.
7857+1 records in
7857+1 records out
cutaway> ls -al
total 754653
drwx—— 1 cutaway cutaway      4096 2012-03-18 13:40 .
drwx—— 1 cutaway cutaway      4096 2012-03-18 12:18 ..
-rwx—— 1 cutaway cutaway      2529 2012-03-18 13:03 drive_data__dev_sdf_testing_20120318180337.txt
-rwx—— 1 cutaway cutaway      2519 2012-03-18 13:07 drive_data__dev_sdf_testing_20120318180731.txt
-rwx—— 1 cutaway cutaway    300656 2012-03-18 13:27 oketa_image_diff.png
-rwx—— 1 cutaway cutaway 257474560 2012-03-18 13:03 testing_20120318180307.dd
-rwx—— 1 cutaway cutaway       643 2012-03-18 13:03 testing_20120318180307_hash.txt
-rwx—— 1 cutaway cutaway 257490944 2012-03-18 13:07 testing_20120318180700.dd
-rwx—— 1 cutaway cutaway        46 2012-03-18 13:40 testing_20120318180700_hash_noerror.txt
-rwx—— 1 cutaway cutaway        46 2012-03-18 13:07 testing_20120318180700_hash.txt
-rwx—— 1 cutaway cutaway 257474560 2012-03-18 13:40 testing_20120318180700_noerror.dd
cutaway> md5sum testing_20120318180307.dd testing_20120318180700.dd testing_20120318180700_noerror.dd
eaa52cfb7b1b37d2b94b8d371e0e47a8  testing_20120318180307.dd
a3aa87600be5559117c7450b5475cd0c  testing_20120318180700.dd
eaa52cfb7b1b37d2b94b8d371e0e47a8  testing_20120318180700_noerror.dd
cutaway>

Yes, that is it. DCFLDD adds extra bytes to account for the rest of the file out to the end of the last block. The options that tells DC3DD to manage bad blocks is the “rec=on” option. As I have this selected for the DC3DD command it appears that it does not add these additional null bytes to the end of the file.

In other words, “Know Your Tools.”

Go forth and do good things,

Don C. Weber

My eight year old son has been asking to carry a knife. I have been wondering about knife safety and what it will take for me to let him carry a knife around.

When I think about it the knife has been a right of passage for little boys since the beginning of time. Banning pocket knives from school (as far as I know) is a very resent change to society. Banning them actually hurts our youth (in my opinion) because it deprives youth of learning opportunities that teach them responsibility and the consequences of action. Protecting people and kids from individuals that may decide to cut them with a knife is ludicrous because if they want to cut you they will bring a knife, permission or not.

Of course, I want my son to be safe. Therefore, I am going to set down some rules. This might not be the same method as our predecessors but when I think about it, my son is not going to be presented with the same “working” responsibilities as the youth or our predecessors.

My problem is that I do not have a good “knife learning skills” from my youth. Actually, I don’t even remember when I got my first pocket knife. I do, however, remember what was expected of me as a Marine. I was presented with very specific rules of weapon handling which were a requirement before I was permitted to enter a house with my platoon and a live weapon. These were the five rules of weapon handling I was responsible to know and demonstrate.

Rules of Weapon Handling

1. Treat every weapon as loaded, even after you have ensured that it is unloaded.
2. Never let your muzzle cover anything that you are not willing to destroy.
3. Keep your finger off the trigger and outside the trigger guard until you are up on target and ready to shoot.
4. Be sure of your target and consider the background.

Working off of these I have developed the rules of knife handling.

Rules of Knife Handling

1. Treat all knives as sharp even if you know that it is not sharp.
2. Never touch anything with your knife unless you want it to be cut.
3. Keep your knife folded or in its sheath until you are ready to use it for cutting.
4. Always cut away from yourself and other people.
5. When handing a knife to another person point the blade and tip away from yourself and do not let go until they say “Thank you.”

Rules are rules, but action is action. I can talk about rules all day, but unless you have trained to understand how to implement the rules there will be no learning. To help with his understanding of the rules I have decided to specify one of his plastic knives as an “actual knife.” He will demonstrate the following with the plastic knife first. Once I am satisfied he will move to a real knife and demonstrate everything again. I am hoping to show him that it is important to learn the rules and then that it is important to remember the rules.

Knife Tasks

1. Say, write, explain, and demonstrate all Knife Handling Rules.
2. Use a knife to sharpen a pencil.
3. Show how to sharpen a knife using a Spyderco Knife Sharpener.

Hopefully this works and provides the “real world” learning experience the youths of our past gained through actual implementation. Please let me know if you have any other tasks that might be helpful to learn these rules and promote knife handling skills.

Go forth and do good things,

Don C. Weber

When acquiring data I am always worried about writing down a hard drive’s part number and serial number incorrectly. Sometimes the print is so small that an “8″ will look like a “B” or maybe the information has been obscured by other markings, stickers, or time. Some acquisition techniques such as HELIX Pro Version 3 and FTK Imager provide this information in their drive acquisition information file and I don’t need to worry about it. But HELIX Pro doesn’t really work for me any more and I find myself booting the system using a different Linux Live CD before falling back to HELIX, if necessary.

My favorite Live CD for data acquisition is Backtrack version 4 or 5 because it is also a part of my assessment toolkit. BT4/5 has a forensic boot mode which does not use the local drive’s SWAP partition and does not automatically mount any internal or external drives. Since it is actively maintain I can usually use it to boot any system as long as that system has a DVD drive. It would be nice to have a CD-ROM version of BT5 for systems that do not have DVD drives or the ability to boot to USB. (Yes, those types of systems are still out there.)

Unfortunately BT does not provide a scripted ability to gather information about an attached drive. Software that does provide this information does so (as far as I can tell) by using C code to query the kernel for a drive’s information. If I had time to sit down and write the code I would, but I would rather have a simple way to use system commands to provide me with this information. This is where “hdparm” and “sdparm” come into the picture. Both of these commands are designed to query a hard drive and provide various types of information.

The following is the logical process that I use to gather the information I need about an attached hard drive.

The “dmesg” command provides information about any drive connected to the system. I use this command to show me where the operating system is attaching a new drive I have plugged into the system via USB or Firewire (directly or via a write blocker). In the following case the operating system is allowing access to the Western Digital hard drive via the “/dev/sdb” device file. This means that the system is treating the drive as a SCSI device. It also means (generally) that the “/dev/sda” device has already been taken by another SCSI hard drive.

cutaway@smash:~$ dmesg | tail -17
[  383.584108] usb 1-2: new high speed USB device number 7 using ehci_hcd
[  383.719545] scsi4 : usb-storage 1-2:1.0
[  383.722070] input: Western Digital  External HDD     as /devices/pci0000:00/0000:00:1d.7/usb1/1-2/1-2:1.1/input/input12
[  383.722264] generic-usb 0003:1058:0705.0005: input,hidraw3: USB HID v1.10 Device [Western Digital  External HDD    ] on usb-0000:00:1d.7-2/input1
[  384.717116] scsi 4:0:0:0: Direct-Access     WD       3200BEV External 1.75 PQ: 0 ANSI: 0
[  384.736576] sd 4:0:0:0: Attached scsi generic sg2 type 0
[  384.738391] sd 4:0:0:0: [sdb] 625142448 512-byte logical blocks: (320 GB/298 GiB)
[  384.738961] sd 4:0:0:0: [sdb] Write Protect is off
[  384.738969] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00
[  384.740263] sd 4:0:0:0: [sdb] No Caching mode page present
[  384.740271] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[  384.745318] sd 4:0:0:0: [sdb] No Caching mode page present
[  384.745326] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[  384.798801]  sdb: sdb1
[  384.801173] sd 4:0:0:0: [sdb] No Caching mode page present
[  384.801181] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[  384.801188] sd 4:0:0:0: [sdb] Attached SCSI disk

Notice that the “dmesg” program provides manufacturer name, part number, and disk size information for this newly attached drive. The information that is missing is the drive’s serial number. To gather serial number we will need another method.

Linux operating systems usually come with the “hdparm” program as a core utility. This program is designed to “get/set SATA/IDE device parameters” from hard drives attached to the system. The following is the information this program provides pertaining to a locally attached hard drive. By locally attached I mean that this hard drive is directly connected to the system’s mother board.

cutaway@smash:~$ sudo hdparm -i /dev/sda

/dev/sda:

Model=ST9250827AS, FwRev=3.AAA, SerialNo=5RG08HAJ
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes:  pio0 pio1 pio2 pio3 pio4
DMA modes:  mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: unknown setting WriteCache=enabled
Drive conforms to: unknown:  ATA/ATAPI-4,5,6,7

* signifies the current active mode

As you can see, by using the “hdparm” command, we now know the hard drive’s manufacturer part and serial number. Using the “-I” option actually gives us more information which could be useful to document.

cutaway@smash:~$ sudo !!
sudo hdparm -I /dev/sda
[sudo] password for cutaway:

/dev/sda:

ATA device, with non-removable media
Model Number:       ST9250827AS
Serial Number:      5RG08HAJ
Firmware Revision:  3.AAA
Transport:          Serial
Standards:
Used: unknown (minor revision code 0×0029) cutaway@smash:~$ sudo sdparm -C capacity /dev/sdb
/dev/sdb: WD        3200BEV External  1.75
blocks: 625142448
block_length: 512
capacity_mib: 305245.3

Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical         max     current
cylinders       16383   16383
heads           16      16
sectors/track   63      63
–
CHS current addressable sectors:   16514064
LBA    user addressable sectors:  268435455
LBA48  user addressable sectors:  488397168
Logical  Sector size:                   512 bytes
Physical Sector size:                   512 bytes
device size with M = 1024*1024:      238475 MBytes
device size with M = 1000*1000:      250059 MBytes (250 GB)
cache/buffer size  = 8192 KBytes
Nominal Media Rotation Rate: 5400
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec’d by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16  Current = 16
Advanced power management level: 254
Recommended acoustic management value: 254, current value: 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
Enabled Supported:
*    SMART feature set
Security Mode feature set
*    Power Management feature set
*    Write cache
*    Look-ahead
Host Protected Area feature set
*    WRITE_BUFFER command
*    READ_BUFFER command
*    DOWNLOAD_MICROCODE
*    Advanced Power Management feature set
SET_MAX security extension
*    48-bit Address feature set
*    Device Configuration Overlay feature set
*    Mandatory FLUSH_CACHE
*    FLUSH_CACHE_EXT
*    SMART error logging
*    SMART self-test
*    64-bit World wide name
*    IDLE_IMMEDIATE with UNLOAD
Write-Read-Verify feature set
*    WRITE_UNCORRECTABLE_EXT command
*    {READ,WRITE}_DMA_EXT_GPL commands
*    Gen1 signaling speed (1.5Gb/s)
*    Gen2 signaling speed (3.0Gb/s)
*    Native Command Queueing (NCQ)
*    Phy event counters
*    Device-initiated interface power management
*    Software settings preservation
*    SMART Command Transport (SCT) feature set
Security:
Master password revision code = 65534
supported
not     enabled
not     locked
frozen
not     expired: security count
not     supported: enhanced erase
Logical Unit WWN Device Identifier: 5000c5000990cb81
NAA             : 5
IEEE OUI        : 000c50
Unique ID       : 00990cb81
Checksum: correct

It would be nice if this command also provided the manufacturer name for the drive as the “dmesg” command did, but it is not completely necessary. A quick Google search shows that the Model Number for this drive is related to a Seagate drive.

Unfortunately we run into a problem with the “hdparm” command. This program does not work for drives attached to a system’s USB or Firewire ports. I am not exactly sure why this occurs, but it does have to do with the fact that drives attached via USB or Firewire do not return drive information when the kernel makes a “HDIO_GET_IDENTITY” request. Here is an example.

cutaway@smash:~$ sudo hdparm -i /dev/sdb
/dev/sdb:
HDIO_GET_IDENTITY failed: Invalid argument

To gather similar information we need to use the “sdparm” command. This command allows us to “access SCSI modes pages; read VPD pages; send simple SCSI commands” for a SCSI-based hard drive. To get a hard drive’s serial number using “sdparm” we need to directly query the VPD “page” that contains this information. Sometimes the “–inquiry” command will provide this information and sometimes it will not. By querying the “sn” page directly we can insure we get the hard drive’s part number and serial number with a single command.

cutaway@smash:~$ sudo sdparm –page=sn  /dev/sdb
/dev/sdb: WD        3200BEV External  1.75
Unit serial number VPD page:
WD-WXE308NF5233

If we need information pertaining to the drive’s capacity we will need to run an actual SCSI command to query the data from the drive. For this we will use the “-C” option and provide it the parameter “capacity”.

cutaway@smash:~$ sudo sdparm -C capacity /dev/sdb
/dev/sdb: WD        3200BEV External  1.75
blocks: 625142448
block_length: 512
capacity_mib: 305245.3

Be aware that the information provided by this command is dependent on how the drive responds to information requests. Most main stream hard drives and manufacturers will return good data. Some manufacturers and drive types (such as Flash drives) may not return the information you expect or require. Therefore, your mileage may vary.

This is all well and good, but as you will find out the “sdparm” program is not installed as a core utility on most Linux distributions. It has to be specifically installed. For Live CDs you may or may not be provided with this utility and this holds true for Backtrack as well. At least it did. The latest release, Backtrack 5r2 does include the “sdparm” program for the specific purpose of gathering this information from both the hard drive being aquired and the destination hard drive.

I have considered writing a python script that gathers this information. My first attempt queried “HDIO_GET_IDENTITY” and worked for local drives but not external drives. Thus leading me down this rabbit hole. I guess I will have to leverage Python’s subprocess capabilities to use the “sdparm” command to gather this information reliably. I was holding off on this script until “sdparm” was included in BT5r2. Now that it is released I guess I need to get busy. Check back soon.

Go forth and do good things,

Don C. Weber

Once again I find myself pointing to tweets by Richard Bejtlich. This time it was actually a retweet of Hogfly who runs the Forensic Incident Response blog. Hogfly recently pointed out an article in Aviation Week titled “China’s Role In JSF’s Spiraling Costs“. This article demonstrates the actual cost for a specific project associated with industrial espionage, nation state infiltration of critical infrastructures, and general criminal activity. A blog post by Richard Stiennon, titled “The first thing we do, is hack all the lawyers“, also showed how these same threat agents are leveraging third-party relationships to impact specific projects. I like these articles because they provide specific numbers relating to cost of impact. “…$40 billion…” “…costs at tens of billions of dollars…”

These two examples show both ends of the information technology (IT) spectrum. The defense contractors responsible for the Joint Strike Fighter (JSF) should have had decent security in place to include security testing and monitoring. The majority of law offices will not have security practices that met these standards. In most cases the IT security considerations employed by law offices will actually fall at the other end of the spectrum: operating without significant information security considerations. But, in the end the result of both cases was the same.

I believe that it is pretty safe to conclude that the threat agents responsible for these and similar breaches did not just attach to the networks and start exfiltrating data. Rather, these successful attacks very likely required the use of a combination of known and discovered exploits to gain access, persistent, and propagate within these networks. It is also logical to conclude that their activities generated system and network-based artifacts that outlined their activity, even if that activity mimicked normal and authorized operational activity. Understanding these system and network-based artifacts is an important step to preventing and detecting attempts to infiltrate a network. Another key component is detecting exploitable vulnerabilities before they can be leveraged against the resources in a network.

Early detection is why security professionals encourage network mapping, vulnerability scanning, penetration testing, research and development, and monitoring. Security teams that provide penetration testing services should have an understanding of the techniques applied by current and past threat agents. They should also have a keen eye for leveraging the resources and services to their advantage to demonstrate the ingenuity attackers will implement after the initial compromise of a network. Tom Liston of InGuardians has a plethora of stories that demonstrate how he circumvented good security implementations using common sense and experience with a wide variety of technologies. The result of such penetration testing will generate system and network-based artifacts that can be leveraged to train a organization’s security and information technology administrators to detect and identify similar activity.

Research into technologies deployed in test networks and off-line implementations provide valuable information without impacting an organization’s business assets. It also reduces the cost of effort by providing beneficial information to all businesses employing a technology rather than a single instance where the organization hordes the information to prevent distribution to threat agents. When the results of research are presented to security professionals, IT administrators, IT management, and corporate executives all of these parties benefit from the knowledge and are able to leverage the information to assess and use it to improve their security and effectiveness of their business assets.

While writing this Richard tweeted (if you are not following him then you should stop reading and take care of it right now) to additional insights that are relative to my point. “Exploits aren’t as important as some think. I worked cases where not even active intruders on a corp network inspired appropriate concern!” and “Tech people should consider that IT and sec are one of many factors that mgt weighs. I fear it’s underweighted, but it’s not tech’s call.” Both of these are very true and have played a significant role in the persistence of many breaches including those pointed out at the beginning of this post. I too have experienced active intrusions with manual (rather than automated) system interactions, supported by specific system and network-based artifacts, that were downplayed and eventually treated as a malware infestation.  Even the experiences of multiple incident response professionals was not enough to change the opinions of the administrations, IT managers, and executives of these organizations. This attitude was born out of inexperience in the types of activities associated with a network’s initial compromise, persistence of the compromise, propagation to additional resources, and exfiltration of data.  Experience that might have been achieved by monitoring the data produced by penetration testing. Of course, it also requires a mind that is not specifically limited by business restrictions and is open to new possibilities that are born out of sublime and criminal research into information technologies.

Go forth and do good things,

Don C. Weber

It is more than obvious now that my ShmooCon talk, Looking into the Eye of the Meter, was canceled.  Kelly Jackson Higgins in her  Dark Reading article Researchers Postpone Release Of Free Smart Meter Security Testing Tool did a good job describing what InGuardians and I can say about the topic. But even one week later there is not much news or discussion about this. Robert Former wrote an interesting blog post, Security researchers: Spawn of Satan, Necessary Evil, or Security Salvation?, about his opinion of the event. I liked it, but I am biased (Free SMACK!! Indeed.). Other than that the Smart Grid lists and media feeds have been very quiet about the whole issue. It seems to be turning into the little meter talk that faded into the night. I cannot say if this is the goal of the vendor that asked us to pull the talk, but I can say that it was my fear when they asked us to pull it from the ShmooCon venue.

I cannot provide any more details about the vendor’s issues until we speak with the vendor and get some things cleared up. I want to talk a bit about my opinions on why we decided to pull the talk at the request of a vendor. Of course, these opinions are my own and do not reflect the official opinions of InGuardians, Inc.

I wrote the Smart Meter presentation to educate. I wanted to educate security professionals that will be dealing with the fast proliferation of embedded devices. I wanted to show that following a good testing methodology and implementing the hardware analysis basics well could lead to findings that will strengthen future development and implementation of a product and associated services. ShmooCon might be considered a “hacker” conference, but the people attending this event are security professionals and researchers that will be providing guidance to information technology deployments throughout the world. By educating these people I am not teaching the public how to hack the Smart Grid, I am informing them on the basics for security assessments and providing them with the skills to pass on to their teams and organizations.

In addition to security professionals I was hoping to educate the Smart Grid-related vendors and implementors. The Smart Grid industry has come a long way in the last three years. Most of the vendors and utilities have been listening to security professionals (internal and external) and addressing issues as quickly as they can. As with all industries there are individuals and even teams of people who are afraid of information disclosure and security tools. Basically, the Smart Grid industry, although moving as quickly as they can, are still new to the positive impacts that research, education, and assessment tools can provide to their efforts. They are not familiar with Wright’s Law: “Security will not get better until tools for practical exploration of the attack surface are made available.” I believe that Richard Bejtlich put it very well in a tweet posted as I was arriving in Washington, D.C.: “Proponents argue that releasing weaponized exploits will have long term positive impact; critics worry about short/med term negative impact.” Although I was not intending on releasing a “weaponized exploit” the statement hits very close to home for all security-related research and tools.

InGuardians has experienced the effects of security-related misconceptions within the Smart Grid arena. In fact, I almost didn’t get hired at InGuardians because of the fear, uncertainty, and doubt raised by the Associated Press article: ‘Smart’ meters have security holes. The title alone was enough to raise a stir within the Smart Grid industry not to mention the fact that the reporter left out many of the positive statements made by Joshua Wright. I now have a good understanding of how Josh might have been feeling at this time. I respect him immensely for his continued courage and desire to educate.

Because of Josh’s, InGuardians’, and other experiences, I approached presenting a Smart Meter talk at ShmooCon very carefully. I first had to sell it to InGuardians. I provided our team with an outline of my presentation idea with specific emphasis on the mitigations already employed by many meter vendors and third-party solutions. Mike Poor (yes, Tom Liston, it is Mike Poor’s fault) especially liked the idea as our approach would replace Fear, Uncertainty, and Doubt with Understanding, Certainty, and Knowledge (TM, I think. ). With InGuardians’ approval I had to sell the optical toolkit (the actual basis for my presentation) and the presentation content to the Smart Grid industry. I did this by providing access to the toolkit to our contacts at as many Smart Grid vendors as I could. These people were provided access to the toolkit on January 8, 2012 (approximately, I would have to double check for accuracy). I received immediate positive feedback from the list. Robert Former of Itron provided me with an understanding of the impacts of the tool to Advanced Metering Infrastructure (AMI) solutions and helped me understand implementable mitigations. Ed Beroset of Elster provided me with code modifications to make the tool more stable and usable by meter research and development teams. Several other individual, who have asked not to be named, provided us with their thoughts on the tool as well. As we did not receive any complaints about the release of the tool we continued with developing the presentation. After intense internal and legal review, I provided a draft presentation to the same group on the Monday before the presentation. This gave the group at least five days to provide us with their input about the content. The same individuals that provided me input about the tool also provided me input about the content of the presentation. All of the input was positive and really helped tighten up the concepts and content of the presentation.

We did not hear any objections to the toolkit or presentation until the first day of ShmooCon. One of the vendors on our list contacted us with generic objections to the content and venue of the presentation. As we had almost two full days to work through their objections InGuardians began a concerted effort to identify and address their issues so that the information could be presented and the toolkit released. I am very proud of the InGuardians team and the professionalism we displayed during these discussions. There were times when I wanted to call it and move forward as planned, but cooler heads prevailed and we adhered to the request of the vendor. And looking back, keeping a cool head at these times is the key to responsible disclosure, education, and maintaining positive relationships with our vendors and clients. InGuardians strives to be an organization of thought leaders and information security professionals that can be turned to for guidance and expertise. Of course we make mistakes, but we are quick to own them and address them as swiftly and professionally as possible. With these ideals in mind we could not move forward with the tool release and presentation until all parties were comfortable. It could be said that trying to please everybody is a recipe for disaster, but we cannot ignore direct requests for additional information. Because in the long run it provides each party with a better understanding of the positive and negative impacts of publicly releasing information and toolkits relating to specific products or solutions.

The result of all of this is that my Smart Meter presentation and the release of the Smart Meter Assessment Communication Kit (SMACK) has been delayed until further notice. I have already received an offer to give the presentation at the next Smart Grid Security Summit in Atlanta. I am hoping we can work through the vendor issues before they have to fill the slot with another presentation. I am also hoping to present this at another information security-related conference such as Black Hat USA and/or DefCon so that this information can educate the future security professionals that will be moving into Smart Grid-related positions or conducting authorized research on Smart Grid solutions. Of course this requires that the presentation is accepted for these venues.

I am also hoping the the vendor will come forward with a statement that they requested us to hold the presentation and release of the toolkit and InGuardians worked with them in good faith. This would show the public that they have a concern about the information being provided and that all parties are working to address the issues and concerns before moving forward. This would have a positive impact on the Smart Grid industry and security researchers.It would demonstrate that we are working as a team and not playing a fancy political game to suppress information or teach criminals how to hack the Smart Grid.

Go forth and do good things,

Don C. Weber

All of the opinions expressed in this blog post are mine alone. They do not represent the opinions of my employer, InGuardians, Inc.

When I started working for IBM’s Emergency Response Team I was a little intimidated about walking into a client’s environment and quickly providing incident response leadership. Luckily I was trained by Chris Pogue and Harlan Carvey to consider three things when I got on-site:

• What are you trying to answer?
• What data do you need to answer it?
• How do you get that data?

Obviously the first question is the hardest to answer (although, perhaps, not the most challenging). I often find myself having Car Talk-style conversations where you talk about the situation for an hour or two and then somebody says something to the effect of: “Oh, yeah. And we have this service running over here.”

It always amazes me how similar many of the security issues are across companies with decent security programs and teams. The security teams work hard to identify situations before they happen but incidents still occur and the teams struggle with pulling all of the information together. Disciplined incident response comes with experience. Not just experience within the security team, but experience throughout the organization. Most companies have information technology (IT) divisions with silo-ed experience (I am not saying it is bad, just natural). The web application developers and administrators know the web applications and web logs. Database administrators know the database logs, how verbose they are, how to retrieve them, and what can be turned on and off. Network administrators know what is logging where, what has been disabled, what can be turned up. Etc, Etc. Of course there is some overlap, but this example demonstrates that a lot of internal interaction may be required to initiate an incident response.

This silo-ing can complicate things but it is often manageable. The situations that prove to be more challenging are those that involve external services and equipment. Security teams are not usually consulted when service level agreements with external entities are formulated. Any third-party organization worth their salt will be prepared to provide information and action during critical times. But experience is the only way to determine the proper channels and methods of request to initiate the actions necessary to facilitate an efficient incident response. Acquiring data, removing services, increasing logging, and physically accessing a facility are just a few of the things that could increase the gap between incident identification and response.

Another thing that comes into play during an active incident response is the review of unique data types. I have assisted in several instances where an incident involved a web application running on an Apache server. The Apache web logs did not include any POST information which may have provided artifacts relating to the incident. As these web logs were the primary method for detecting anomalies the security team quickly realized that with the default configuration they may have been missing a few things. Digging a little deeper by including web application administrators and developers additional logs were identified. In a recent case the development team used Apache log4j to produce excellent activity information for debugging. As it did not introduce a performance hit to the server the developers just left the debugging code alone. The end result was a detailed log of the web server activity. The only real hick-up was that each entry was undocumented and multi-lined making it difficult to review by common automated processes. But, in the end, very helpful.

So, again, we come back around to the same incident response-related conclusion: Preparation is KEY. Understanding how things interact and who is involved is critical to reducing the time involved during each step of an incident response. But where to start with preparation? The results of an actual incident or a penetration test provide excellent examples and supporting data. Incident response scenarios are also very helpful but can be difficult to design and get everybody involved. To be honest, I have been a big advocate of “incident response scenarios” and I have told many people to develop them. But, looking back, I realize how hard it is for an organization to do this. Heck, it was hard for me when I was specifically thinking about and devoting time to developing a good incident response scenario. Therefore I am going to change my future recommendations from  developing incident response scenarios to performing system walk-throughs.

I made this decision when I found myself leaning back in a chair, looking at a white-boarded diagram of a system (by this I mean a group of resources combined for a specific purpose), and trying to determine what we needed to understand what might have happened during an incident. It was excellent because I also found myself and the security team asking questions to which we did not have immediate answers. I also found myself thinking about how I would have accomplished a specific set of actions relating to the incident. Coming up with these possibilities lead me to asking additional questions and identifying other resources-of-concern and data that could be used to identify useful network and system artifacts.

Therefore, my recommendation is that security teams periodically perform a system walk-through for various IT implementations in their organization. See how systems walk-throughs work and let us know your experiences. Pick one thing at a time when you start and see where it takes you. Focus on the things that will provide you information about a specific activity. Brain-storm situations and talk about the system and network-based artifacts that would be helpful. Folllow up on these ideas and pull in personnel to provide additional information when necessary. This will increase their experience and begin the collaboration process that may prove vitally important in future incidents. I also believe that these interactions will help identify risks, weaknesses, and vulnerabilities that can be easily addressed and increase the overall security of the organization.

Go forth and do good things,

Don C. Weber

Mentoring can be a powerful learning tool for learning specific topics. I have been thinking about mentoring a little bit because I have often found myself thinking that a mentor would be beneficial to my technological and managerial growth.  From my experiences I have determined there are a few requirements to setting up a good mentoring situation. Now, I am not a professional mentor, so, your mileage may vary.

• Focus: a broad range of mentoring subjects do not really work. A mentoring experience should be focused on a specific area.
• Time: both mentor and mentee must have time and inclination for the mentoring experience. Mentoring requires consistent meetings and reviews.
• Experience: A mentor must have knowledge of the subject and mentoring. A mentee must be able to learn the subject and be willing to branch out without encouragement.
• Desire: Both parties need to have a strong desire to participate from the beginning to the end of the mentoring experience.
• End State: both mentor and mentee must have an understanding of when the mentoring experience will end.  This may be after a specific set of goals is reached or a after a specific time period.

Personally, I don’t think that a blossoming Information Technology (IT) Security professional needs mentoring outside of the educational practices implemented by their place of employment. But that is the key: place of employment. Without a job it is difficult to implement the requirements that I listed above. Obviously this means that my list should include the additional requirement of: a job. Of course, a job is generally why a blossoming IT Security professional wants to enter into a mentoring experience.

How do people attempting to enter the IT Security profession get past this gap? My thoughts: effort, tenacity, and the will to teach. A well rounded IT Security professional starts by knowing a lot of things. They slowly, via experience, move to knowing a lot about a lot of things and eventually realize that they do not know and have not done everything. Once they realize they do not know everything they accept the fact that they will be learning during their whole career. I also believe that continuous effort and vocalism are requirements for becoming a well-rounded IT Security professional. Not only does this get you noticed by your peers, it expresses confidence to other administrators and managers.

As IT Security professionals mature they tend to filter into specific areas of focus. This usually means that the influential people in their lives become more narrow and they start to enter into good peer-mentoring relationships. By “peer-mentoring” I mean that each person grows from the other’s experiences. They drive each other to dig deeper and accomplish more. Eventually, people start developing other interests and the “peer-mentoring” relationships shift. But the excellent thing is that, generally, the previous relationships (business or friend) remain strong and continue throughout the years. At some point, interests will diverge again and collaboration will continue.

So, if you are just getting into IT Security or attempting to transition to a new focus area, do not get stifled or discouraged by the lack of mentoring opportunities. Rather, put yourself out there. Start working on personal projects. Tell people about your experiences, failures and success (because BOTH are important to the learning process). Do not be discouraged by critical feed back and have fun even if the subject is hard from start to finish. Remember, experience comes with time and effort. Learning the hard way helps people understand the easy and efficient way. In the end, people will notice and you will have achieved your goal.

Go forth and do good things,

Don C. Weber

There are several reasons that I am drawn to IT security and incident response.

• The discovery of what occurred.
• Protecting a business and its employees from people doing them harm.
• The need for a breadth and depth of knowledge in many areas.

When I was but a young security professional I always wanted to actively go head to head with a malicious hacker.  Last month, I finally got my chance.

Tom Liston (OMG, he has a Wikipedia page!?!) and myself, of InGuardians, came to our client’s site and integrated ourselves with the other security team members already on-site.  Our addition rounded out the team with a good cross-section of skill sets and experiences.  Perfect for what we were going to experience in the next few days.

By the time Tom and I arrived on-site the incident response team understood that the client’s website was being modified to serve malware to its visitors but they did know know how the modifications were being accomplished.  They had already start getting resources in place to provide data that would get us answers our questions.

• Snapshots of the dynamic websites were being saved to a strategic location.
• Web logs were configured to log centrally instead of locally.
• Full network packet captures were configured and stored in another location the incident responders could easily access.
• A method for remotely conducting data analysis and data acquisition was implemented.

Although I won’t say that I always ask for these things during an incident response, I will say that these are usually some of the recommendations that are made at the end of an engagement.  The reason these technologies are valuable is because they provide responders with the system and network-based artifacts that can be used to make quick decisions.

The response effort started normally.  We used our time to become familiar with the environment, located compromised webpages, and tried to piece together the initial compromise vector, persistence mechanisms, and propagation techniques being utilized by the attacker.  During this time we were able to devise methods for quickly locating anomalous activity within the information provided by the weblogs, packet captures, and file differences.  Analysis of systems did not detect anything significant so the team believed that the compromise was limited to the modification of dynamic web pages.

We quickly came to realize that the attackers had been modifying files for quite a while.  The specific code that provided them their initial access was eluding us and we made various recommendations to reduce the number of blatantly vulnerable web applications.  Our analysis identified various obfuscated PHP web administration tools (such as the web shell WSO and Web-based file manager webadmin.php) that the attackers were using to modify files and stomp the file’s metadata.  The combination of all of these things made timeline analysis very difficult and less fruitful than I am use to during active incidents.

This type of activity is fairly normal during incident response and we were starting to get to the point where our team was just going through the motions of detecting modifications and addressing them as quickly as possible.  While this was happening the systems and website administrators worked on individual sites and servers to close vulnerabilities (no small task, indeed).  These websites are the primary business of this client and each of the affected web applications and their servers had to be left online during the attack.  In other words, it was cost effective for them to keep us chasing the bad guys and to keep the sites alive despite the attack.

And then, we had contact with the enemy.

Tom and I had just sat down for our last day on-site.  All of our team had their systems up and running and we were going through our usual motions.  I had just sat down with my coffee when the client’s security manager walked in and told us that one of their primary sites was being blocked due to malicious code.  The only thing I can relate this moment to is somebody yelling “Contact Left!!” and the Marine squad turning in unison and entering the fray.  Each one of our team turned to our computers and start gathering information with a flurry of keystrokes.  One man starting rolling through the web logs for the last hour.  Another man starting pulling down the last hour’s worth of packet captures.  Tom located the malicious code in the infected webpage and I, using that information, tracked down the source of the inserted code to a PHP include file (obviously used since it would get tacked onto every page served by the web application).  I quickly handed the PHP code off to Tom for de-obfuscation (damn, he is seriously fast at it, too) and I turned to investigating the last “known good” snapshot of the website to try and get a good timeline for the team members conducting log analysis. At the same time, two of us remotely acquired images of the web servers in an attempt to detect any malicious interactions with the operating system and provide more detail to our timeline information.

All of our quick action payed off.  About fifteen minutes into this activity the team member analyzing the packet captures said “Holy sh*t!!! I just grabbed the latest packet capture and I think he is on the system right now.”  He paused and then said, “Holy sh*t!!  He’s got root.”  It turns out that all of our work during the week had hampered the attacker enough that s/he wanted to know what as going on with the system.  So, instead of merely managing the malicious activities via the web shell s/he dropped to interacting with the operating system.  The packet captures pointed us to several system-based artifacts which we grabbed for analysis.  This was a boon because until this point, as I mentioned, we had not detected this type of interaction (those web shells provide some nasty functionality – “It’s a feature!!”).  Now we knew the types of tools s/he was using, how s/he got them onto the system, how s/he was hiding them, and the tool’s capabilities.

About thirty minutes in the fray the excitement wore off.  We could see where the attacker logged off of the system (possibly moving onto their next compromised site).  We spent the rest of the day working through the information we found and firming up our findings and recommendations.  I actually flew out of there later that day; high on adrenaline and wishing I could stay.  After all, I would much rather stay and face the enemy than to return to the rear and write a report about it.

So, the incident response-related lessons learned from this engagement:

• Centralized logging of application logs and full network captures are critical during an incident response;
• Being prepared with remote acquisition and data analysis techniques is also extremely important;
• Team organization, tool familiarization, and overall experience will produce positive results from stressful situations;
• Management support and confidence breeds success.

These are the tools and concepts that will help your incident response team fight-the-fight while the mission critical assets stay online and ensures that everybody (client and consultant) gets paid.  When an incident response team asks for these resources or recommends they be put in place, they are not doing it because the technologies are cool.  They are making the recommendations because they are effective and will reduce the time and effort associated with the incident.  Pre-deploying these technologies or generating procedures for doing so will make them even more effective.

Go forth and do good things,

Don C. Weber

Drop The Refrain

The refrain “make it too expensive for the attackers” needs to be retired from the security professional’s vocabulary.  It is not going to happen.  Making it “too expensive” is not S.M.A.R.T. It also means absolutely nothing to the attackers.  The guidance security professionals need to be pushing is that managed business processes and security controls will reduce the overall cost associated with responding to each attack as they are experienced.  It is not a matter of who will do the attacking, when they will do it, or how many resources they have behind them.  It is the understanding that attacks are going to occur, most attacks will involve techniques to which an organization can identify and respond, and some attacks will occur using new methodologies and technologies to which the organization can identify and respond.

Attacker’s Viewpoint

Let’s take a look at the malicious hacker list Roger Grimes put together (which I like very much, BTW) and see how each group is affected by the overall “expense” of their efforts..

Cyber criminals: as these people are after big financial gain they understand that there will be cost involved with their efforts.  The bigger the pay-out the more time and effort they are willing to spend.  However, they just don’t turn away from targets.  Hard targets are softened by time.  Over time there will be new vulnerabilities, new attack methodologies, new personnel, etc.  If something is currently difficult they may roll over to other prey, but they will come back around.

Spammers and adware spreaders: these attackers are generally not concerned with specific targets.  However, the way spammers and adware spreaders conduct their business is interesting to other malicious hackers.  The research and development of this group can easily be leveraged for other purposes.  They try everything in the book and then write new pages when those do not work any more.  They are not concerned about how much it costs to get around your controls because they are best at presenting a moving target.  Basically making it more expensive for customers to keep up with them.

Advanced persistent threat (APT) agents: these guys are good at getting in.  They are also good at being patient.  Biding their time for specific opportunities.  They try a few things to get in and, if that doesn’t work, they try something else.  As they have multiple targets (or so it appears) they move onto the next target on their list.  Then, after a time, they roll back to a targeted organization where their tactics have been unsuccessful and they try something else.  Security programs and controls are not making it more expensive for them.  They know it is a part of the game and they just continue until they are successful.

Corporate spies: well, this attacker is most likely (yes, I’m guessing) expensive to begin with.  I have not run into any of these people or cases, nor have I heard much about them.   But, I understand the mentality.  They could be heavily trained or simply people exploiting an opportunity.  These people are usually in a position where they can manipulate the security controls, or feel they can get away with their efforts despite the controls.  In other words, the reward already out-weighs the risk.

Hacktivists: this group is probably the most affected by the cost of their efforts.  However, they will most likely be associated with the Rogue hacker category and thereby reap the rewards of their efforts.  Which, in turn, means that cost does not affect them much as they rely on targets of opportunity that will produce the actions they desire.

Cyber warriors: although military commanders do take into consideration cost of resources, their limits are beyond those of most corporations.  Additionally, once the cost reaches a certain point then the tactics for this group changes to kinetic solutions.

Rogue hackers: one word for these guys: “challenge.”  If it is a challenge is it really too expensive?  To this group time and effort is nothing.  Once they set their sights they either work it till they are bored with it or they accomplish their objectives.  If a group of these individuals gets their collective heads together, then cost matters even less.  Certainly a good security effort will prevent many unmotivated rogue hackers, but those that are motivated have a purpose where cost is of little consequence.

In Need of a New Catchphrase

Therefore I say out with the old refrain and in with something new.  Preferably something that is a little more Specific, Measurable, Attainable, Relevant, and Time-bound.  I prefer more direct and implementable guidance that helps build cross-functional incident response efforts and teams.  However, for those who require those “elevator statements” (don’t we all at some point) maybe try one of my favorites: “reducing the gap between compromise and identification.”  Because the old “make it too expensive for the attackers” statement is placing the wrong emphasis on the overall effort and makes people, particularly executives, think that 100% secure is an obtainable goal.  When we all know that information security is a sustained effort that will continue as long as the organization exists.

Go forth and do good things,

Don C. Weber

Shmoo Con

First of all, I have to say that my talk at ShmooCon 2011 was a great experience.  Here is a view from my stand point.

Q and Atlas did a great job.  You can experience our talk yourself by downloading and watching the presentation generously provided by ShmooCon.

Purpose

Although this started as one of my first full-fledged hardware projects, the intent was always to evaluate ways to cheaply assess deployments frequency hopping spread spectrum (FHSS) technologies (please review and I’ll assume you did).  Why is this important to you?  Well, because there is a rift in the radio and information techology (IT) community about how much protection FHSS provides.  The most concerning of these view points is that FHSS acts as a pseudo-encryption technique.  People that think FHSS is, by itself, secure believe that the channel hops happen too fast to predict and simulate without knowing  the actual algorithm used to generate the hopping pattern.  This manner of thinking leads to implementations that send data “protected by FHSS” in clear text or obfuscated by techniques such as XOR.  In any system the transmission of clear text information could lead to information disclosure and, in the worst case, data injection.

Some deployments of FHSS are going to be more secure than others.  Military units that use  FHSS have the best capabilities for modifying algorithms such that hopping patterns are reduced or even  eliminated.    Commercial implementations are always going to be based on risk assessment.  This means that the resources necessary to consistently modify algorithms to limit hopping patterns is going to suffer unless it is constantly maintained.  Other limitations will also play into repeated hopping patterns.  Embedded devices with limited memory and processing capabilities naturally limit the effective rotation of generated hopping patterns.  Poor implementations of FHSS will reduce this even more and could result in one pattern being repeated over and over.

The intent of security researchers is to identify weak implementations in any technology.  This lead our team to focus on producing tools that would provide engineers, IT administrators, and security professionals with the capabilities to assess FHSS deployments.  As weak implementations are identified they can be improved with newer technologies or augmented with additional security controls.

FHSS itself is not a vulnerable or “broken” technology.  Just like most technologies it must be deployed and configured correctly to provide its intended functionality.  It is the deployment that may be vulnerable.   FHSS itself increases resiliency (availability) and does make it harder to intercept and interact with the transmitted data.  It, like other technologies, is improved and becomes even more robust when augmented by other technologies such as encryption.

Hedy Attack

The way our team approached identifying hopping patterns is simple in theory.  Certain FHSS deployments will, when given enough time, repeat the channels to which they hop.  This might happen over a year, month, week, day, hour, or even minute.  By monitoring FHSS transmissions it should be possible to determine the point where an FHSS deployment repeats or, in a term that might help some understand, loop.  Loops are the weakness.  Once loops are know the actual algorithm that generated the pattern is not necessary.  A simple ordered list is all that is necessary to intercept and interact with the complete transmission.

HedyAttack approaches this problem by analysing the minimum noise on each channel.  The first step is to record the average minimum received signal strength indicator (RSSI) value of each channel.  Later, any RSSI value that is greater than the minimum plus a boundary value should indicate a transmission on that channel.  Thus, by quickly looping through the spectrum, transmissions on any channel should be detectable.  As hopping patterns are pseudo-random scans must be very fast.  To increase scan speed the actions taken by the radio and controlling microcontroller must be limited to tuning the radio and recording any detected channels that jump above the minimum value.

For FHSS sources that have known configurations, this is enough to begin the analysis.  But, as with every technology, different vendors have their own methods of implementations.  For instance, let’s take the frequency range we mentioned before.  a simple breakdown of this range would be to cut it into 500 KHs pieces which are also referred to as channels.  This would give us 53 channels and make it easy to gather data.  However, the channel spacing does not have to be 500 KHs.  Vendors can split this up any way they choose making their implementations have more or fewer channels. This means that for systems where the channel spacing is unknown tools must analyse and determine these values so that hopping patterns are as accurate as possible.

Similar to channel spacing, the amount of data that each vendor will send during each hop is going to vary.  Data analysis to determine the hopping time increments will also be helpful when analysing the hopping patterns.  As time increments decrease these values will be very valuable to determine the type of equipment necessary to conduct the research.

Hedy Attack provides all of these tools that attempt to provide all of the above with the exception of determining hopping time increments.  Time increments will be worked into the toolset as the other tools become more stable.

Hardware

The hardware selected for this project was the CC1111EMK868-915 Evaluation Module Kit.  This was picked because of the cost, Chipcon radio, TI support, USB capabilities, and breakout of the Data Debug pins.  The fact that other pins were broken out was an added bonus.  Extra added bonus is that work for the CC1111EMK will could also be leveraged for work with the CC2511EMK Evaluation Module Kit and other implementations of Chipcon chips.

Of course interaction with the CC1111EMK would not be possible without the Goodfet.  Travis and his neighbours have developed tools such as goodfet.cc that allow for easy debugging and interaction with the Chipcon radio.   All of the capabilities provided by the Goodfet are also provided by the CC Debugger.  However, I recommend that you get a Goodfet and use it because of its flexibility.  As you develop you will move to other platforms and it is very likely that the Goodfet does, or will, provide you the support you need.

Source Code

Since the talk we have firmed up the code base and uploaded it to HedyAttack at Google Code.  The primary tools (at the time of this post) are:

• specan – Spectrum analysis code ported from the IM-ME project.  This code was the starting point for all of the other tools.  It has had the display functionality removed.  The scan data is written to XDATA and can be pulled using the Data Debug functionality provided by the Goodfet.  The specantap_gnuplot.py client can be used to display the results.  As the
• maxscan – Spectrum analysis code with a focus on the 902 thru 928 MHz range.  This tool generates data in the same manner as specan.  The best way to display this data is to use the maxscan_gnuploy.py client.
• hoptrans – Transmission code that mimics frequency hopping.  This code can be adjusted to hop at different speeds and across as many channels as configured.  Default is set to a channel spacing of 500 KHz which equates to 53 channels.  The intent of this tool is to provide a test environment.  Using this in conjunction with the other tools will require a second CC1111EMK.
• minscan – This tool starts out by recording the average minimum RSSI value for each channel using a series of initialisation passes.  Once the minimum values have been recorded the tool changes mode to monitor ups in the RSSI value that should indicate transmission on that channel.  To track when jumps occurred a loop counter is also maintained.  The loop counter lets us create a tracked array which will contain an ordered list of channel hops.  This list can be pulled off using the minscan.py client.
• hedyattack – The culmination of all the tools.  This tool initialises in much the same manner as minscan.  Several iterations are run to detect the minimum and maximum values of each channel.  Initially this information is used to attempt to determine the channel spacing of the FHSS device.  Although channel spacing can be determine programmatically reviewing the data manually is also helpful.  After the initial iterations the tool moves onto detecting and recording hops in the same manner as minscan.  The added strength of the hedyattack tool is the USB functionality.  This means that interactions with the radio and XDATA no longer need to be accomplished using the Data Debug feature which actually pauses the microprocessor to function.
• Makefile – each tools has a corresponding Makefile in their individual tool folders.  The Makefiles build  the corresponding firmware and place it in the firmware directory.  The Makefiles can also be used to have the Goodfet install the firmware onto the CC1111EMK.

Get To Hacking…err…Assessing

That is it.  HedyAttack in a nutshell.  A methodology and toolset to be used for assessing the FHSS implementations and deployments.  Hopefully it is helpful. Should you wish to join this effort just drop the administrators at HedyAttack a message.  We’ll get back to you as soon as possible.

Go forth and do good things,

Don C. Weber