I spent a few days in Lancaster last week at the #wcukretreat. While there I got a message from someone who I’d done some work for earlier this year that one of his sites had been hacked. This post tells you a bit about how I fixed it, where the vulnerability was, and some follow up activity.
When visiting the site, instead of seeing the home page, the hackers had added index.html, which trumps index.php
Getting the site working again
Behind the index.html page, WordPress was still working. At the time I didn’t have access to FTP, so I couldn’t JUST remove the offending file to get the site back up and running. I resorted to some hacking of my own.
- Log in as an administrator
- Edit an inactive plugin
- Replace ALL the code in the main plugin file with logic to remove the unwanted “index.html” file
- Activate it
- Let it run
- Deactivate it
I had to repeat steps 3. to 5. a few times before I got it right, even though it was only an unlink() that was needed.
BUT that wasn’t enough…
Although the hacked index.html was no longer present, since the site was installed in a slightly non-standard way, I still needed to reinstate the .htaccess file in the root directory with a file that performed 301 redirects from the original static HTML pages to the WordPress equivalent URLs
Notes: The hackers had removed this .htaccess file in order to make their hack work. Fortunately, I had a backup of the original file AND was able to use FTP to transfer it.
Finding the vulnerability
I then set about finding the vulnerability.
- I took a complete backup of the site ( database and files ) and downloaded the .zip file to my PC.
- I then unzipped the file to a local directory
- AND as I did so, Kaspersky Internet Security identified a backdoor PHP shell, in an uploads directory.
- There was also an unexpected .c file in the folder too
Analysing the log file
So now that I knew there was at least one unwanted file in uploads, I started looking for how it got there. Fortunately I had a head start. I’d already done some work on a site which contained a simple file upload vulnerability in its theme ( No, it wasn’t the tim thumb vulnerability). So I was quickly able to spot the vulnerable code being invoked and then see the uploaded file being run.
The hackers were fairly clever; they actually deleted the vulnerable file from the theme.
It turned out that the file that Kaspersky reported wasn’t the one that had been used to apply the hack. There was more than one rogue file in the uploads directory folders. I removed these as well.
Then I turned to the original vulnerability. I checked the theme and found that although it had been updated for compatibility with the latest version of WordPress, the vulnerable file was still being delivered.
I contacted the theme authors and they replied with this apology.
We updated all the themes a while ago (the latest updates), xxxxxxx was removed and functionality replaced with default WP media management functionality.
I have now updated the site to the latest version of WordPress, updated to the latest version of the theme, removed the vulnerability from the theme and taken a new backup.
Recreating the problem
Had I not discovered that the vulnerable file could quite simply be deleted I would have gone on to applying some fixes myself. In order to demonstrate that the fixes worked I would have needed to create a test case.
The following HTML is all that is needed to demonstrate the vulnerability.
<form action="full URL of vulnerable file" method="post" enctype="multipart/form-data"> <input type="file" name="field_the_file_looks_for" /> <input type="submit" value="Send" /> </form>
Notice how the JSON reply tells you where it’s put the file!
This post has been sanitized
The details of the vulnerability have not been included in this post. If you want to know more then please get in touch. Contact me