Saturday, May 29, 2010

Defcon 18 CTF quals writeup - Forensics 100

Forensics 100 was simple forensics but still with some traps.

Description: find the key, and they gave us the following file which revealed to be a gzipped raw disk image.

First analysis

After extracting, use the file command to recognize a raw disk image:
$ file f100_6db079ca91c4860f.bin
f100_6db079ca91c4860f.bin:    x86 boot sector; partition 1: ID=0x7, starthead 0,
  startsector 31, 31558 sectors

fdisk shows one valid partition:
$ fdisk -lu f100_6db079ca91c4860f.bin
You must set cylinders.
You can do this from the extra functions menu.

Disk f100_6db079ca91c4860f.bin: 0 MB, 0 bytes
1 heads, 31 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0x00000000

Device Boot      Start         End      Blocks   Id  System
f100_6db079ca91c4860f.bin1              31       31588       15779    7  HPFS/NTFS

But thanks to mmls - part of The Sleuth Kit - we can see the full partition table, with the unallocated space not to forget in our analysis:
$ mmls f100_6db079ca91c4860f.bin 
DOS Partition Table
Offset Sector: 0
Units are in 512-byte sectors

Slot    Start        End          Length       Description
00:  Meta    0000000000   0000000000   0000000001   Primary Table (#0)
01:  -----   0000000000   0000000030   0000000031   Unallocated
02:  00:00   0000000031   0000031588   0000031558   NTFS (0x07)
03:  -----   0000031589   0000031615   0000000027   Unallocated

From now on, here is what I usually do (my methodology):
  • Extract the partitions simply with dd
  • Quick look with strings or even raw hex: not at the main partition (15 MB is too big), but at the unallocated space
  • Run foremost or scalpel to quickly extract any interesting files, and have a look at them
  • Run The Sleuth Kit with Autopsy browser for more in-depth analysis of the filesystem of main partition

Extracting partitions

According to the values given by mmls, we can extract partitions with dd.
$ dd if=f100_6db079ca91c4860f.bin of=f100_6db079ca91c4860f_p0.bin bs=512 skip=0 count=1
$ dd if=f100_6db079ca91c4860f.bin of=f100_6db079ca91c4860f_p1.bin bs=512 skip=0 count=31
$ dd if=f100_6db079ca91c4860f.bin of=f100_6db079ca91c4860f_p2.bin bs=512 skip=31 count=31558
$ dd if=f100_6db079ca91c4860f.bin of=f100_6db079ca91c4860f_p3.bin bs=512 skip=31589 count=27
$ file 100_6db079ca91c4860f_p*.bin
f100_6db079ca91c4860f_p0.bin: x86 boot sector; partition 1: ID=0x7, starthead 0, startsector 31, 31558 sectors
f100_6db079ca91c4860f_p1.bin: x86 boot sector; partition 1: ID=0x7, starthead 0, startsector 31, 31558 sectors
f100_6db079ca91c4860f_p2.bin: x86 boot sector
f100_6db079ca91c4860f_p3.bin: data

Quick look at unallocated space

Running strings on partition #3:
$ strings f100_6db079ca91c4860f_p3.bin
Mustapha Laden          972-3-5197575
Hank Huessein           00-1-703-343-7604
Samir Nagheenanajar     9661-4883800
Pete Mitchell           843-234-2342
Tom Kazanski            343-343-2343
Pete Gibbons            234-324-2342
Hans Gruber             49-89-2888-0
Wah Sing Ku             011-81-3-3224-5000
sometimes it is not real
strings suck

And with a hex dump:
$ hexdump -C f100_6db079ca91c4860f_p3.bin
00000470  0000000000e00000  7768657265307768  |........where0wh|
00000480  6572653135746865  6b33793f00000000  |ere15thek3y?....|
00000490  0000000000000000  0000000000000000  |................|
000004a0  0069007400690073  006e006f00740068  |.i.t.i.s.n.o.t.h|
000004b0  0065007200650000  0000000000000000  |.e.r.e..........|

Ok, it is clear: it is not here.

Interesting files

Foremost, scalpel or even mounting partition #2 give the same files:
$ ls -l
-rwxrwxrwx 2 root root 33383 May 19 02:32 2009040811380736734_115018_0.jpg
-rwxrwxrwx 2 root root  9970 May 19 02:31 carpenter.png
-rwxrwxrwx 1 root root 11765 May 19 02:31 caught.jpg
-rwxrwxrwx 1 root root 13862 May 19 02:31 evidence.jpg
-rwxrwxrwx 1 root root 36947 May 19 02:32 furries.jpg
-rwxrwxrwx 1 root root  4378 May 19 02:33 images.jpg
-rwxrwxrwx 2 root root  1929 May 19 02:32 whiteflag.jpg
All extracted files available here.

carpenter.png seems an interesting picture of base64 text: we took some time to extract it with my teammate milo, played with it a bit, but found nothing.

The panda images.jpg has some JPEG EXIF data:
$ jhead extracted_files/images.jpg
File name    : extracted_files/images.jpg
File size    : 4378 bytes
File date    : 2010:05:22 01:57:57
Resolution   : 116 x 102
GPS Latitude : N 36d  8m  8.5s
GPS Longitude: E 115d  9m 29s
Comment      : Who is the author?ASCII

We find the ASCII comment Who is the author? and GPS coordinates leading us in China. We even spent some to find the same picture in Google Images to see if we can find some useful information, but nothing interesting.

Another trap.

In-depth analysis of the main partition

For that, I use my favourite tools: The Sleuth Kit with Autopsy browser, which I have already introduced in a previous posting about Codegate challenge #19. Same thing: we create a new case, a new host, add partition #2 and ready to start file analysis.

File analysis view is very useful as always, we can see deleted file C:\key, sadly with no content in it:

However NTFS has an interesting component: the Master File Table (MFT), shown in the NTFS filesystem as $MFT. Let's have a look at it because it may still contain portions of our deleted file.

We could scroll the whole MFT in hex, but is rather big. A better thing to do is to see its metadata 0-128-1 (last column) and view the information from there.

Interesting report. Let's have a look at all the MFT data clusters:
1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 ...
For instance with cluster 1323:

Finally we stumble upon the MFT entry for key file, and find something interesting:

We see:
where the dots are null bytes (they may come from Unicode). Seems interesting, try it as a flag, first by adding spaces to make it correct: not deleted, never existed but it does not work, so try without spaces: notdeleted,neverexisted and CORRECT!

You can find another good write-up of this challenge from Scott Wolchok, among others.

1 comment:

  1. Did you see Scott Wolchok getting hacked at smpctf?