Write-up of the 29c3 CTF “What’s This” Challenge

Archive for the ‘Forensics’ Category

Write-up of the 29c3 CTF “What’s This” Challenge

Posted by

Subtitled: “How to capture a flag in twelve easy days”

The 29th Chaos Communication Congress (29C3) held an online capture the flag (CTF) event this year. There were several challenges, which you can see at the CTF Time page for the 29c3 CTF. I spent most of the time on the “What’s This” challenge. The clue was a USB packet capture file named what_this.pcap.

The first thing we did was run strings what_this.pcap and look at the ASCII and Unicode strings in the capture. ASCII: CASIO DIGITAL_CAMERA 1.00, FAT16, ACR122U103h. Unicode: CASIO QV DIGITAL, CASIO COMPUTER, CCID USB Reader.

The second thing we did was to open the capture in Wireshark 1.84. (Using the lastest version of Wireshark is important as the USB packet parser is still being implemented.) We knew Philip Polstra had covered USB forensics in the past, such as at GrrCon, and Philip pointed us to http://www.linux-usb.org/usb.ids for identifying devices. We see a Genesys Logic USB-2.0 4-Port HUB (frame.number==2), a Linux Foundation USB 2.0 root hub (frame.number==4), Holtek Semiconductor Shortboard Lefty (frame.number==32, 42), a Casio Computer device (frame.number==96, 106), and another Casio Computer device (frame.number==1790).

Supposition? The person is running Linux with a keyboard, Casio camera, and smart card (CCID) reader attached over USB. A Mifare Classic card (ACR122U103) is swiped on the CCID reader. The camera is mounted (FAT16) and a file or files are read from the device.

Next, we extracted the keystrokes. I had previously written a simple keystroke analyzer for the CSAW CTF Qualification Round 2012. This simply took the second byte in the USB keyboard packets (URB_INTERRUPT) and added 94. This meant the alphabetical characters were correct, however, all special characters and linefeeds were lost. The #misec 29c3 CTF captain, j3remy, passed along a lookup table. Using this lookup table, we found the following keystrokes:

dmeesg
mmouunt t vfaat //ddev/ssdb1 /usb
ccd usb
llss —l
fiille laagg
dmmeessg
nfc-lsisst
ccat flaag \ aespipe -p 3 -d 3,,, nffs-llisst \c-llisst \ grrep uuid \ cut =-d -f 10\ dd sbbs=113 couunnt=2

There are a number of problems with this method of analyzing keystrokes. First, when the key is held down too long, we get multiple letters (dmeesg). Second, special keys like shift and backspace are ignored. I redid my parser to read bytes 1, 2, and 3. The first byte in a keyboard packet is whether or not shift is depressed. The second byte is the character (including keys like enter and backspace). The third byte is the error code for repeating characters. Using this information, I mapped the HID usage tables toMicrosoft’s SendKeys documentation and replayed the packet file into Notepad.

dmesg
mount -t vfat /dev/sdb1 usb
cd usb
ls -l
file  lag
dmesg
nfc-list
cat flag | aespipe -p 3 -d 3<<< "`nfc-list | grep UID | cut -d  " " -f 10-| dd bs=13 count=2`"

Supposition? The person at the keyboard plugged in the Casio camera and mounted it to usb. He listed the folder contents, then scanned for the Mifare Card (nfc-list lists near field communications devices via ISO14443A). Once confirmed, he read the flag from the camera and decrypted it via AES 128-bit encryption in CBC mode (man aespipe). The passcode was the UID of the Mifare Card in bytes (nfc-list | grep | cut | dd). To find the flag, we need both the UID and the flag file.

The hard work of finding the UID was done by j3remy. He followed the ACR122U API guide and traced the calls/responses. For example, frame.number==1954 reads Data: ff 00 00 00 02 d4 02, or get (ff) the firmware (2d d4). The response comes in frame.number==1961 Data: 61 08, 8 bytes coming with the firmware. Then frame.number==1966, Data: ff c0 00 00 00 08, get (ff) read (c0) the 8 bytes (08). And the card reader returns the firmware d5 03 32 01 06 07 90 00 in frame.number==1973. j3remy likewise parsed the communications and found frame.number==3427 which reads: d54b010100440007049748ba3423809000

d5 4b == pre-amble
01 == number of tag found
01 == target number
00 44 == SNES_RES
07 == Length of UID
04 97 48 ba 34 23 80 == UID
90 00 == Operation finished

The next step was to properly format the UID as the nfc-list command would display it. This took some doing. Effectively, there are 4 blank spaces before ATQA, 7 blank spaces before UID, and 6 spaces before SAK. There is one space after : and before the hexadecimal value. Each hexadecimal value is double-spaced. With that in mind, we created an nfc-list.txt file:

    ATQA (SENS_RES): 00  44
       UID (NFCID1): 04  97  48  ba  34  23  80
      SAK (SEL_RES): 00

Determining the spacing took some time. Once we had it, we could run the cat | grep | dd command and correctly return 26 bytes of ASCII characters.

$ echo "`cat nfc-list.txt | grep UID | cut -d  " " -f 10-| dd bs=13 count=2`"
2+0 records in
2+0 records out
26 bytes (26 B) copied, 6.2772e-05 s, 414 kB/s
04  97  48  ba  34  23  80

To recap: we have the UID, we have correctly converted the UID to a AES 128-bit decryption key, and we are now ready to decrypt the file. How to find the file, though? Rather than reverse engineering FAT16 over USB, we took a brute force approach. We exported all USB packets with data into files named flagnnnn (where nnnn was the frame.number). We then ran the following script:

FILES=flag*
for f in $FILES
do
    echo -e \n Processing $f file… \n
    cat $f | aespipe -p 3ls -d 3<<< `cat nfc-list.txt | grep UID | cut -d ‘ ‘ -f 10-| dd bs=13 count=2`
done

There it was. In the file flag1746, in the frame.number==1746, from the Casio camera (device 26.1) to the computer (host), we found a byte array that decrypted properly to:

29C3_ISO1443A_what_else?

What else, indeed? Well played.

Special thanks to Friedrich (aka airmack) and the 29c3 CTF organizers for an enjoyable challenge. Thanks for j3remy for captaining the #misec team and helping make sense of the ACR122 API. Helping us solve this were Philip Polstra and PhreakingGeek. It took a while, but we got it!

iOS Forensic website

Posted by

The iPhone Forensics book by Jonathan Zdziarski (NerveGas) is getting a little long in the tooth. The material covers iOS 2.x and Apple is now well into iOS 4.x, with 5.x on the horizon. The book is on iPhones and, of course, the iPad revolution is well underway. Where to now?

I see that Zdziarski launched an iOS Forensic Research website with up-to-date information. The site and its toolset are aimed at law enforcement and the military. He is also hosting a series of workshops (Advanced iOS Imaging and Investigation L-1) which cover a variety of forensics techniques on iPhones, iPods, and iPads. Here’s hoping the site is extended to corporate InfoSec professionals.

iPhone Forensics book

Posted by

iPhone forensics guru Jonathan Zdziarski (NerveGas) has abook out with O’Reilly. “With iPhone use increasing in business networks, IT and security professionals face a serious challenge: these devices store an enormous amount of information. If your staff conducts business with iPhones, you need to know how to recover, analyze, and securely destroy sensitive data. iPhone Forensics supplies the knowledge necessary to conduct complete and highly specialized forensic analysis of the iPhone, iPhone 3G, and iPod Touch.”

Amazon.com has the iPhone Forensics book online.

Detecting information leakage in Windows Server

Posted by

Information leakage can occur when people with access to sensitive information copy the information to an insecure location. For example, a company’s financials may be stored on a file server. This server has restricted CIFS share permissions and restricted NTFS file system permissions. An employee with access copies these financials down and burns them to a CD. As there are no permissions or restrictions on the CD, anyone now has access to this sensitive information.

Detective controls exist in Windows Server and Windows XP to catch these types of situations.
Server-side

Simply setup SACL (system access control lists) permissions on the file server. Right-click the folder, choose Properties, click the Security tab and then click Advanced. On the Advanced dialog, click the Auditing tab and then click Edit. I recommend checking “List Folder / Read Data”, “Create Files / Write Data”, “Create Folders / Append Data”, and “Delete Subfolders and Files”. This will generate events in the Security logs when files are accessed. For example:

Event Type: Success Audit
Event Source: Security
Event Category: Object Access
Event ID: 560
User: DOMAIN\username
Description:
Object Open:
Object Server: Security
Object Type: File
Object Name: \Device\HarddiskVolume20\Share\Sensitive Files\Financials.xls
Handle ID: 20492
Operation ID: {0,1917999625}
Process ID: 4
Image File Name:
Primary User Name: SERVER$
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: username
Client Domain: DOMAIN
Client Logon ID: (0x0,0x6CEC6800)
Accesses: ReadData (or ListDirectory)
Client-side

The event log will now tell you when files are opened, copied, or modified by employees. Now watch the Window desktops to see what they are doing with these files.

The registry contains a wealth of information on external storage devices. Monitor the following keys to see if external devices are being attached.

Floppy disks – [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FDC]
Firewire Devices– [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\sbp2]
IDE – [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\IDE]
SCSI – [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\SCSI]
USB – [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\usbstor]

Monitor other registry keys to see what programs are being run. In particular, look for bulk copy utilities, backup programs, FTP clients, CD burners, and so on. Open the user’s registry file (ntuser.dat) and browse to:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist]

This UserAssist key will have several entries that represent recently used programs. Each entry is encoded (rot13) and formatted as follows: GUID, Index, ACTION, Session key, Number of times the app has executed, date time last executed.  The section you want is the action. Specifically, the UEME_RUNPAT<executable> entries.

 

In summary, enable SACL auditing on the Windows Servers and be prepared to spot-check Windows XP clients. By combining server-side auditing and client-side forensics, you will be able to curtail information disclosure.