Tag Archives: WordPress

Strengthen Your IDS/IPS With Known WordPress Plugins

I maintain a dashboard in my Splunk environment to monitor for potential hacking attempts against my web servers. One way that I do this is to monitor for sources that are generating repeated 404 errors looking for exploitable web pages on the sites. During this recent review, I became aware of a number of new WordPress plugins that hackers are attempting to exploit. The URLs are easy to spot. They all begin with /wp-content/plugins/ followed by the name of plugin. The plugins that I saw are not even installed on my server, so these are obviously hackers looking for a way in.

This got me thinking about how I can use this information to strengthen my security with my intrusion detection and prevention systems.

Controlled WordPress Environment

For my particular installation, I am the only administrator for all of the hosted WordPress sites. This means that I have complete control over which plugins are installed. Because of this, I can use the solution that follows.

Identify Installed Plugins

The first step in my solution is to identify the list of currently installed plugins across all of my sites. From the directory where all of my sites are stored, I was able to use the following Linux command to get a list of plugins:

find . -type d -name plugins -exec ls {} \; | sort -u | grep -v "\.php$"

This command does the following:

  • find – Looks for all directories with the name of “plugins” and lists the contents of each directory.
  • sort – The sort command takes all of the plugin directory names, sorts them and removes duplicates.
  • grep – The plugins directory in WordPress may contain some PHP files in the directory. We can ignore these. This grep statement removes anything found to end with a .php extension.

Configure a Fail2Ban Filter

In order to secure my environment from these malicious invaders, I decided to again use Fail2Ban. If someone attempts to access a plugin that isn’t in a list of known plugins, then I want to immediately block any further access from that IP address. Fail2Ban makes this process very each.

Assuming that my list of installed plugins was pluginA, pluginB and pluginC, my filter file would look like the following:

failregex = ^<HOST> -.* \[.*\] "(GET|POST) \/wp-content\/plugins\/
ignoreregex = ^<HOST> .* "(GET|POST) \/wp-content\/plugins\/pluginA\/
  ^<HOST> .* "(GET|POST) \/wp-content\/plugins\/pluginB\/
  ^<HOST> .* "(GET|POST) \/wp-content\/plugins\/pluginC\/

This filter starts by triggering on any attempt made against the wp-content/plugins URL, but then provides exclusions for each plugin that is allowed.

I store this in a filter file that I named wp-plugin.conf in /etc/fail2ban/filter.d. I then add the following to my jail.local in /etc/fail2ban:

enabled  = true
port     = http,https
filter   = wp-plugin
logpath  = /var/log/web/*access.log
maxretry = 1
bantime  = 2592000

This creates a jail with the wp-plugin filter. It monitors all of my web access logs and blocks a sender after 1 malicious attempt. Once triggered, the user is blocked for 2592000 seconds (30 days).

With this in place, restart the Fail2Ban service and a new layer of protection will be added to your security defenses.

Timthumb.php Remote Execution Vulnerability in WordPress

This morning, while going through my e-mails, I saw that my IDS system was seeing a lot of attempts against a timthumb.php file on my web sites. This seemed a little suspicious, so I headed out to Google to see what was going on. I started searching on “timthumb.php” and very quickly, Google gave me a suggestion of “timthumb.php exploit”. Yep, my suspicions were warranted.

Vulnerability Explained

This apparently isn’t a new vulnerability. It was a zero-day attack identified back in 2014. However, the fact that hackers are still trying to exploit it probably means that there are still web sites out on the web that haven’t been patched for this vulnerability.

The PHP script is used in a number of different themes for WordPress. The hacker exploits a bug in the software that allows the code to source an “image” from a remote web site. The following video does an excellent job of showing you the exploit.

Am I At Risk?

First task for me was to see if this is a vulnerability that affects me. I use Linux for all of my web servers. I was able to use one of the following commands to see if this code was implemented in any of my sites…

locate timthumb.php
cd /PATH_TO_WEB_SERVER_ROOT (fill in with the actual path to your web server)
find . -name timthumb.php

Luckily, I did not find this being used on any of our themes. If you find this file in your environment, you might want to checkout the post by Sucuri Blog with tips for protecting your environment.


Block Them Anyway!

I am a strong advocate about the fact that even though an exploit doesn’t exist on your system, you should still take action to block attempts. Someone was obviously maliciously attempt to attack your site and this is a clear piece of evidence as to how they do it. This attempt failed, but you can be sure they will keep trying until they find a way.

Another reasons to do this is to protect against site administrators loading themes with this vulnerability without your knowledge in the future. By putting the protection in place now, you can protect against future vulnerabilities created in your environment.

With that in mind, I decided to again use my Fail2Ban system to block individuals attempting to access this URL. The filter configuration file was very simple.

failregex = ^<HOST> - .*\/timthumb\.php
ignoreregex =

I added this filter to my jail configuration and restarted Fail2Ban. Now if anyone else attempts to access this URL that we don’t use, they will be automatically blocked from accessing our sites any further!

Simple Protection for WordPress From Malicious PHP Files

While recently auditing my web server logs for 404 errors, I came across a new pattern of hacker attempts. There were a number of attempts at opening PHP files with a specific name.  A quick search of the internet turned up an article, WordPress Security – Arbitrary File Upload in Gravity Forms by Rodrigo Escobar. The article does a fantastic job of explaining this particular exploit.

To summarize how the attack works, the hacker attempts to exploit a vulnerability identified in the Gravity Forms plugin in order to upload a malicious PHP file to the web site. The file is loaded into the wp-content/uploads path of WordPress. Upon successful upload, they can call the PHP file directly and the Apache server will execute the code. Luckily for me, I don’t have this plugin installed and the attempts on my site were all failed attempts.

The Pattern

As I researched this issue further, it dawned on me that a number of exploits against WordPress work in a similar fashion. The identify a means of exploiting a file upload mechanism within WordPress. These mechanisms are usually designed to place the uploaded file somewhere within the wp-content/uploads directory. The hacker then tries to call the file directly.

As far as I can tell, there should NEVER be a legitimate case where a PHP file needs to be uploaded to this directory and run directly from this directory. The directory was designed to be a place for storing images, videos and documents (Word, PowerPoint, PDFs, etc.). Therefore, if a PHP file does exist in this directory structure, a successful hacker attack is probably already underway.

Solution #1 – Fail2Ban

My first reaction was to setup a new rule in my Fail2Ban system. This software does a great job of monitoring system logs for recurring patterns and then taking automatic action to remedy the problem. In the case of my web applications, it directly manipulates the iptables (software firewall) to block the offender.

I wrote a new rule to identify the access of PHP files in the uploads directory. The regex expression was fairly straightforward:

^<HOST> -.*"(GET|POST).*(?i)\/wp-content\/uploads\/[^"+]*php.*".*"$

I configured the service to block a source IP after just one attempt of this URL pattern. I restarted the Fail2Ban service and did some testing. The filter worked as designed.

The problem with this solution is that if the hacker is successful the first time, they will still be able to perform the hack before the software blocks them for good. It’s unlikely that the hacker will be successful in just one shot, but I don’t want to take that risk.

Solution #2 – Deny Access in Apache Configuration

I decided that I wanted to configure Apache to deny access to any attempt at a PHP file in that directory. A quick search of the internet gave me a couple of good resources. I could make use of the FilesMatch directive in the Apache configuration file to identify a file pattern and block access to that file. I did some testing and I developed the following solution:

        <Directory "/path/to/wordpress/htdocs/wp-content/uploads">
                <FilesMatch "\.php$">
                        Order allow,deny
                        Deny from all

This information goes directly within the VirtualHost configuration for the WordPress web site in the Apache configuration files. After making the configuration change and restarting Apache, I dropped a test PHP file into various directory levels in wp-content/uploads. I tried accessing the PHP file and Apache always gave me a Forbidden access message.

Solution #3 – All of the Above!

The second solution is obviously the better approach. Even if the hacker is successful at uploading a file through an exploited upload mechanism, Apache will make sure that they never actually run the uploaded script. However, security works best in layers. Even though solution #2 is best, keep solution #1 in place too. Even though the hacker can’t succeed in running their script, allow the Fail2Ban software to recognize the attempt and block that hacker from any further exploit attempts on your site. They are obviously up to no good, so keep them from attempting any further harm.

Encrypting WordPress Administration

Since I am just setting up my WordPress blog, I thought that my first post should be about securing administration of the site. I wanted to have my site setup so that if you go to the admin login screen, you will be forced to do so over an encrypted connection on HTTPS. After doing a little bit of research, I found that there is a setting within WordPress that takes care of this for you.

To start the process, setup your site to be accessible by both HTTP and HTTPS. (This might be a good article for a future date!) After you are able to access your site with each of these protocols, then add the following line of text to your wp-config.php file:

define(‘FORCE_SSL_ADMIN’, true);

Now try to access your WordPress administration login and you will notice that it automatically redirects you to the HTTPS port.