1

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 show a lot of this entries:

...
119.71.5.44 - - [03/Sep/2014:18:34:57 -0700] "POST /xmlrpc.php HTTP/1.1" 404 34826 "-" "-"
197.149.17.195 - - [03/Sep/2014:18:35:01 -0700] "POST /xmlrpc.php HTTP/1.0" 404 34826 "-" "-"
210.206.226.130 - - [03/Sep/2014:18:35:04 -0700] "POST /xmlrpc.php HTTP/1.1" 404 34826 "-" "-"
...

I'm trying to understand this log.

  1. This was only a DDoS attack or they were trying to hack my site?
  2. Was I under attack or they used my site to attack others? (all IPs entries are different)
  3. What is the best way to stop this? Modify .htaccess file or Add a filter in functions.php

Update: Background information

  • I had WordPress 3.9.2. Now, I've updated WordPress to the latest version (4.0).
  • The site is on a shared hosting (with cPanel X).
  • The attack started on 02/Sep/2014 18:06:57 -0700 and ended 03/Sep/2014 21:22:24 -0700

Also, an hour before the attack the log shows this:

82.27.195.149 - - [02/Sep/2014:16:50:52 -0700] "GET /xmlrpc.php HTTP/1.1" 200 42 "-" "Mozilla/5.0 (Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20100101 Firefox/8.0"
82.27.195.149 - - [02/Sep/2014:16:50:54 -0700] "GET /wp-login.php HTTP/1.1" 200 2663 "-" "Mozilla/5.0 (Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20100101 Firefox/8.0"

And two hours after it started I've found this:

184.176.42.181 - - [02/Sep/2014:19:58:18 -0700] "GET /wp-login.php HTTP/1.1" 200 2663 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:18 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:18 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:19 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:19 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:20 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:20 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:20 -0700] "POST /wp-login.php HTTP/1.1" 200 2843 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"
184.176.42.181 - - [02/Sep/2014:19:58:21 -0700] "GET /blog/wp-login.php HTTP/1.1" 404 34107 "-" "Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1667.0 Safari/537.36"

So, I guess they were trying to hack my account through XML-RPC.

2

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 https://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 https://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: https://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... http://1.usa.gov/1ryt7bZ

|improve this answer|||||
  • Thanks for your answer! When you say "This is not a DDoS or DoS", how do you know that? It's the first time I face something like this and they definitely managed to exhaust my hosting resources – IvanRF Sep 5 '14 at 19:01
  • 1
    @IvanRF I typed a comment then deleted it. This should be much clearer. You were likely not the target of a DDoS attack but being used as a propagtor of an attack. I guess it is all perspective. The activity you were seeing was not a DDoS against you but a crack against Wordpress that in turn would as a collective of hacked systems direct a DDoS. I have experienced a DDoS from China. Believe me when I say, if the attack was directed at you- you would know. I was receiving 100,000+ requests per hour for months. Of course I was able to swat this attack away after a few hours of analysis. – closetnoc Sep 6 '14 at 0:00
  • In regard to solving this or trying to avoid it in the future, you recommended ModSecurity. I'm on a shared hosting (GoDaddy Deluxe), and I can't do much about that, but I think they use it. The fact that the response to POST /xmlrpc.php was an error code 404 means something? I mean, WordPress blocked the POST or was the hosting? or the attack was supposed to receive the 404 error? Thanks for sharing you knowledge! – IvanRF Sep 6 '14 at 20:07
  • @IvanRF I do not know anything about Wordpress. The 404 error means that the file was not found so I assume that /xmlrpc.php does not exist which should not be a problem. Remember that not all 404 errors indicate a problem. Some are actually good news. I did a review of ModSecurity a few years back and I liked what I saw. I also trust anything that jeffatrackaid says so if he makes a recommendation, I would also check that out. There are some security scan sites for Wordpress that may be good. google.com/?gws_rd=ssl#q=wordpress%20security%20scan – closetnoc Sep 6 '14 at 22:00
  • the file /xmlrpc.php exists, that's why asked about the 404 error. So, I'm guessing that WordPress or the firewall of the shared hosting blocked the attack somehow by returning 404 error. Thanks for the tip! – IvanRF Sep 7 '14 at 2:06
3

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).

|improve this answer|||||
  • Is it possible to see the POST payload somewhere? I mean, does a server save logs of that? – IvanRF Sep 4 '14 at 21:22
  • @IvanRF not by default I think. – Rarst Sep 4 '14 at 21:23
  • I've asked the hosting provider and I do not have a way to see payloads – IvanRF Sep 5 '14 at 18:37
3

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.

|improve this answer|||||
  • Three good answers. I like the detail you added. One up-vote for excellence! I still also recommend blocking access as far away from the web server as much as possible and using ModSecurity and creating a filter to block these access along with your recommendations. The more layers anyone can add, the better. Again. I love your answer! – closetnoc Sep 5 '14 at 16:08
  • If you are using WordPress, I highly recommend you follow Sucuri's blog. They have a lot of excellent WP security information they gleam from their malware detection and WAF services. Their WAF service is comparatively inexpensive and requires far less knowledge to implement than ModSecurity. CloudFlare is another option but I've recently seen some reports that their WAF has its shortcomings. – jeffatrackaid Sep 5 '14 at 16:15
  • Excellent info for WP users. I am not a blogger nor do I use a CMS other than the software I wrote which does a lot of security stuff and gives me the opportunity to test theories out on my site. Oddly, my site is less about providing information and more about testing theories in real-time. I will look into these suggestions of course. It could be helpful here at the very least. BTW- I tend to like your answers. I am glad you are here! – closetnoc Sep 5 '14 at 16:39
  • Just updated my post to include some analysis from an attack we just mitigated. – jeffatrackaid Sep 5 '14 at 18:45
  • @jeffatrackaid Thank you very much for your answer, it's really complete! I've added some background info. I'm on a shared hosting. Is there anyway to analyse traffic and see Apache Status? From cPanel I can only see the logs like the one in the question – IvanRF Sep 5 '14 at 18:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.