I’m with you!!
So I picked up latest 50 vulnerabilities from WPScan DB, and dig into the each attack vector one by one to investigate which can be prevented or not by WP-ZEP.
To find out the prevention ability of WP-ZEP, I only picked up the vulnerable plugins which I can download by 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 clarify the definition of “Attack Vector” itself. My definition here is:
The “Path” can be categorized into severals patterns. Here are the short descriptions of abbreviation in the later part of this article.
|Abbreviation of Path||Description|
|AX||Ajax / Post|
Then I examined the prevention ability of IP Geo Block in 2.1.0 based on the type of validation method, that are:
For example, 2. is available on “Validation Settings” as follows:
Well then, let’s take a look at the results:
|WP Business Intelligence Lite||<= 1.6.1||SQLI||PD+||OK||OK|
|EZ Portfolio||<= 1.0.1||XSS||AX||OK||OK|
|WonderPlugin Audio Player||<= 2.0||SQLI, XSS||AX||OK||OK|
|Aspose Cloud eBook Generator||<= 1.0||LFI||PD-||NG||NG|
|WPshop - eCommerce||<= 22.214.171.124||AFU||PD+||OK||OK|
|WP-ViperGB||<= 1.3.10||XSS, CSRF||AA||OK||OK|
|WordPress Survey & Poll||<= 1.1.7||SQLI||AX||OK||OK|
|WP Media Cleaner||<= 2.2.6||XSS||AA||OK||OK|
|WP Easy Slideshow||<= 1.0.3||CSRF||AA||OK||OK|
|N-Media Website Contact Form||<= 1.3.4||AFU||AX*||OK||NG|
|Tune Library||<= 1.5.4||SQLI||FE||NG||NG|
|Redirection Page||<= 1.2||CSRF, XSS||AA||OK||OK|
|PHP Event Calendar||<= 1.5||AFU||PD-||NG||NG|
|My Wish List||<= 1.4.1||XSS||FE||NG||NG|
|Mobile Domain||<= 1.5.2||CSRF, XSS||AA||OK||OK|
|MailChimp Subscribe Form||<= 1.1||RCE||PD-||NG||NG|
|IP Blacklist Cloud||<= 3.4||SQLI||AA||OK||OK|
|IP Blacklist Cloud||<= 3.42||LFI||FE||NG||NG|
|InBoundio Marketing||<= 2.0.3||RFU||PD-||NG||NG|
|Image Metadata Cruncher||<= 1.8||CSRF, XSS||AA||OK||OK|
|CrossSlide jQuery||<= 2.0.5||CSRF, XSS||AA||OK||OK|
|Aspose PDF Exporter||< 2.0||LFI||PD-||NG||NG|
|Aspose Importer & Exporter||<= 1.0||LFI||PD-||NG||NG|
|Aspose DOC Exporter||<= 1.0||LFI||PD-||NG||NG|
|WP Ultimate CSV Importer||<= 3.6.74||AB||PD+||OK||OK|
|WP Ultimate CSV Importer||<= 3.7.1||DT||PD+||OK||OK|
|WP Mobile Edition||<= 2.2.7||LFI||PD-||NG||NG|
|WP All Import||<= 3.2.3||RCE||AX||OK||OK|
|WP All Import||<= 3.2.4||CSRF, XSS||AX||OK||OK|
|Ultimate Member||<= 1.0.78||AFU||PD+||OK||OK|
|Ultimate Product Catalogue||<= 3.1.1||AFU||AX||OK||OK|
|Ultimate Product Catalogue||<= 3.1.2||SQLI||AX||OK||OK|
|Ultimate Product Catalogue||<= 3.1.2||SQLI||FE||NG||NG|
|TinyMCE Advanced||<= 4.1||CSRF||AX||OK||OK|
|Huge-IT Slider||<= 2.6.8||SQLI||AX||OK||OK|
|Simple Ads Manager||<= 2.5.94||AFU, SQLI||PD+||OK||OK|
|Related Posts for WordPress||<= 1.8.1||XSS||FE||NG||NG|
|Ajax Search Lite||<= 3.1||RCE||AX||OK||OK|
|Blubrry PowerPress||<= 6.0||XSS||AA||OK||OK|
|Plugin Performance Profiler||<= 126.96.36.199||XSS||AA||NG||NG|
|MiwoFTP||<= 1.0.5||CSRF, XSS||AA||OK||OK|
|MainWP Child||<= 188.8.131.52||AB||FE||NG||NG|
|WordPress Leads||<= 1.6.2||XSS||AX*||OK||NG|
|The total amount of OK||33||30|
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.
Some plugin or theme authors tend to call their PHP files in
wp-content/themes/. The reason may be mainly for
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 vulnerability 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
have 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 type of direct access.
But “PD-“ (without +) is still in red.
There was an vulnerability that allowed anyone to login as an administrator without any fences by following access:
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 to filter out any malicious queries (i.e. “signature”) from the requests using whitelist or blacklist to prevent LFI, XSS, SQLI.
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 2.0.8, but now 60% in 2.1.0.
Is it still low? – Yes it is.
So I’d like to make WP-ZEP have an ability to prevent the “Plugin Direct” (without *) vulnerability, which means the true positive becomes to 80% !!