Has your wordpress website been attacked? Here’s how to refresh it

We have revised some websites developed in Wordpress which hadn’t been updated for some time, in order to make some of these Wordpress websites compliant to the new privacy rules and, in particular, to the use of cookies report which entered into force on June 2^nd 2015.

Visiting the “Plugins” page of some of these websites, we noticed a unusual message, repeated for the most of its plugins:

The plugin has been deactivated due to an error: The plugin does not have a valid header.

Just few researches has been necessary for understanding that it was due to the fact that those sites had been attacked by a malware.

Indeed, a significant number of wordpress php files and installed plugins started with a very suspect single line of code:

?php if(!isset($GLOBALS["\x61\156\x75\156\x61"])) { $ua=strtolower($_SERVER["\x48\124\x54\120\x5f\125\x53\105\x52\137\x41\107\x45\116\x54"]); if ((! strstr($ua,"\x6d\163\x69\145")) and (! strstr($ua,"\x72\166\x3a\61\x31"))) $GLOBALS["\x61\156\x75\156\x61"]=1; } ?...

Also some backup files had the same problem, in this way, refreshing the system to a previous version was impossible.

 

Here’s the method we adopted for refreshing Wordpress websites which had been compromised by the attack

Firstly, we have analysed the malware code. In all the files we noticed a recurrent pattern at the very beginning of the string ()

Then, as first action, we have verified that the current user was allowed to write on all the files in the root of the compromised website, after that, we used  the following command (always in the root through a ssh)

find . -type f -exec sed -ri '1 s/.*<\?php if\(\!isset\(\$GLOBALS.*7860msvd.*fklweyuxit-1; \?>//g' {} +

The first part of the command (find) searches for all the files in the current folder and in its subfolders, then a list is passed to the following command (sed), it looks for a string beginning, containing and ending with the implicated types. When it’s found, it’s removed from the file.

In this way, the malware has been removed from each file.

This has been enough for solving the original problem: the fact that the plugins were deactivated by visiting the “Plugins”page.

However, for an additional check, we have installed on every site a plugin called GOTMLS and then we have launched the website scan. In some cases the previous command has been enough for solving the problem, in others, the plugin has found further critical factors which have been subsequently solved by the same plugin. Obviously, the apache user (or www-data if you’re on Ubuntu) has to be allowed to write on all the files in the website root for fixing them.

 

 

At this point it has been possible to update Wordpress and all the plugins to the latest version for preventing the risk of new attacks.

Finally, we had applied a more strict permission policy to the files. Here there’s the commands sequence that we have used for setting the permissions on the files and folders of each Wordpress website:

 

# cd /var/www/html/

# chown -R filippo:filippo root_del_sito

# chmod -R 755 root_del_sito //only the user “filippo” is allowed to write on the website root and on the subsequent folders.

# cd root_del_sito/wp-content

# chown -R filippo:apache uploads

# chmod -R 775 uploads //while here also Apache can write on  the “uploads” folder. 

If there were other specific folders where some users have to be allowed to write or set permissions

# cd /var/www/html/root_del_sito //then let’s go back to the website root

# find . -iname "*.php" | xargs chmod 755

# find . -iname "*.php" | xargs chown filippo:filippo //if there were some exposed php files left after the alteration of the permissions in the root subfolders, in this way we can protect them.

# find . -iname ".htaccess" | xargs chmod 744

# find . -iname ".htaccess" | xargs chown filippo:filippo //the same has been done for Apache configuration files.

 

In this way we have refreshed compromised websites and, with a quite “strict” permissions policy, we have avoided future malware attacks to our php files.

The next step has consisted in verifying if there were unknown users with an administrator role (we have found one called “backup”), then we have changed the passwords to the administrators.

 

Have you ever been victim of similar attacks on your Wordpress websites? Which method have you adopted for refreshing the damaged websites?

Let us know how you have refreshed your Wordpress websites from malware!