: WordPress XML-RPC attack Yesterday I suffered a DDoS attack on a WordPress site. I had 21,443 hits with HTTP Status code 404 and a Bandwidth of 711.85 MB. Also, CPU usage went to 100%. Logs

@Kevin317

XML-RPC is Being Used to Brute Force Passwords

Aside from the security issues mentioned in the other answers, there has been an uptick in brute-force attacks against xmlrpc.php. These attacks are trying to gain passwords. Sucuri has some nice documentation on this.

This is not a bug in the software. WP's XML-RPC implementation includes authentication routines. Attackers have switched to this technique as it is often not blocked by various brute force plugins and it is faster.

If you do not use any services that require XML-RPC, you can just disable it. I've been recommending setting the file permissions to 000.

This way you can easily revert the change if it causes issues. Note that pingbacks use xml-rpc, so this will break pingbacks if you have them enabled.

We've seen this attack rise and fall on servers we manage. Most of the time it goes undetected on shared hosting systems without any type of web application firewall. We've only seen it really impact servers when multiple sites get hit at the same time and/or the hosting providers are using CloudLinux to control resources on a per-account basis.

Update:

XML-RPC DOS issue or Brute Force?

Coincidentally, we just had a customer's server alert for load issues. On investigation, we found a WP site under attack. I did a little extra analysis and came up with this check to determine if you are suffering from a XML-RPC DOS Issue or password attack.

There are two clear signs of a XML-RPC DoS Exploit:


Multiple outbound connections to remote web sites.
High rate of traffic to xmlrpc.php


With a brute force attack, you would not see these outbound requests to a remote web server.

Looking at Apache Status page we see:

7-0 17954 0/11/11 _ 0.96 2 16149 0.0 0.01 0.01 attacker.com localhost POST /xmlrpc.php HTTP/1.0
8-0 17962 0/10/10 _ 1.14 0 0 0.0 0.00 0.00 attacker.com localhost POST /xmlrpc.php HTTP/1.0
9-0 17968 0/10/10 _ 0.77 3 0 0.0 0.00 0.00 attacker.com localhost POST /xmlrpc.php HTTP/1.0


localhost is the host under attack.

attacker.com is a remote system flooding in requests to xmlrpc.php.

Looking at netstat (IP addresses scrubbed for privacy reasons):

tcp 0 0 localhost:39254 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39248 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39251 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39250 remotehost:80 TIME_WAIT -
tcp 0 1 localhost:39260 remotehost:80 FIN_WAIT1 -
tcp 0 0 localhost:39257 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39258 remotehost:80 TIME_WAIT -
tcp 0 0 localhost:39237 remotehost:80 TIME_WAIT -


remotehost is the victim of the DoS attack.

Typically, your localhost should not be making calls to a remote web server unless you are using some sort of remote API. Even then, seeing hundreds of such connections is highly suspect. Note that we saw both ports 80 and 443 under attack.

To confirm the type of attack, we captured some traffic and found this payload:

POST /xmlrpc.php HTTP/1.0

Host: localhost

Content-type: text/xml

Content-length: 268

User-agent: Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)

Connection: close



<?xmlversion="1.0"?><methodCall><methodName>pingback.ping</methodName><params><param><value><string>http://victim.com</string></value></param><param><value><string>http://localhost/blog/just-another-post/</string></value></param></params></methodCall>


In this case localhost was actually an IP address and not a domain name. I am not sure if an IP is required for this attack, I would not think so, but it would mean you eliminate the need for DNS lookups both for attacking and for scanning.

Sucuri has a good write up WP XMLRPC DoS attack too as does Incapsula.

Vote Up Vote Down

@Becky754

I study and research advanced processes for defense and detection for such things. The answer from Rarst is technically correct. No question. However, this smells of what is extremely typical- let me explain.

A number of systems were compromised and Wordpress sites were likely bulk attacked and are now targeting known vulnerabilities almost randomly. It does not matter if the sites have Wordpress installed or not. Often, these attacks try and take advantage of the same vulnerability that succeeded on the compromised system, but may also use a dictionary-database of vulnerabilities to seek more compromised systems.

The single most attacked PHP web based application is Wordpress. There are two reasons for this; one- it' popularity and install base, two- hacker success in the past and the vulnerabilities that have existed in the software make it highly likely that a hacker will have success. It is not that Wordpress is poorly coded. It is well coded. It is more that Wordpress is complicated and involved code and vulnerabilities have and may continue to exist.

This is not a DDoS or DoS. Just script-Kiddies doing what they do. Simply block the attacks for now. They will stop eventually. It is best to stop these access at the furthest point from the server if possible. Often this is a firewall or a configurable router. If these are not available, then I suggest using ModSecurity found at www.modsecurity.org/. This is a highly effective firewall-style software meant to run on the web server and integrates into Apache and IIS.

Make sure you are running a stabilized version of Wordpress. It is important to check periodically to make sure you are running updated software. As well, make sure that the plug-ins you are using are secure too.

It can be difficult to track this stuff down, however, there is a clearing-house of security notices that I can recommend. This is the de-facto place to go though other sites with the same data exist. You can research vulnerabilities here www.us-cert.gov/ncas and keep up to date with e-mail notices. I would highly recommend that every webmaster sign-up for these notices or check this site often.

You can follow this group using twitter too: twitter.com/uscert_gov
Here is the top tweet in the list as of this writing:

WordPress Releases Security Update: Original release date: September 04, 2014 WordPress 3.9.2 has been released... 1.usa.gov/1ryt7bZ

Vote Up Vote Down

@Kaufman445

This was only a DDoS attack or they were trying to hack my site?


There is no way to tell the functional aspect of it without seeing POST payload. Since it was aimed at interactive endpoint I would assume that had some point, other than simply exhausting your resources. Although they might have been trying (succeeding? no way to tell without seeing payloads) in using this specific endpoint to increase the load produced.


Was I under attack or they used my site to attack others? (all IPs entries are different)


There is number of techniques that "bounce" of site to make it involuntary participate in attacks. I am not that into security to say if XML-RPC is suitable for it, but it wouldn't be my first thought.


What is the best way to stop this? Modify .htaccess file or Add a filter in functions.php


The lower level the better. So blocking it on web server level is better than PHP level. Blocking it on network level is better than web server level (but gets farther into realm of hosting taking care of that and/or costly solutions).

Vote Up Vote Down