TIMISOARA CTF 2018 QUALS - Neurosurgery

Solves: 17 | Points: 250 | Category: Forensics

Challenge description

I consider biology classes the most fun of all and sometimes scary.
For example, in the last lesson we learned about brain dumping. It
was extraordinary (black magic as my dad said, btw he’s a computer
scientist), learning about interactions and activities in the memory.
What? Yes, of course you can look at it, too. The pleasure is mine!
Download: https://drive.google.com/open?id=1IKI7Pn73y8L2u-znw3H7PLYhzSAtYJRK
Authors: Sin__ & 0xcpu

Challenge resolution

Creating a volatility profile

While running the file command on the challenge file, we get the following output :

florent@kali:~# file image 
image: ELF 64-bit LSB core file x86-64, version 1 (SYSV)

However, after trying to run the file, we can see that it is either corrupted or not an ELF.

florent@kali:~# strings image
VBCORE
VBCPU
system.slice
nder='org.freedesktop.DBus',path='/org/freedesktop/DBus',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.1'
[...]
sys-devices-pci0000:00-0000:00:05.0-sound-card0.device.requires
sys-devices-pci0000:00-0000:00:05.0-sound-card0.device.wants
[...]
systemd.log_target
systemd.log_level
systemd.log_color
systemd.log_location
alert
crit
warning
notice
info
console
console-prefixed
kmsg
journal
journal-or-kmsg
syslog
syslog-or-kmsg
[...]

The latter seems to be the answer as we can find out that the file is a memory dump.

florent@kali:~# strings image | grep "Linux version"
Linux version 4.4.0-116-generic (buildd@lgw01-amd64-021) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9) ) #140-Ubuntu SMP Mon Feb 12 21:23:04 UTC 2018 (Ubuntu 4.4.0-116.140-generic 4.4.98)

To analyze this memory dump, we can use volatility.
Unfortunately, the volatility profile for this kernel version isn’t available by default, so we need to make one.
To do so, we set up an Ubuntu 16.04 VM and install the following packages :

  • linux-image-4.4.0-116-generic
  • linux-headers-4.4.0-116-generic
  • volatility-tools

Then, we modify the GRUB so it can boot on our newly added kernel.
This tutorial can be used to do so.

We put the zip file in the desired directory (might change according to the version of yours tools) :

florent@kali:~# cp ~/ubuntu1604timctf.zip /usr/lib/python2.7/dist-packages/volatility/plugins/overlays/linux/

If imported successfully, you should be able to see the profile :

florent@kali:~# volatility --info | grep Profiles -A 5
Volatility Foundation Volatility Framework 2.5
Profiles
--------
Linuxubuntu1604timctfx64 - A Profile for Linux ubuntu1604timctf x64
VistaSP0x64 - A Profile for Windows Vista SP0 x64
VistaSP0x86 - A Profile for Windows Vista SP0 x86
VistaSP1x64 - A Profile for Windows Vista SP1 x64

The profile can now be used to retrieve information from the memory dump.
We run the linux bash command which allows us to have a look at the .bash_history :

Analyzing the memory

florent@kali:~# volatility -f image --profile=Linuxubuntu1604timctfx64 linux_bash

Pid Name Command Time Command
-------- -------------------- ------------------------------ -------
1166 bash 2018-04-15 15:24:47 UTC+0000 cd ..
1166 bash 2018-04-15 15:24:47 UTC+0000 ls
1166 bash 2018-04-15 15:24:47 UTC+0000 ls
1166 bash 2018-04-15 15:24:47 UTC+0000 sudo rm /media/sf_bin/
1166 bash 2018-04-15 15:24:47 UTC+0000 cd .cache/
1166 bash 2018-04-15 15:24:47 UTC+0000 ls
1166 bash 2018-04-15 15:24:47 UTC+0000 sudo su
1166 bash 2018-04-15 15:24:47 UTC+0000 ls -la
1166 bash 2018-04-15 15:24:47 UTC+0000 poweroff
1166 bash 2018-04-15 15:24:47 UTC+0000 ls -la
1166 bash 2018-04-15 15:24:47 UTC+0000 sudo chown panda:panda ht0p
1166 bash 2018-04-15 15:24:47 UTC+0000 ls
1166 bash 2018-04-15 15:24:47 UTC+0000 ls -la
1166 bash 2018-04-15 15:24:47 UTC+0000 sudo umount /media/sf_bin
1166 bash 2018-04-15 15:24:47 UTC+0000 sudo rm -r /media/sf_bin/
1166 bash 2018-04-15 15:24:47 UTC+0000 chown panda:panda ht0p
1166 bash 2018-04-15 15:24:47 UTC+0000 chown panda:panda suleanu
1166 bash 2018-04-15 15:24:47 UTC+0000 mv suleanu ht0p
1166 bash 2018-04-15 15:24:49 UTC+0000 ls -la
1166 bash 2018-04-15 15:24:55 UTC+0000 shred -u .bash_history
1166 bash 2018-04-15 15:24:59 UTC+0000 ls
1166 bash 2018-04-15 15:25:02 UTC+0000 ls -la
1166 bash 2018-04-15 15:25:21 UTC+0000 ls /media/
1166 bash 2018-04-15 15:25:24 UTC+0000 ls -la
1166 bash 2018-04-15 15:25:30 UTC+0000 ./ht0p \ &
1166 bash 2018-04-15 15:25:32 UTC+0000 htop
1166 bash 2018-04-15 15:25:32 UTC+0000 htop

As we can see, there is what seems to be an interesting file called ht0p.
At this point, we could just dump the process from memory.
However, for some reason, it doesn’t work as intended when we try do so and we get a corrupted binary.
Below is another method to dump the binary :

  • First, we retrieve its full path :
volatility -f image --profile
Volatility Foundation Volatility Framework 2.5
ht0p 1192 XDG_VTNR=1 XDG_SESSION_ID=1 SHELL=/bin/bash
[...]
PWD=/home/panda LANG=en_US.UTF-8 SHLVL=1 XDG_SEAT=seat0 HOME=/home/panda LOGNAME=panda
[...]
  • After, we get the offset at which the binary is loaded in memory :
florent@kali:~# volatility -f image --profile=Linuxubuntu1604timctfx64 linux_find_file -F "/home/panda/ht0p"
Volatility Foundation Volatility Framework 2.6
Inode Number Inode File Path
---------------- ------------------ ---------
390593 0xffff88007bd8e698 /home/panda/ht0p
  • Finally, we dump the binary :
florent@kali:~# volatility -f image --profile=Linuxubuntu1604timctfx64 linux_find_file -i 0xffff88007bd8e698 -O ht0p

The end of the challenge is pretty straightforward :

florent@kali:~# file ht0p 
ht0p: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=015d3ac9f4ba50287e556b432120e468916710ce, stripped
florent@kali:~# chmod +x ht0p
florent@kali:~# ./ht0p
****\/\/-- timctf{ch4nc3_f4vors_th3_pr3p4red_m1nd} --\/\/****