Prevent exposure of wp-config.php

From July to September in 2015, 33 types of malicious requests to attempt exposing the wp-config.php via vulnerable plugins and themes had been observed on my site. I analyzed all of them to identify if IP Location Block can block them or not.

Unfortunately, I could not find all the causes of exposure because most of them were already removed from the WordPress repository. So I can’t say the right thing with confidence, but only 2 of these could be blocked by IP Location Block 0.2.1.5 and under even if they were from the forbidden countries.

In this article, I should clarify how to prevent exposure of wp-config.php against such malicious requests.

Analysis of Attack Vectors

Before showing the results, I should explain the description of the terms same as in the previous article.

Attack Vector = Type x Path

where:

• Type: The type of vulnerability that an attacker can abuse. For example, XSS, SQLI, LFI, and so on. Also, it includes certain parameters which are generally called “signature”.
• Path: The path to the entrance into WordPress where an attacker can deliver a certain type of vulnerability.

The “Path” can be categorized into below:

Here’s the table of 33 requests that were attempted to expose wp-config.php in my site. Most of them were disclosed recently.

IP Location Block 0.2.1.5 and under can only protect the Path of WP, while the PD (and probably N/A) can not because those plugins and themes never load the WordPress core.

What’s the cause?

As you can see, most of them had their own download function like download.php. Typical OMG code in there are like this:

<?php
$file = $_GET['file'];
if (file_exists('../../uploads/xxxx/'.$file)) {
    readfile('../../uploads/xxxx/'.$file);
    exit();
}
?>

This kind of vulnerability is caused by Directory Traversal attack.

I’m not sure why some authers tend to such a direct requesting without loading WordPress core (do they mind speed?), but they should know why so many WordPress plugins vulnerable and absolutely use some of WordPress framework unless they can’t keep their products secure by their own.

How to protect my site against such OMG code?

First and foremost, we should consider to make the Path transformed from PD and N/A to WP. If those plugins and themes would load WordPres core before they were excuted, IP Location Block can have a chance to block the attacks.

So we should force those plugins and themes to load the wp-load.php. To
achieve this, .htaccess in the plugins directory can be configured to
rewrite a request to rewrite.php by following directives:

# BEGIN IP Location Block
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /wp-content/plugins/ip-location-block/
RewriteCond %{REQUEST_URI} !ip-location-block/rewrite.php$
RewriteRule ^.*.php$ rewrite.php [L]
</IfModule>
# END IP Location Block

The absolute path /wp-content/plugins/ should be changed according to your site configuration. And here’s the example of .htaccess in the themes directory:

# BEGIN IP Location Block
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /wp-content/plugins/ip-location-block/
RewriteRule ^.*.php$ rewrite.php [L]
</IfModule>
# END IP Location Block

Those will redirect a request, which is pointed to /wp-content/plugins/.../*.php and to /wp-content/themes/.../*.php, to the rewrite.php in IP Location Block to load wp-load.php and then it will be validated by country code or WP-ZEP .

Another consideration for Type in Attack Vector is that IP Location Block should filter out the “Malicious signature” such as wp-config.php or passwd  to defence against attacks from the permitted countries.

I’ll provide you this functionarity in the next release (may be 0.2.2.0) !!