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.
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?
HEAVENWEB_SCRAPE.tar.xz archive contained 2 files:
HITB2015_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:
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 –
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:
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:
To this configuration file, we can append the container from the challenge to attempt to load it:
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:
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:
Which is the md5 of our password, followed by our container name.
Similarly, in the challenge container we notice in the header:
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:
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: