Hack in the box teaser 2015 : Forensics 1000
In preparation for the Amsterdam Hack in the box CTF this year I took a look at the Forensics 1000 challenge, the description of which you can find below.
Pyongyang
While doing forensics on the HEAVENWEB’s server we found a possible ACTOR.
We scanned the interweb for possible traces left by this ACTOR and found an opendir containing HEAVENWEB_SCRAPE.tar.xz [sha256: 6188c47846d306f29315c5df85c507052d20e98e592e08bdf1b35b46c7f84564].
We believe they use a proprietary crypto application only known to this ACTOR.
Are you able to find the flag?
HINT: https://www.youtube.com/watch?v=zuxlLLeKZZ8
The HEAVENWEB_SCRAPE.tar.xz archive contained 2 files:
HITB_FOR1000_2015: dataHITB2015_FOR1000.dmp: ELF 64-bit LSB core file x86-64, version 1 (SYSV)
Running strings on the HITB2015_FOR1000.dmp file, we see it is an operating system memory dump:
/boot/vmlinuz-2.6.38.8-24.rs3.0.i686
Some cursory googling, coupled with the challenge name we identify the operating system as North Korea’s RedStar. Inspecting the HITB_FOR1000_2015 file we find references to a file system as well as some common encryption buzz words.
After this quick analysis, we watched the hint video and at around the 12.00 minute mark we see a demonstration of Red Star’s custom encryption application – Bokem.
The video further explains Bokem is native to Red Star and requires root privileges to run.
So, let’s install Red Star and escalate to root:
echo 'RUN"+=/bin/bash /tmp/root.sh"' > /etc/udev/rules.d/85-hplj10xx.rules
cat /tmp/root.sh
echo -e "ALL\t\ALL=(ALL)\tNOPASSWD: ALL" >> /etc/sudoers
Let’s fix networking while we are at it:
rm /etc/sysconfig/iptables
After a quick sudo –s you should be able to execute Bokem with root privileges.
Next we can create our own Bokem container, after which we identified that the challenge is also a Bokem container which we need to access.
After creating our own container, we notice the .bokem3.conf file in our current directory, which contained:
[/Users/neut/Desktop/test]
A=B
To this configuration file, we can append the container from the challenge to attempt to load it:
[/Users/neut/Desktop/HITB_FOR1000_2015]
A=B
Unsurprisingly, the challenge container 93a0c2f4 requires a password.
Given this is a forensics challenge, let’s assume we can find what we need in the challenge. So, let’s mount our own container and dump our machine memory. Assuming you are using a virtual machine, you can do this by simply taking the .vmem file of a snapshot.
So now we have the following:
- Our container file, to which we know the password;
- Our memory dump, including a running and decrypted container;
- The challenge container file, which we want to decrypt and do not know the password;
- The challenge memory dump, hopefully including a running and decrypted container.
Let’s start by analysing our own container.
Looking at our own container with the name and password of test we notice in the header:
098f6bcd4621d373cade4e832627b4f6test
Which is the md5 of our password, followed by our container name.
Similarly, in the challenge container we notice in the header:
5135c956f0d1dbacaaaabebc7b3a659f93a0c2f4
Which is the md5 of the container password (which we couldn’t crack), followed by the container name.
So we need some more information from the challenge container, let’s take another look at our running container on Red Star.
Dmsetup is a low level logical volume management tool. Dmsetup can be used to create and remove devices, get information about devices or reload tables. Using the dmsetup tool we can gain some information about the currently mapped devices on the system. Luckily, dmsetup also supports displaying of the encryption keys used.
Let’s take a look at our mapped container and its associated encryption key:
dmsetup table -showkeys bokemcrypt_000: 0 102399 crypt pilsung-cbc-essiv:sha256 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08 0 7:0 1
So, our encryption key is as follows:
9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
If we lazily search for our key in our memory dump we identify an interesting instance:
xxd -p Snapshot1.vmem | grep -A10 -B10 9f86d081884c7d659a2feaa0c55
00000000000000000000000000000000000000000000098f6bcd4621d373
cade4e832627b4f600000000000000000000000000000000000000000000
00000000000000000000b09952080000000081d0869f657d4c88a0ea2f9a
15d05ac51b4fbfa32c820b2b156c5dd1080af0b040000000000000007465
737480000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000
00209f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15
b0f00a08609b520800000000000000000000000000000000000000000000
The memory structure identified contains the md5 of our password, as well as our known encryption key some bytes above.
Doing a similar search using the password hash from the challenge, we identify a similar structure in the challenge memory:
0000000000000000000000000000000000005135c956f0d1dbacaaaabebc
7b3a659f0000000000000000000000000000000000000000000000000000
0000000000009078a4090000000030506bbe15ea870ed58408daff8147e4
280080bfad3db06db6e40ce0f40bad4c4000000000000000000000000000
000000000000000000000000000000800000000000000000000000000000
000000000000000000000000000000000000000000000000000000a8be6b
50300e87ea15da0884d5e44781ffbf8000286db03dade00ce4b64cad0bf4
407aa4090000000000000000000000000000000000000000000000000000
Based on our testing container, be6b50300e87ea15da0884d5e44781ffbf8000286db03dade00ce4b64cad0bf4 appears to be the encryption key used by the challenge container.
So, let’s try and mount the challenge container using the above identified key.
We can create a device and specify a mapping table using dmsetup, for this we need the following table parameters:
start size target cipher –mode-iv:type 256-bit key iv_offset device sector_offset
We can identify most of this information from the mapping settings in our similarly sized container, except the sector offset.
Looking at the challenge container randomness with a hex editor we can identify that the file’s encryption offset appears to start at 0x200 or 512 bytes into the file. For dmsetup a sector is always defined as 512 bytes, so we can identify our new table as follows:
0 102399 crypt pilsung-cbc-essiv:sha256 be6b50300e87ea15da0884d5e44781ffbf8000286db03dade00ce4b64cad0bf4 0 /dev/loop2 1
Now we can mount the challenge container:
losetup /dev/loop2 HITB
dmsetup create HITB --table '0 102399 crypt pilsung-cbc-essiv:sha256 be6b50300e87ea15da0884d5e44781ffbf8000286db03dade00ce4b64cad0bf4 0 /dev/loop2 1'
mount -o rw -t ext3 /dev/mapper/HITB /mnt/HITB
Once mounted, we identify a single file in the container flag_HITB.txt which contained:
HITB{4468eaa8a5d6fdbff208dac223afb81c}