Recently participated on Timisoara CTF 2018 Quals, which is an online qualifier round international jeopardy-style cybersecurity competition, dedicated to high-school students, community-organized in Timisoara, Romania, under Banat IT Association’s coordination.
Me and my team mate managed to finish at #15 out of 460 teams (under Just for fun Scoreboard — category is for non-eligible teams since the CTF is originally dedicated to high-school students but it allowed non-eligible teams to join provided they will be on Just for fun Scoreboard). We have managed to solve 44.3% of the challenges or (1,961 out of 4,431 total score).
Below are the write-ups for some of the challenges on it.
Note: My team mate actually managed to solved this first. (Hi Mon! ^_^) I ran some problems with the volatility tool that I’ve used which ended up not being able to extract or dump files properly even with correct volatility profile and inode. It was just later after the challenge was solved, when we compare findings that I found out that there is a problem with the volatility I’m using particularly related to python libraries.
- Download the image and find out the OS and kernel version that it uses. (Ubuntu 16.04.4 LTS GNU/Linux 4.4.0-116-generic x86_64)
- Build a volatility profile.
- Use the volatility profile to examine the image.
- Extract the suspicious file that was running.
- Run the file locally to get the flag.
The first step to solve the challenge, was to examine it. Running file command, will show that it is an ELF 64-bit LSB core file x86-64, version 1 (SYSV).
By using strings command, it can be seen that the core dump file is using Ubuntu 16.04.4 LTS as its operating system and is on kernel version 4.4.0-116-generic.
Based on the file, it was already known that it is needed to do memory forensics and analysis on it, and for that the volatility tool was used.
Upon learning this, quick Google search for downloading the volatility profile for Ubuntu 16.04.4 LTS GNU/Linux 4.4.0-116-generic x86_64 was done, but unfortunately didn’t found any of it.
Next thing that was done, was to create a volatility profile based on the operating system and kernel version. Steps for it is already available on Volatility Wiki on Creating a New Profile.
Hence, built a machine with an operating system and kernel version (Ubuntu 16.04.4 LTS GNU/Linux 4.4.0-116-generic x86_64) similar to the image file and then use it to create a volatility profile. More info can be found on Volatility Wiki on Making the Profile.
Created profile was then imported to volatility.
Using volatility and the created profile to examine the process running on the image file shows a rather suspicious file named ht0p.
This can be verified by checking the commands entered on the machine, where it shows that panda user renamed the suleanu file into ht0p, deleted the .bash_history file and run the suspicious ht0p file in background, after that the regular htop file was also been run.
The suspicious file was then searched for its inode (0xffff88007bd8e698) and then use it to dump it.
Running the suspicious file would then result on getting the flag.
To be continued…
More write-ups for the challenges will be added when there is available time.