The xmlrpc.php file can be found in the WordPress core and is generally enabled by default, which leaves your WordPress site exposed to all kinds of malicious attacks.
We are going to look at what the XMLRPC file is, what it does, and, more importantly, how to manage it while boosting your website’s security.
What Is XMLRPC?
XML-RPC (eXtensible Markup Language – Remote Procedure Call) was created to offer cross-platform communication. This is a protocol that uses HTTP as a transport and XML as an encoder to generate procedure calls, thus allowing for the ability to run functions on a remote computer.
HTTP requests can be sent by the client (i.e., browser or mobile app) to the server, and the server then sends an HTTP response. The HTTP request can be used to invoke functions, and these functions can then be used to perform specific actions.
This is different from the REST API, as that uses URL parameters to identify resources. In contrast, RPC uses query parameters to offer function arguments.
XMLRPC allows users to interact with their site remotely, such as through the WordPress mobile app or via plugins like JetPack or WooCommerce.
The Security Issues Associated With The xmlrpc.php File
XMLRPC can expose your site to a variety of attacks. Since it’s easy to trace, hackers can send arbitrary XML data, which then allows them to control the site in a number of ways. Here are some security issues that you should know about.
Brute Force Attacks
In a brute force attack, the hackers essentially try to guess the correct password and user name using pure brute force – by attempting thousands of combinations.
If you have a weak admin password and aren’t using multi-factor authentication, there’s a chance that a hacker can brute force their way into your website’s backend.
WPSCAN, a popular tool from Kali Linux, can be used to easily find and list all valid usernames for the website. Once that’s done, hackers can use brute force via the xmlrpc.php file by sending the following request:
POST /xmlrpc.php HTTP/1.1
User-Agent: Fiddler
Host: www.example.com
Content-Length: 164
<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>
This way, hackers can send thousands of combinations until the site sends the correct password. A response indicating that an incorrect input, while also telling the hacker to try again, is shown below:
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 May 2019 13:30:17 GMT
Content-Type: text/xml; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/7.1.21
Cache-Control: private, must-revalidate
Expires: Sun, 02 Jun 2019 13:30:17 GMT
Content-Length: 403
<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>403</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Incorrect username or password.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>It returns the HTTP 200 code, indicating that the username and password are incorrect. Hackers don’t even have to worry about reCaptchas or limited login attempts if security is low.
DDoS Attacks
Distributed Denial of Service, or DDoS attacks, can completely take a server offline by sending thousands of requests simultaneously. The pingback feature in WordPress is commonly used by hackers in combination with the xmlrpc.php file to run DDoS attacks.
Usually, hackers find a page that they can target multiple times and then start attacking it. To start the attack, the hacker begins by checking for the xmlrpc.php file. They do this by sending this request:
POST /xmlrpc.php HTTP/1.1
Host: servebolt.com
Connection: keep-alive
Content-Length: 175
<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>demo.sayHello</methodName>
<params>
<param>
<value>admin</value>
</param>
</params>
</methodCall>Once the hackers have confirmation that the xmlrpc.php file is enabled, they then start attacking it with a network of exploited websites to send different pingback requests.
In many cases, this can be automated using the following code:
POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 293
<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://173.244.58.36/</string></value>
</param>
<param>
<value><string>https://example.com/blog/how-to-make-a-salad</string></value>
</param>
</params>
</methodCall>
Cross-Site Port Attacks
Cross-site Port Attacks (XSPA) are quite common. Hackers generally initiate these attacks by injecting malicious code to receive information about IP addresses and TCP ports.
Hackers use the pingback.ping technique to pingback a post on a website, which returns the IP address. Then, they use a sniffer to establish an endpoint to send a live blog post URL and a pingback using the following request:
<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>How to Block XMLRPC Attacks
There are several methods you can use to block XMLRPC attacks – most of which you’ll come across are ineffective – here’s how we recommend addressing this:
How Accelerated Domains and Servebolt CDN Handles XMLRPC Issues
Servebolt has two products that perform XMLRPC security out of the box. They both take the approach that some traffic to this place can be valid, but too much or too often is a sign of a hack attempt.
For example, our Accelerated Domains implementation listens to requests to xmlrpc.php, if there are more than 15 requests in a minute, it will ban that IP address for a whole day. This effectively stops the hack attempt while allowing users of the website via WordPress Mobile or users of Jetpack/WooCommerce to continue to work.
The Servebolt CDN deals with it slightly differently, it also has a threshold of 15 requests per minute from the same IP address to the xmlrpc.php and then bans the IP address for 1 hour.
If you’ve already made the (wise 😄) decision to host your WordPress websites with us – when using Servebolt’s CDN or Accelerated Domains – one of these security options is automatically implemented for you.
Blocking XMLRPC on Cloudflare
It is possible to block traffic to xmlrpc.php directly on Cloudflare, stopping it from ever reaching your server.
This is only a really valid solution if you are also blocking traffic that is not originating from Cloudflare. If you have not already set this up, then it will still be possible for hackers to attempt to access and exploit it on your origin server directly. And, of course, this is easily configurable in just a single click via the Servebolt admin interface.
Where this will help is that, like with Accelerated Domains or CDN from Servebolt, the xmlrpc.php traffic from bad actors is stopped at the edge long before it reaches the server.
To block all traffic, login to Cloudflare admin, select the domain, click Security, click WAF, create a new firewall rule, and enter the details as shown in the photo below:
- Rule Name = whatever you want to call it
- Field = URI Path
- Operator = equals
- Value = /xmlrpc.php
Or you can “edit the expression” and paste it into the following code:
(http.request.uri.path eq "/xmlrpc.php")
Choose the action of “Block” and save & deploy it.
Remember: because you have set this up, you will have to remember it exists. There might be a time in the future when you are wondering why xmlrpc.php is not working, and you cannot see it in your server configuration.
Note: If you use this method, you must ensure that your server is configured only to allow traffic that is coming through Cloudflare. As otherwise, it would be possible to bypass this.
In Servebolt, this can be enabled in the control panel:
Alternative Method: Disabling XMLRPC On The Server Altogether
On Apache Servers
A better alternative is to disable the XMLRPC file altogether. This is possible on Apache by just adding a snippet of code in your .htaccess file just before the firm rules added by WordPress:
<Files xmlrpc.php>
order allow,deny
deny from all
</Files>You can also whitelist IP addresses through which you wish to access XMLRPC. For that, use this command:
<Files xmlrpc.php>
<RequireAny>
Require ip 1.1.1.2
Require ip 2001:db8::/32
</RequireAny>
</Files>This is a wise option as it eliminates the misuse of XMLRPC, though there’s a downside: you’ll be disabling remote access to your site. As a result, the mobile app – or Jetpack, for that matter – won’t work properly.
On Nginx Servers
Disabling Nginx is slightly harder as you need to have server configuration access rather than the more simple .htaccess of Apache. To disable, edit the virtual host config file, usually located in /etc/nginx/sites-available and add the following directive to the server block:
server {
# // your standard server root and configuration
location = /xmlrpc.php { deny all; }
# // rest of the server configuration such as PHP-FPM}
Servebolt uses the .htaccess method to deploy this solution to xmlrpc.php. If you are with a managed host like Servebolt and are using Nginx you will most likely need them to implement this for you.
Why Installing a Security Plugin Isn’t a Wise Idea
Most people might be thinking of installing a WordPress security plugin on their site. However, that’s not actually a good idea for several reasons:
- The request to xmlrpc.php will still be happening, with the security plugin sat in between it and WordPress, using up system resources that will fail quicker in the event of an attack.
- They are primarily effective at the application level, not at the server level.
- They add unnecessary code to your site, affecting its performance.
- They require constant load management.
- Security plugins mess with crucial parts of WordPress security, including login – with just a single mistake in code that runs as a part of logins, your site is at greater risk.
Conclusion
Cyberattacks are getting more sophisticated day by day. As a webmaster & business owner, it’s essential to be aware of and understand potential threats and the steps you can take to protect yourself against them. The majority of which can be mitigated with the help of a proactive approach – a combination of monitoring and keeping software up-to-date as well as taking advantage of solutions like Accelerated Domains. When enabled, Accelerated Domains or Servebolt CDN intelligently filters traffic and automatically takes action to protect your website from harmful attacks, ultimately keeping your origin server secure and your site safe.
Any specific questions about XMLRPC or security? Get in touch with us – our expert, friendly, and thorough support team is here to help.
