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.
- 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:
|Abbreviation of Path||Description|
|WP||It loads WordPress Core through
|PD||It is called Plugin Directly without loading WP Core.|
|N/A||Unknown because the source code is Not Available.|
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:
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
.htaccess in the plugins directory can be configured to
rewrite a request to
rewrite.php by following directives:
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:
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
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) !!
Leave a Reply