Protect Against WordPress Brute Force Amplification Attack
It seems the WordPress xmlrpc.php file is the target of another type of attack. Before, it was the XML-RPC Pingback Vulnerability. Now, it is the Brute Force Amplification Attack. This post explains what you need to know and then cuts to the chase with several ways to protect your site against this new malicious exploit, as well as all other related threats.
What is XML-RPC?
Before getting into protecting the xmlrpc.php file, it is important to understand what it does. As explained here:
[XML-RPC is] a spec and a set of implementations that allow software running on disparate operating systems, running in different environments to make procedure calls over the Internet. It’s remote procedure calling using HTTP as the transport and XML as the encoding. XML-RPC is designed to be as simple as possible, while allowing complex data structures to be transmitted, processed and returned.
If you’re scratching your head, basically that means that XML-RPC enables remote platforms to interact with each other over the internet. More specifically, the WordPress xmlrpc.php file enables external applications to connect, transmit, and process data.
Do I need XML-RPC?
If you have to ask, chances are you do NOT need the xmlrpc.php file. But there are various plugins that may make use of WP’s XML-RPC functionality for various remote operations, so if in doubt ask the developers of whichever plugins you are using. In my experience, 99% of WordPress-powered sites do not use the xmlrpc.php file whatsoever. So as long as you are sure that you don’t need the file, it’s fine to delete, block, or disable it. Read on for numerous ways to secure your site against XML-RPC threats.
Protect via plugin
If adding/maintaining another plugin is your thing, then head on over to the WordPress Plugin Directory and search for “xmlrpc plugin” or similar. I’m sure there is at least one plugin that is suitable for disabling xmlrpc.php.
Protect via .htaccess
If you are savvy with .htaccess, there are numerous ways to go about blocking access to the xmlrpc.php file. Here are two of the simplest ways of doing so:
Block xmlrpc.php via RedirectMatch
# protect xmlrpc
<IfModule mod_alias.c>
RedirectMatch 403 (?i)/xmlrpc.php
</IfModule>The nice thing about this technique is that it doesn’t matter where you have installed WordPress. The xmlrpc.php file will be protected regardless of its location in the directory structure (e.g., /wp/xmlrpc.php, /wordpress/xmlrpc.php, /whatever/xmlrpc.php, etc.). It’s also case-insensitive, so you’re protected against any “all-cap” attack variations.
Block xmlrpc.php via Order/Deny
# protect xmlrpc
<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>Either of these snippets work perfectly to protect the xmlrpc.php file by blocking all access to it. This is my preferred method of securing against XML-RPC attacks. It’s easy, thorough, reliable, and maintenance-free. Of course, it is possible to customize these xmlrpc.php .htaccess techniques to do stuff like allow access from specific IP addresses and redirecting blocked requests to a specific page.
Alternately, you can block access using mod_rewrite via a variety of request variables. With .htaccess, there are many possibilities.
Protect via custom function
If you don’t want to use another plugin, and don’t want to mess with .htaccess, another way to protect against the Brute Force Amplification Attack specifically is to disable the system.multicall functionality of the xmlrpc.php file. Here is the function that you can add directly via your theme’s functions.php file:
function shapeSpace_disable_xmlrpc($methods) {
unset($methods['system.multicall']);
unset($methods['system.listMethods']);
unset($methods['system.getCapabilities']);
unset($methods['pingback.extensions.getPingbacks']);
unset($methods['pingback.ping']);
return $methods;
}
add_filter('xmlrpc_methods', 'shapeSpace_disable_xmlrpc');And then if you also want to remove the “X-Pingback” header from your web pages:
function shapeSpace_disable_xmlrpc_header() {
header_remove('X-Pingback');
}
add_action('wp', 'shapeSpace_disable_xmlrpc_header', 9999);Some pros and cons about this “custom function” technique:
- Pro – no need to maintain another plugin
- Pro – no need for .htaccess
- Con – is theme-specific
So the pros are self-explanatory, but the con may be elaborated upon. By “theme-specific”, that basically means that the function will help protect only when the theme that includes it is active. That is, if you switch themes, you lose protection unless you add the function to your new theme. Of course, a simple way to make it not theme-dependent, is to add the code via simple custom plugin.
Bottom Line
Be aware that the WordPress xmlrpc.php file is a huge attack vector. If you’re running the latest version of WordPress, technically you have nothing to worry about, but even so the file remains a perpetual target for attackers. The bad guys are constantly scanning for vulnerabilities related to pingbacks, amplification attacks, brute-force attacks, and all sorts of other mischief.
With that in mind, it’s advisable to protect your site according to your own security strategy. If you’re not using the file, I recommend disabling, deleting, or denying access.
