Recently, we produced some work for a new client Beauty Box, Oxted whose WordPress
website had become the victim of hackers on multiple occasions. 5and3 were tasked with
recovering the data from the infected site, finding out what information/data had been affected, restoring the website to a working condition
and doing our best to ensure that attackers wouldn't be successful again.
Below are the four steps we took to help recover the site:
- How did we locate the hacker's code?
- How did the hackers get in?
- How did we recover the site?
- What have we done to stop it happening again?
1. How did we locate the hacker's code?
WordPress is a very popular blogging/cms platform and therefore there is a large incentive for hackers to attack it, due to its huge market share.
WordPress as a whole, is a very secure system which updates regularly fixing smaller and smaller exploits. With this in mind, we had a dig around
online looking for any known vulnerabilities that may have affected the server. This allowed us to get an idea of the sort of code we would be looking for.
The next step was to find the code the attackers had managed to execute on the server, and to ensure that none of that code would be transferred
when restoring the data, plugins or theme. We started with the uploads directory as we believed this would be the most likely place to be compromised
and found a few interesting PHP files.
We found several suspicious looking PHP files, all of which contained code that had been obfuscated in some way i.e. base64 encoding rot13 etc.
When attempting to decode this mess, we stumbled across a tool called UnPHP, which was very helpful in recursively decoding obfuscated PHP.
After decoding all the affected code, we found the hackers had managed to successfully upload a PHP shell backdoor called WSO (Fileman).
This particular backdoor script, is very popular and can be used to upload further hacking tools to a website i.e. Spambots (mass spam email
senders) and computer viruses, allowing execution of arbitrary code and giving access to basic terminal commands.
After finding such a large and powerful backdoor tool installed on the server, we assumed that we would find more similar scripts dotted
throughout the WordPress installation. After inspecting some further suspicious directories, we stumbled across an attack that seemed to have
been implemented by a different hacker.
This hacker had managed to upload a slightly more basic script. This program self replicated to every PHP file it could find that contained
index, default or config. It then took a copy of all of the files it could access on the server that it deemed important i.e. documents, videos,
images etc. and sat in the background and recorded any usernames and passwords that had been entered into the standard WordPress login form,
reporting them back to the hacker. It also allowed the hacker to upload exploits to the server from their website.
After doing a little more digging around in the plugins directory, we stumbled across another suspiciously named folder which contained a
further set of exploits. This hacker had managed to successfully upload a basic rootkit and utilised the escalated privileges that gave them
to install another copy of WSO (Fileman). This advanced backdoor script was then utilised to try and set the server up for virus distribution
via mass mailing. A file called "man1.exe" (a windows trojan virus) was uploaded to the server and the attackers attempted to start sending
emails via a file called "mail.php". Fortunately, the server was not configured to allow outgoing email and their code failed. It seems that
upon failure they then attempted to run a cleanup script that deleted most of the evidence. Thankfully for us, leaving behind a handy log file
which showed their attempts to get it working. Due to the fact that a cleanup was attempted, we assumed that they were attempting to avoid
discovery and intended to use the server for other purposes.
All in all, we found 6 different installations of rootkits, around 2407 instances of file stealer scripts, a windows virus and an email
spamming script.
2. How did the hackers get in?
We believe that all of the issues above were either caused by an insecure WordPress admin account or several vulnerabilities in a few
outdated plugins, distributed with the theme used on this website.
WordPress was configured with relatively standard settings and unfortunately the default admin. account was left active. If the password was insecure
this may have been the target of a brute force attack (unlikely), or the hackers may have even been able to guess it.
The most likely point of access in our opinion was via two of the installed plugins called showbiz and revslider, both of these plugins
came built into a paid theme from Envato and were massively out of date (by about 3 versions). After some research, we found several
articles listing numerous security vulnerabilities in these outdated versions of the plugins.
Slider Revolution Plugin Critical Vulnerability Being Exploited
Wordpress RevSlider File Upload and Execute Vulnerability
Another Revslider Vulnerability
We also found multiple entries in the client's log file which showed very unusual calls to the revslider plugin, asking for the sites
main config. file and getting a 200 (success) response.
3. How did we recover the site?
We set up a fresh copy of WordPress of the same version as the one the client already had, to cut down on compatibility issues. We then
imported the information from a cleaned up copy of the databases we had thankfully been able to grab from the server. Once we had the
data into a working copy of WordPress, we ran the update procedure to ensure that all of the latest security updates were in place.
Once the main site data was imported and WordPress was up to date, we had to look into finding a new theme for the client that didn't
have the same issues as the last one. To do this we repurposed one of the free themes provided on the WordPress theme directory. This
ensured that all of the plugins were open source and could be kept up to date to hopefully avoid security issues in the future.
This did mean a slight change to the look of the site but by implementing a free theme we could keep the website recovery costs down.
4. What have we done to stop it happening again?
Hackers tend to target the largest and most popular frameworks on the web. This is because if an exploit is found in one of the larger
frameworks there are potentially millions of targets that are vulnerable in exactly the same way. Therefore it is very important to keep
your version of WordPress fully up to date.
Another way we have reduced the scope of attack, is by cutting down on the number of plugins installed and ensuring that the plugins that
are installed, are well tested and late in their development cycle. Even one untested/insecure plugin could open your site up to hundreds
of potential attackers so choose your plugins wisely.
If the site was compromised again we would have to cut down the potential scope of attack by ensuring that all of the files on the server
have the correct owner and the strictest file permissions we can give them. This would cut down the amount of damage one of these programs could do by limiting it to only public directories.
To counter issues with password guessing and brute force attacks, we have implemented a basic .htaccess password protection to the back end.
This should prevent only the most dedicated hackers from brute forcing the passwords as they will have two layers of defence to get through.
We have also been careful and selected complicated passwords of numbers, letters and special characters.
In conclusion
We have found that a WordPress setup with a reasonable amount of security is still vulnerable if the theme you are using
contains dangerous or out of date plugins. The best way to keep your site safe, is to ensure everything is up to date, use secure passwords
and backup your website on a regular basis.