Malware attacking the WordPress Download Manager plugin

• May 31, 2015
• technology  
• hackers  
• security  
• wordpress  

I’ve seen three attempts to exploit the WordPress Download Manager plugin in the past couple of days and forty since I saw the first one on 2015-02-06. Not a huge number which is why it escaped my attention until now when I saw several attacks in a short interval. The signature is a “POST /” request with payloads like the following (these are from the most recent attacks):

action=wpdm_ajax_call&user_login=admin-jonns&execute=wp_insert_user&role=administrator&user_pass=1213141516

action=wpdm_ajax_call&user_login=userdemo&execute=wp_insert_user&role=administrator&user_pass=demopassword

action=wpdm_ajax_call&user_login=uLIr2a&execute=wp_insert_user&role=administrator&user_pass=c3oTzz

This article at blog.sucuri.net provides details about the nature of the attack.

Can such attacks be detected and blocked in a generic manner? What are the rules or minimal requirements for issuing a POST request to the WordPress root document? The WordPress documentation doesn’t answer that question; at least not in a manner someone who doesn’t write plugins can find and understand. A lot of Googling didn’t find any answers. I’ve asked how to determine if a post request is valid on the WordPress support forums but so far no answers.

Since I’ve never seen a legitimate “POST /” request at my site I’ve implemented the following .htaccess rule:

# Detect attempts to POST / without an authentication token. We regularly see
# malware attempt to create accounts via that API.
RewriteCond %{REQUEST_METHOD} POST [NC]
RewriteCond %{REQUEST_URI} =/ [NC]
RewriteCond %{HTTP_REFERER} !^https?:// [NC,OR]
RewriteCond %{HTTP_COOKIE} !wordpress_test_cookie=WP\+Cookie\+check [NC,OR]
RewriteCond %{HTTP_COOKIE} !wordpress_logged_in_ [NC,OR]
RewriteCond %{THE_REQUEST} \sHTTP/(?:0\.9|1\.0)$ [NC]
RewriteRule ^ /blocked.php [END,E=error-notes:invalid-wp-root-post]

That rule is almost certainly wrong. For example, I have no reason to believe that such requests should include the cookie “wordpress_test_cookie“. I’ve included those requirements because I’ve noticed that a lot of malware violates those conditions even where they are known to be required. As I’ve never seen a legitimate post to my WordPress root document it seems reasonable to be too strict.