Only One WordPress Security Plugin Fully Protected Against a Recently Disclosed Arbitrary File Upload Vulnerability

Last week we did our first test to see what protection that WordPress security plugins can provide against the exploitation of the vulnerabilities in plugins. The results for a persistent cross-site scripting (XSS) vulnerability were not good, with only 2 of the 11 plugins tested providing any protection and even the protection in those two was easily bypassed.

Earlier this week we disclosed a set of arbitrary file upload vulnerabilities in four plugins by the same developer. While these vulnerabilities are of the type that are likely to be exploited (you can now know how likely vulnerabilities are to be exploited with our service), after we contacted the developer, they took two weeks to fix one and the other three have yet to be fixed two months later. That shows a couple of the problems with being able to protect against plugin vulnerabilities at this time, one being that vulnerabilities are not fixed in a timely manner and the other being that simply keeping you plugins up to date will not protect you.

An arbitrary file upload vulnerability allows an attacker to upload any type of file to the website. They would usually use that upload .php file that contains PHP code, which provide them further access to the website or allows them to take further malicious actions.

To see how security plugins would protect against this type of vulnerability we will test them out against the arbitrary file upload vulnerability that exists in N-Media Post Front-end Form simply because that was the first one of those plugins that we discovered had a vulnerability, which we found while looking in to the possibility that plugin had a vulnerability elsewhere in its code.

From what we see monitoring hacking attempts it looks as if arbitrary file upload vulnerabilities are the most frequently targeted vulnerability in WordPress plugins and from cleaning up many hacked WordPress websites they also frequently are the cause of websites being hacked. Based on that you would expect that if security plugins could protect against some type of vulnerability this would be one type that they would. It also seems like it should be relatively easy to monitor files that are being uploaded directly to the website, by check the contents $_FILES variable of PHP, increasing the chances they can stop this type of issue in its most basic form.

Continuing something that came up while working on the first test, we first trying exploiting the vulnerability in and then for plugins that we found stop exploitation we look if we can find a way to bypass that protection without looking at the underlying code (black-box testing).

Testing Procedure

For each of the tested plugin we set up a fresh install of WordPress 4.6.1, installed the latest version of N-Media Post Front-end Form, and installed the latest version of the security plugin. We tried to enable any feature of the plugin that could possibly have an impact on stopping exploitation of the vulnerability.

We used the proof of concept included in our previous post and uploaded a file with a .php extension that contains PHP code.

The 12 plugins we tested include the security plugins listed in the Popular plugins section of the Plugin Directory and some others that look to intended to prevent this type of situation. If you would like to see an additional plugin included in future testing please leave a comment on the post or contact us.

Results

Only three of the plugins tested, Anti-Malware Security and Brute-Force Firewall, NinjaFirewall (WP Edition) and Wordfence, prevented the vulnerability from being exploited in the original test. But we were able to easily bypass the protection in two of those, Anti-Malware Security and Brute-Force Firewall and Wordfence, without even looking the at the underlying source code of how their protection works (that source code would be available to anyone looking to exploit them). With both plugins simply uploading a file with .jpg extension instead of .php evaded their protection. Since you also specify what the file will be named on the server with this vulnerability, the extension of the uploaded file doesn’t dictate the extension of the file on the server.

It is interesting to note that the only plugin to fully protect against the vulnerability, NinjaFirewall (WP Edition), was one of the least popular of the plugins tested, with only 10,000+ active installs. That is a good reminder that the popularity of security plugins has little bearing on the protection they provide.

The full results are below: