Latest TweetsVerify any search engine or visitor via CLI Forward-Reverse Lookup perishablepress.com/cli-forwar…
Perishable Press

Protection for WordPress Pingback Vulnerability

It was recently reported about a WordPress Pingback Vulnerability, whereby an attacker has four potential ways to cause harm via xmlrpc.php, which is the file included in WordPress for XML-RPC Support (e.g., “pingbacks”). In this post, I offer a simple .htaccess technique to lock things down and protect against any meddling via the xmlrpc.php file.

Note: this technique is only recommended if you aren’t using XML-RPC for anything (e.g., pingbacks, Blogger, MovableType, etc.).
Update: Check out the alternate method to whitelist specific IPs while protecting against threats.

About the Pingback Vulnerability

According to this article, there are four ways that WP‘s XML-RPC API (specifically, the pingback.ping method) could be abused by an attacker:

  • Intel gathering — attacker may probe for specific ports in the target’s internal network
  • Port scanning — attacker may port-scan hosts in the internal network
  • DoS attacks — attacker may pingback via large number of sites for DoS attack
  • Router hacking — attacker may reconfigure an internal router on the network

Again, this is just a summary for reference, see the original article for more details on these various vulnerabilities as well as the pingback.ping method. No need to rehash everything here :)

Protect against WordPress Pingback Vulnerability

If you know you aren’t using the XML-RPC functionality for anything, and would like to protect against any vulnerabilities, you can lock things down with a simple slice of .htaccess:

# protect xmlrpc
<IfModule mod_alias.c>
	RedirectMatch 403 /xmlrpc.php
</IfModule>

Include that after any other rules in your site’s root .htaccess file and you should be good to go. To test that it’s working, try accessing the xmlrpc.php file in your browser. If it’s working, you’ll get a “403 – Forbidden message”. Tip: to redirect requests for xmlrpc.php to a custom page, modify the RedirectMatch like so:

# protect xmlrpc
<IfModule mod_alias.c>
	Redirect 301 /xmlrpc.php http://example.com/custom-page.php
</IfModule>

Alternate .htaccess method

Here is an alternate .htaccess technique for denying all access to xmlrpc.php:

# protect xmlrpc
<Files xmlrpc.php>
	Order Deny,Allow
	Deny from all
</Files>

Using this method, it’s possible to allow access to xmlrpc.php for specific IP addresses. For example, if you know your Blogger and/or MovableType IP(s), you can whitelist them by adding an “Allow” line for each, like so:

# protect xmlrpc
<Files xmlrpc.php>
	Order Deny,Allow
	Deny from all
	Allow from 123.456.789
	Allow from 321.654.987
</Files>

Note: if you use one of these .htaccess methods, keep in mind that it may be removed once the reported vulnerability is secured in a future version of WordPress.

For further discussion, check out my post at DigWP.com: The xmlrpc.php File and Site Security.

Thanks to Yael K. Miller for bringing this to my attention.

Jeff Starr
About the Author Jeff Starr = Creative thinker. Passionate about free and open Web.
Archives
23 responses
  1. Currently, several of my blogs are being hit with xmlrpc DDOS attacks. I’ve implemented Fail2Ban-fu to counter these attacks.

    For Fail2Ban Fans:

    /etc/fail2ban/filter.d/wp-xmlrpc.conf
    # Fail2Ban configuration file

    [INCLUDES]

    # Read common prefixes. If any customizations available -- read them from
    # common.local
    before = common.conf

    [Definition]
    _daemon = wp-xmlrpc

    # Option: failregex
    # Notes.: regex to match repeated xmlrpc attacks. The
    # host must be matched by a group named "host". The tag "" can
    # be used for standard IP/hostname matching and is only an alias for
    # (?:::f{4,6}:)?(?P[w-.^_]+)
    # Values: TEXT
    #
    failregex = s.*s.POST /xmlrpc.php HTTP/1.1"*.s.*

    # Option: ignoreregex
    # Notes.: regex to ignore. If this regex matches, the line is ignored.
    # Values: TEXT
    #
    ignoreregex =

    and /etc/fail2ban/jail.local
    [wp-xmlrpc]
    enabled = true
    filter = wp-xmlrpc
    action = iptables-multiport[name=wp-xmlrpc, port="80,443", protocol=tcp]
    sendmail-whois[name=wp-xmlrpc, dest=vacantserver@vacantserver.net]
    logpath = /home/*/logs/access_log
    maxretry = 10
    findtime = 60
    bantime = 3600

  2. i just had it again, an attack on 11 Domains and a Serverload of 100+ that got my server to its limits, and so i went to your site (http://perishablepress.com/wordpress-xmlrpc-pingback-vulnerability/) to copy the correct htaccess code together and i saw a comment that statet like “In WP 3.5.1 the issue was fixed” and Plugins ans such were no more needed, were removed or can be removed.

    Well, the truth is that there are more than enough ppl still trying to use/search for the vulnerability and that can easily bring your server down. With your htaccess code this is easily to avoid. I had just checked the processes, filtered the xmlrpc.php ones out and fixed these htaccess files. In less than 10 minutes the serverload normalized again.

    • Jeff Starr

      Thanks for the feedback, Sascha. The xmlrpc file indeed remains a huge target for attackers. I think it’s a good idea to disable/block it on any site for which it is not needed. Just helps to keep liability at a minimum.

[ Comments are closed for this post ]