Webmasters Gallery

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

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

The interface is now completely deactivated. However, it still appears in the website’s HTTP header.

Part 2: Deactivating the HTTP Header Entry

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

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

Clicking the Graphic Opens the GitHub Gist

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)