Tuesday, September 23, 2014

Writeup - CSAW 2014 : Forensics 300 - Fluffly No More

PREFACE: There is a ton of data to look at in this challenge. I will not be posting many screen shots, but I will post the important ones.

For this challenge, we were given a tar ball with all of the files from the var and etc folders and the mysql file from a server that had sustained some sort of  attack. Our job was to figure out what happened.

I had some issues with the archive not extracting properly. I used bzip2recover and then reassembled the blocks and everything worked fine. A teammate said he used 7zip to extract everything with no issues.

Once we got the files extracted it was time to start digging. The first thing we should have done was reassemble the database. I didn't do that for a while, but after I did it was actually helpful.

I saw a comment exchange between a bald bunny who was very offended at the fluffy bunny blog and was determined to hack it. Note the same IP addresses.


After looking around for a bit, our attention was drawn to the access.log in the apache2 folder. In there, we noticed a metric TON of 404 errors on random URLs that all happened very, very quickly. The attacker was using some fuzzer to scan the site for vulns. The fuzzing came to an abrupt stop. The log is massive so I will not be posting a screen shot of that, but you can use the following command to see what I'm talking about.

 var/log/apache2: grep -n "404" access.log  

Looking in other logs, we can see that the attacker was able to pop a shell and get access to the machine. Once he did that, he began locking it down.

The attacker disabled all of the non-system level user accounts, INCLUDING ROOT, after adding himself as a root user and gave himself the diabolical user name of 'ubuntu.' One might think that the flag is the password for the attacker's user account. But, knowing some about shadow files, the normal hashing algorithm is sha256. He upgraded the hashing to sha512, so that would prevent things like John's unshadowing tool from working without some kind of mod. Additionally, breaking a sha512 seems a little unreasonable, so we continued to look for things of interest in the logs. (Note: The accounts with a * have been disabled).

Continuing to peek around the logs, we could see that the attacker started a screen sharing session, uploaded his own personal private / public keys for his ssh sessions and created a ssh connection with the server that he would be able to use. But none of this was of critical relevance for solving the challenge.

Continuing to look at the auth.log file, we noticed that he edited the html5.js file.

Looking at the file, it appears to be normal except for the end of it. (I put the contents into a js beautifier, then into an online interpreter). After running the questionable code (aka, deleting the parts that were legitimate and changing document.write to console.log), we got the following output:

Time to go look at analytics.js!

After putting the code into a beautifier again, we noticed this string:
(click to zoom)

Well. Let's pop that hex into one of my favorite tools, asciitohex.com! 

Off to the pdf we go! 

 At this point, it is important to note that the attacker changed the headers of the wp theme files to call his malicious javascript. When any page running any of the themes would load, that script would execute and bring any user of the website to this pdf.

The "RIGHT NOW" part of the pdf makes me suspicious. This isn't a jpg, or png file, but a PDF. I know pdfs used to be (and probably still are) able to be exploited with the way that they stored associated data. I also know that data in PDFs are stored in streams and undergo a type of compression. So trying to run strings or open the PDF in a hex editor would prove unfruitful. I found this really good tool called PDFStreamDumper that dumps all of the compressed data in PDF files.

In doing that, I got the following output from one of the blocks:

Looks pretty suspect, eh?

Back to asciitohex.com we go!

And that's it!

key{Those Fluffy Bunnies Make Tummy Bumpy}

There are many more things to see in the logs about what the attacker did to the machine to lock everyone out and to also gain persistence (like changing the pass for the mysql user, etc) but there is way too much to show in this post.

This was a really good challenge and I learned a lot.