Andreas Hecht January 23rd, 2016

WordPress Security: Turn Off the XML-RPC Interface

Since WordPress version 3.5, the XML-RPC interface is activated by default. That wouldn't be too bad if WordPress weren't the world's most popular content management system. The interface does not only provide useful features but is also an important target for hackers. The invaders use the xmlrpc.php for their brute force attacks against WordPress more and more often, as attacking this interface is significantly more efficient and can be done with much less effort than other methods require.

This is Why the XML-RPC Interface Exists

Die xmlrpc.php The interface is a useful tool for the management of content. It is used to allow you to manage the website and write articles using the desktop and smartphone apps. It also takes care of pingbacks. The Pingback API enables a type of "connection" between the blogs while, at the same time, it's an interface used to manage WordPress using external programs. Not only the WordPress API, but also the Blogger API, the metaWeblog API, the Movable Type API, and the Pingback API are supported. However, most users don't need this interface, as they write their articles directly within WordPress. Also, the pingbacks of other blogs are not compulsively necessary.

Why the xmlrpc.php is a Security Risk

Password protected areas are an attractive target. The xmlrpc.php is one of them. As increasingly more bloggers protect the admin area of their websites, the attackers now focus on the management interface and let their brute force attacks target it. The issue is that attacks on the XML-RPC interface can be executed much more efficiently as it would be the case for attacks on the WordPress admin area. With the fitting tool, one request to the interface can cover an incredible 500 passwords. The file allows attackers to find out combinations of usernames and passwords by function calls to wp.getUsersBlogs or wp.getComments. As soon as a hacker sends a username and a password, the xmlrpc.php will respond and inform whether the combination is correct or not. This makes hacking a WordPress installation much more effective and promising. That turns the mostly unused interface into a severe security risk, and thus, it should be deactivated as soon as possible. Another, more general, advantage of turning it off is the increased website performance.

Deactivating the XML-RPC Interface

Since WordPress version 3.5, the XML-RPC interface is activated by default. Back then, it was very easy to deactivate it, while today, this is only possible via detours. But the detours are not too complicated. Overall, three steps are necessary to turn off the interface and to prevent it from being accessed.

Part One: Deactivating the Interface Using a Filter

The following code has to be pasted into the theme's functions.php. Clicking the Graphic Opens the GitHub Gist xml-rpc-filter The interface is now completely deactivated. However, it still appears in the website's HTTP header.

Part 2: Deactivating the HTTP Header Entry

http-header If it's still displayed, it can still be accessed. While this might not be a security risk anymore, it can still have an impact on the website's performance. That's why the entry needs to be removed. This code snippet also needs to be put into the functions.php of your theme. Here, you can find the complete code with the filter from the first part included: Clicking the Graphic Opens the GitHub Gist Die XMLRPC-Schnittstelle abschalten und den HTTP-Header entfernen

Part 3: Blocking the xmlrpc.php Via .htaccess

As long as WordPress has access to the xmlrpc.php, hidden access to the file exist. This doesn't help with the website's performance, which is why the file should be blocked by the .htaccess file once more. An Important Thing Before You Start: Please Create a Backup of the File Whenever You Alter .htaccess! One mistake during the editing of the file can result in your website not working anymore. You should also keep in mind that, because of the dot in front of the file name, the .htaccess is treated as a system file on Mac OS X. This causes the file not to be displayed as soon as it is on the desktop. You can either use the terminal or a dashboard widget to find hidden files. Paste the following entry into the .htaccess file in the WordPress Installation's main index. The entry should be above of #Begin WordPress. The file can be opened and edited using a text editor like Notepad or TextEdit. The Main Index of a WordPress Installation hauptverzeichnis Clicking the Graphic Opens the GitHub Gist htaccess

Conclusion

These three little steps have made your WordPress significantly safer. An attack on the xmlrpc.php is now impossible, and even calls to this file are not answered anymore, which helps with the performance. However, you should be aware that WordPress doesn't receive pingbacks anymore, and you also can't manage your content in apps of any kind anymore. However, this should only be a small downer that doesn't outweigh the security gain. (dpe)

Andreas Hecht

Andreas Hecht is a journalist and specialist for WordPress and WordPress Security. He roams the web since its inception. He has published an ebook on WordPress Security, which you might want to take a look at.

2 comments

  1. Sorry but that’s just BS. XMLRPC interface is used by many integration clients so saying that most users don’t need it is like saying most users use their wordpress site for posting pics of kittens.

    Also, if your main concern here is the number of passwords that are checked, you can just use a hashing algorithm like bcrypt or at the very least pbkdf2 so there won’t be much gain from using xmlrpc vs standard HTTP POST. Dunno what algorithm wordpress uses by default though. There are quite a few other precautions you can take and staying up to date with security updates is one of the most obvious one. You could also simply add some validation to XML-RPC interface so it only processes one user/password endpoint at a time. Or you could just disable some endpoints.

    There are many possibilities, but disabling the whole thing and arguing like it’s dangerous by itself is wrong.

  2. >so saying that most users don’t need it is like saying most users use their wordpress site for posting pics of kittens

    Well given that WordPress is the most popular website platform by far… then yeah, most users probably do use their WordPress sites for posting pictures of kittens (or cakes, or their new outfits, or their gardens).

Leave a Reply

Your email address will not be published. Required fields are marked *