Forensics CTF challenge - FBiOS writeup

Yesterday, Friday the 13th of May 2016 I had the privilege to take part in a company wide CTF competition. This was my second time attending one from start to finish (the first being SANS Netwars 2015). My department within my company formed a single team to combine our technologically cyber intelligent minds(just trolling :p). But we did indeed band up to take on these challenges. 

There were a few different categories a few including: Trivia, Web, Crypto, Reversing, Forensics, and MISC. Working in IR it took on the challenge of solving the Forensics challenges. Below is the highest point (500) question within the Forensics category. I will then show how I solved this problem. 

Question/Challenge:

Step 1. Download the file. 

The link directs you to a google drive hosted file.

That file is 1,926,442KB in size. The file name is: FBiOS.7z-113c529c20a080bc36b050e9faf33485b123607005e862d67fbf2ac7a517f3d2

Step 2. Extract the file using your favorite uncompressor. 

I chose to use WinRAR.

Inside this 7z file are two additional files:

FBiOS.hdd (2,097,152 KB - 13ba50ee448148c2f17043a660ec5d4a1c4005d3c15fffaca8c143bd0aeb75fb) 

FBiOS.mem (444,205 KB - 276bd3b863e3f0f9f655dd5ffaa81c0f4bc9cade02680b9a430984fec2ac4c73). 

As the challenge states, the .hdd file is the disk image and the .mem file is the memory image. 

Step 3. Explore the HD image.

Before we go digging in the memory file I wanted to get an idea of what we're dealing with by taking a look at the drive image. Why? Because there are a plethora of HD image analysis tools out there, compared with memory analysis tools, that provide a gui based interface and therefor a better visualization of the drive structure. 

Since I work out of Windows on my main system, I chose to use Autopsy to analyze the HD image. 

I see a .gz file. I extracted and could not find anything of interest there considering it seemed to contain nothing of value. 

Also, in that same directory there is a LUKs file. LUKs is a full disk/file container encryption tool on Linux based operating systems. This is the file of interest we need.

Step 4. Extract the LUKs file.

As stated by the challenge, the "HiPhone" was encrypted. We need to figure out how to open this encrypted file to get to our flag. In Autopsy, it is as easy as right clicking and then Extracting files. 

File details: 

f0000000.luks (1,845,248 KB - afc38778d8ff53e257a3eb145288549eeee9435be589b93073af67bf75e78eae)

Step 5. Locating the encryption key

So now that we have our encrypted file container, we now need the key. Luckily we have the memory dump. When memory is dumped and an encrypted file container is mounted at the time of the dump, It will contain the raw encryption key. 

I will be up front, I do not know where in memory encryption keys are located. I could attempt to explore this image via volatility or some other memory analysis tool but I do not have the skill to do that fast. 

I chose to use a tool called bulk_extractor (http://digitalcorpora.org/downloads/bulk_extractor/). The reason being that one of the artifacts that bulk_extractor is able to pull is AES keys from a file. 

Run bulk_extractor on the file:

.\bulk_extractor64.exe -o .\FBiOS\ .\FBiOS.mem

Now check your output directory for a file called "aes_keys.txt"

You should see something like: 

# BANNER FILE NOT PROVIDED (-b option)

# BULK_EXTRACTOR-Version: 1.5.2 ($Rev: 10844 $)

# Feature-Recorder: aes_keys

# Filename: .\FBiOS.mem

# Feature-File-Version: 1.1

209284240 2c c4 4f 83 34 67 8d d3 bf 90 a2 62 73 48 f0 7b 06 ff e6 ed 31 81 4a 19 2d 09 52 ed 3b c8 2f a6 AES256

210258064 08 fe 3b 64 62 08 a2 e2 55 e0 fd d1 ae a8 8a 7e 2a ae 80 3d 16 e9 0e bc 97 7b 14 60 2d 09 84 de AES256

433757396 03 50 5d bf 82 cd 0f 48 2b 45 08 1b b8 45 8d 4c 7d 2e 16 c0 32 d5 9a fc 56 ec d4 8c 05 60 94 92 AES256

Safe these hex values to a new binary file in HxD. We now have the keys to decrypt the LUKs file. 

Step 6. Open the LUKs file.

Attach the LUKS file to a loopback device: 

rak@rakkali:~/Desktop$ sudo losetup /dev/loop/1 f0000000.luks 

Open the luks file with cryptsetup luksOpen:

rak@rakkali:~/Desktop$ sudo cryptsetup luksOpen --master-key-file key1.key /dev/loop1 iphone

Cannot read 64 bytes from keyfile key1.key.

Notice how we have a problem where the keys identified by bulk_extractor are 32 bytes and not 64 as expected by cryptsetup. So lets go back to our aes keys found by bulk extractor. 

If we open the mem file in a hex editor and locate our first AES key, we see that it is not 32 bytes but actually 64. So the first two 32 byte keys identified by bulk_extractor are actually one key:

Combine the two keys:

rak@rakkali:~/Desktop$ cat key1.key key2.key > 1_2.key

Lets try the luksOpen again:

rak@rakkali:~/Desktop$ sudo cryptsetup luksOpen --master-key-file 1_2.key /dev/loop1 iphone

Success. 

Now we must mount the encrypted file container:

rak@rakkali:~/Desktop$ sudo mkdir /mnt/iphone

rak@rakkali:~/Desktop$ sudo mount /dev/mapper/iphone /mnt/iphone/

mount: unknown filesystem type 'LVM2_member'

Ugh oh. A new error which is blocking us. Using the guide here: http://pissedoffadmins.com/os/mount-unknown-filesystem-type-lvm2_member.html I learned how to make the devs ACTIVE:

rak@rakkali:~/Desktop$ sudo lvscan

  inactive          '/dev/FBiOS/root' [1.63 GiB] inherit

  inactive          '/dev/FBiOS/swap_1' [128.00 MiB] inherit

  ACTIVE            '/dev/rakkali-vg/root' [18.90 GiB] inherit

  ACTIVE            '/dev/rakkali-vg/swap_1' [872.00 MiB] inherit

rak@rakkali:~/Desktop$ modprobe dm-mod

rak@rakkali:~/Desktop$ sudo vgchange -ay

  2 logical volume(s) in volume group "FBiOS" now active

  2 logical volume(s) in volume group "rakkali-vg" now active

Now lets finally attempt mounting one more time:

rak@rakkali:~/Desktop$ sudo mount /dev/FBiOS/root /mnt/iphone/

Were in:

rak@rakkali:~/Desktop$ ls /mnt/iphone/

bin/        home/       lost+found/ proc/       selinux/    usr/        

boot/       initrd.img  media/      root/       srv/        var/        

dev/        lib/        mnt/        run/        sys/        vmlinuz     

etc/        lib64/      opt/        sbin/       tmp/   

Let's find this flag quick with a good old find command:
root@rakkali:/# find . -type f -iname flag*

We now have our flag. 

root@rakkali:/mnt/iphone/root# cat flag.txt 
flag{Please_Upgrade_to_FBiOS_10!}