WordPress xmlrpc.php vulnerability





Last Updated on 09/08/2014 by dboth

This problem is not limited to Linux web hosts but I include it here because many WordPress installations that run on Linux are affected by this vulnerability.

The problem

There is a vulnerability in the xmlrpc.php file that allows intruders to have access to certain aspects of the host on which WordPress is installed and it can also allow crackers access to information about your network.

Symptoms

The symptom I first noticed was a higher than normal CPU usage. This was not a large difference but it was definitely noticeable using htop or top.

There was continuous load as shown by the netstat command of anywhere from 4-8 connections on my own server and upwards of 100-125 connections on a remote one that I manage. Almost all connections seem to be from Europe and west Asia, France, Netherlands, Great Britain, Afganistan, Russia, and a few others.

The /var/log/httpd/access_log file contained lines that look like the following.

80.82.65.17 - - [06/Sep/2014:19:16:33 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
176.227.196.90 - - [06/Sep/2014:19:16:33 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
176.227.196.90 - - [06/Sep/2014:19:16:34 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
80.82.65.17 - - [06/Sep/2014:19:16:34 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
195.154.105.219 - - [06/Sep/2014:19:16:34 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
195.154.105.219 - - [06/Sep/2014:19:16:35 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
176.227.196.90 - - [06/Sep/2014:19:16:35 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
80.82.65.17 - - [06/Sep/2014:19:16:35 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
176.227.196.90 - - [06/Sep/2014:19:16:35 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
80.82.65.17 - - [06/Sep/2014:19:16:36 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
195.154.105.219 - - [06/Sep/2014:19:16:36 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" 
176.227.196.90 - - [06/Sep/2014:19:16:36 -0400] "POST /xmlrpc.php HTTP/1.0" 200 370 "-" "Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)"

This problem is not limited to Linux web hosts but I include it here because many WordPress installations that run on Linux are affected by this vulnerability.

The resolution

Here is what I did to block these attempts to utilize the wordpress-xmlrpc-pingback-vulnerability on my CentOS 6.5 web server. This assumes that the Fail2Ban package is already installed on your WordPress host and is working properly.

Fail2Ban is a Free Open Source Software package that scans the log files for various system services including SSH and HTTPD in order to identify cracking attempts. It can then dynamically add a firewall rule that blocks the suspect IP address for a specified period of time.

I created the file /etc/fail2ban/filter.d/apache-xmlrpc.conf with the following content.

[Definition]
 failregex = ^<HOST> .*POST .*xmlrpc\.php.*
 ignoreregex =

I added the following stanza to /etc/fail2ban/jail.local. If jail.local does not exist, copy jail.conf to jail.local and modify jail.local. Do not modify jail.conf as it may get overwritten during updates to Fail2Ban.

[apache-xmlrpc]
 
 enabled  = true
 port     = http
 filter   = apache-xmlrpc
 action   = iptables[name=XMLRP, port=http, protocol=tcp]
               sendmail-whois[name=XMLRP, dest=me@example.com]
 logpath  = /var/log/httpd/access_log
 maxretry = 3
 bantime  = 28800

This is a bit more than any of the web sites I found through Google that described this fix. I added the sendmail-whois line to the apache-xmlrpc line in /etc/fail2ban/jail.local to send me email containing the results from whiois when it blocks an access attempt. I also configured for an 8-hour ban-time. After that, the firewall rule is discarded. Of course it will be reinstated if more attempts occur from this same IP Address.

After making these changes, restart Fail2Ban. The iptables-save command should now show the new chain for fail2ban-XMLRP along with a number of lines rejecting any attempts to connect from remote hosts that are trying to exploit this vulnerability.

You should also receive email notifications when Fail2Ban starts and stops each jail, and each time an IP address is blocked. I usually save these emails for later analysis as they contain the whois results for the offending IP Address.

:OUTPUT ACCEPT [113541:8198249]
COMMIT
# Completed on Sun Sep  7 18:44:49 2014
# Generated by iptables-save v1.4.7 on Sun Sep  7 18:44:49 2014
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [32654:10017982]
:fail2ban-SSH - [0:0]
:fail2ban-XMLRP - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -p tcp -m tcp --dport 80 -j fail2ban-XMLRP
...
<snip>
...
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -j RETURN
-A fail2ban-XMLRP -s 80.82.65.17/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-XMLRP -s 176.227.196.90/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-XMLRP -s 195.154.105.219/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-XMLRP -j RETURN
COMMIT
# Completed on Sun Sep  7 18:44:49 2014

Your IPTables will be different, but you can see in the above example the lines generated by the Fail2Ban program. These lines mean that Fail2Ban is working.