Analysis of Attack Vector against WP Plugins

On the WPScan Vulnerability Database maintained by Sucuri, we can find many new plugins and themes every month. Of course, WP-ZEP is not God Almighty against these. Then you may wonder about:

• Which attack can WP-ZEP prevent?
• How many attacks can WP-ZEP prevent?

I’m with you!!

So I picked up the latest 50 vulnerabilities from WPScan DB, and dig into each attack vector one by one to investigate which can be prevented or not by WP-ZEP.

Introduction

To find out the prevention ability of WP-ZEP, I only picked up the vulnerable plugins which I can download for free. Then I got code differences between before and after fixing issues to start reading the code deeply. In many cases, exploitation reports in something like Packet Storm gave me a lot of help, but in some cases, I had to install these plugins into my PC to confirm the attack vectors.

Each vulnerability has its own attack vectors. Some of them are classified in a direct attack onto the plugin files, and some of them are classified in an indirect attack via WordPress core files. So at first, I must make clear the definition of “Attack Vector” itself. My definition here is:

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 several patterns. Here are the short descriptions of abbreviations in the latter part of this article.

Then I examined the prevention ability of IP Location Block in 0.2.1.0 based on the type of validation method, that is:

1. validate by Geolocation
2. validate by WP-ZEP

For example, 2. is available on “Validation Settings” as follows:

Results

Well then, let’s take a look at the results:

Study of Attack Vectors

The results gave me something of great interest when I sort by “Path”. The “PD” (Plugin Direct) and “FE” (Front End) are all in red. So I’d like to dive into these attack vectors.

Plugin Direct

Some plugin or theme authors tend to call their PHP files in wp-content/plugins/ and wp-content/themes/. The reason may be mainly for the performance.

But you know the WordPress programming model is basically event-driven, so such a direct call is not generally recommended from the WordPress security point of view.

[In almost every case there is no reason to allow code to be called directly]
(http://www.pritect.net/blog/wp-ultimate-csv-importer-3-7-1-critical-vulnerability
“by James Golovich”).

It’s a remarkable fact that a variety of vulnerabilities are there in this type of attack vector. And such a direct call should be blocked to prevent various vulnerabilities if it’s for the administrator.

Fortunately for me, some of these files include wp-load.php to get the WordPress context, which cases are indicated as “PD+”. It means that WP-ZEP has a chance to validate these. Moreover, almost all the above-listed “PD+” are related to admin (besides this). So I decided to make WP-ZEP prevent these types of direct access.

But “PD-“ (without +) is still in the red.

Front End

There was a vulnerability that allowed anyone to log in as an administrator without any fences by the following access:

http://example.com/?login_required=1&user=admin&...

In this type of vulnerability, the init action, which is always triggered by anybody who visits the public-facing pages, is hooked to some functions to make significant jobs for the administrator.

In this case, all we should do is filter out any malicious queries (i.e. “signature”) from the requests using whitelist or blacklist to prevent LFI, XSS, SQLI.

Conclusion

Before I finalized this investigation, the estimated amount of true positive against preventing zero-day exploitation by WP-ZEP in the real world was about 26% in version 0.2.0.8, but now 60% in 0.2.1.0.

Is it still low? – Yes it is.

So I’d like to make WP-ZEP have the ability to prevent the “Plugin Direct” (without *) vulnerability, which means the true positive becomes 80%!