What is XMLRPC and How You Can Stop Hackers From Using It To Hurt Your Online Business

Website security is a tough thing to solve in the right way. Specifically with security issues related to XML-RPC – as commonly exploited in attacks on WordPress sites. There’s a lot of information available on the internet providing all kinds of solutions, but which are correct? This article will explain the how, the solutions out there, and what actually is the best solution. Let’s dive in!

XMLRPC is older than WordPress itself. This system was introduced to WordPress to fight the slow internet connection dilemma by helping the users write new posts offline and then uploaded them to the server. The ability to connect WordPress remotely with other applications was only possible with the xmlrpc.php file. 

Even some experienced developers do not fully understand XMLRPC and the security threats associated with it. It is quite a possibility that the site/sites you manage have an active XMLRPC file that needs your immediate attention but you can only execute an effective plan of action after knowing how XMLRPC is operated and what is the best way of handling it securely.  

Although WordPress has now its own REST API, the xmlrpc.php file is still present inside the core and is enabled by default exposing the WordPress site to various cyber-attacks. In this article, we will learn the usage of this file, the vulnerabilities associated with it, and how to handle this without putting your site’s security at a risk.

What is an xmlrpc.php file?

In its simplest form, XML-RPC (Remote Procedure Call) was created for cross-platform communication. This protocol used to make procedure calls by using HTTP as transport and XML as the encoder. The client makes these calls by sending an HTTP request to the server and receives the HTTP response in return. XML-RPC invokes functions via HTTP request and then these functions perform some actions and send hard-coded responses in return. 

Let’s compare this with a REST API call to fully understand the concept.

ProcedureRPCREST
SignupPOST/signupPOST/users
Read UserGET/readUser?userid=123GET/persons/1234

REST consumes URL parameters to identify resources while RPC uses the query parameters to supply as function arguments.

WordPress used XMLRPC to allow its users to interact with their site remotely. It still uses it to power its mobile app and to support plugins like JetPack, WooCommerce, etc. Using the xmlrpc.php file has its downsides but is disabling it completely the only a viable solution? To answer that we first need to look at the vulnerabilities associated with it and what are the solutions available to avoid them. 

How Vicious Hackers Can Be With xmlrpc.php File?

Using XMLRPC, hackers leverage the Remote Procedure Calls (RPC) and invoke functions to fetch the data they want. In the majority of the WordPress sites, the xmlrpc.php file is easily traceable, and just by sending arbitrary XML data, hackers control the site to run the code they have prepared to execute a certain type of attack. 

To understand how WordPress XMLRPC is compromised, let’s look at the most popular cyberattacks associated with it. 

Bruteforce Attack

In the Bruteforce attack, the hacker tries to guess the correct username and password by running numerous login attempts. Unfortunately, a large number of WordPress sites use weak admin passwords or do not have any security layer added to stop attackers. Those sites are easily compromised with this type of attack. 

Others use a strong password and also have security mechanisms in place such as reCaptcha, and auto IP blocking that is effective against brute force attacks but if the hacker decides to use XMLRPC; she does not even need to access the WordPress admin. 

A very common tool from Kali Linux, WPSCAN is used to enumerate all the usernames and once it’s done, the hackers brute force the password using the xmlrpc.php file by sending the following HTTP request to the victim site.

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>

In the above example, a hacker can send thousands of variations until he retrieves the correct password.

The following response is returned against the above request. The response contains the error code and a clear message stating that the tried username and password were incorrect. It is a clear indication that tells the hacker to try again until the correct password is matched.

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>

The response returned HTTP 200 code and the message that the supplied username and password were incorrect. Going through the XMLRPC channel, a hacker does not have to worry about reCaptchas or limit login attempts plugins. She can keep running the variations until the correct password is retrieved. 

Note: Brute Force attacks are resource-intensive and cause performance issues as well. The trial and error process runs in a loop for a longer period of time that can keep your server busy to serve the actual visitors. This unnecessary resource consumption causes servers to consume more power.  

DDoS Attack

Distributed Denial of Service (DDoS) is one of the most lethal cyber-attacks that can paralyze the server by hitting it with hundreds and thousands of concurrent requests. Hackers use the pingback feature of WordPress along with the xmlrpc.php file to execute such attacks. 

Ideally, the hacker targets the endpoint or a page that can be hit several times and takes longer to respond. This way a single hit can have a maximum impact on server resources and in our case, XMLRPC serves the hacker well in exposing such endpoints.  

Several already compromised WordPress sites are used to execute the pingback.ping method to target a single victim. The overwhelming HTTP GET and POST requests jam the regular traffic and eventually crashes the server. 

First, the hacker checks if the xmlrpc.php file is enabled or not by sending the following request.

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.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 it is confirmed that the XMLRPC is enabled on the target website, the attacker starts hitting it using the network of exploited sites to send multiple pingback requests to a victim site. This can be automated from multiple hosts and be used to cause a mass DDoS attack on the victim site.

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 Attack (XSPA)

Cross-site Port Attacks (XSPA) are very common in which the hacker injects the malicious script to retrieve information on TCP ports and IP addresses. In the case of WordPress, XMLRPC is used along with its pingback mechanism to bypass any IP masking such as basic WAF like Cloudflare.

In an XSPA attack, the hacker uses pingback.ping method to pingback a post on a target website which in return sends the IP address in response. Hacker uses a sniffer to create the endpoint for sending the pingback and a live URL of a blog post.

Hackers send the following request from her server.

<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>

If the response contains faultCode and a value greater than 0 then it means the port is open for you to start sending the HTTP packets directly.

Ineffective Methods of Blocking XMLRPC Attacks

So far in the article, we have established that the xmlrpc.php file is prone to some serious cyber-attacks a such as DDoS, Bruteforce, and Cross-site Port Attack, therefore, it is crucial to handle it properly to block these attacks.

By Deleting the XMLRPC Completely

You can simply delete the XMLRPC file that will make your server start throwing 404 errors at anyone trying to access it. The downside of this solution is that the file will be re-created every time you update WordPress.

By Disabling the XMLRPC Completely

The other more viable option is to disable the xmlrpc.php file. You can do this by simply adding the block of code inside your .htaccess file. Make sure you do this before the never-changing .htaccess rules added by WordPress.

<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

This will disable the xmlrpc.php file for every application or service that uses it. You can whitelist a certain IP address in case you still wish to access your WordPress site via XMLRPC. For that, you need to add the following command:

<Files xmlrpc.php>
<RequireAny>
Require ip 1.1.1.2
Require ip 2001:db8::/32
</RequireAny>
</Files>

Pros

  • Eliminates the risks of XMLRPC being abused in cyberattacks.
  • Long terms performance benefits & savings on server resources.

Cons

  • Disabling XMLRPC is the same as disabling remote access for apps that use this version of remote access. This means Jetpack, WP mobile app, or any other solution that connects with your WordPress site via XMLRPC cannot connect with your site anymore.
  • Legacy code for custom apps might not work either. 

Why Installing a Security Plugin Actually Hurt Your Site

WordPress users often lean onto plugins for any required feature or functionality without thinking much about their impact on the site’s performance. There are several WordPress security plugins out there that promise to secure your website from XMLRPC related security issues but in reality, they hurt your site more. 

Here are some of the reasons why securing your site with a plugin is not the best choice.

  • Security plugins are only effective at the application level and do not protect your server from getting hit. 
  • They add unnecessary code on your site that downgrades its performance and increases time to first byte (TTFB).
  • Some of these plugins do more harm than good and are used by hackers to create backdoors to your website.
  • These plugins require frequent management that adds more work load.  

From the above assessment, none of the options offer an ideal solution to handle the XMLRPC security problem. This brings us to Accelerated Domains. A service that is built to solve complex security-related issues and much more. Let’s look at how Accelerated Domains can effectively solve the XMLRPC problem for you.    

How Accelerated Domains Handles XMLRPC Problems For Its Customers?

Accelerated Domains solves complex performance, security, and scalability issues in the most efficient manner. Accelerated Domains offers enterprise-level managed security that blocks any kind of cyberattacks including the ones associated with XMLRPC.

Accelerated Domains’ smart Security Engine sits in front of the server and filters close to 40% of all HTTP traffic. It detects even the most sophisticated cyberattacks early in the timeline through its intelligent heuristic capabilities powered by continuous data feeding and Servebolt’s hands-on knowledge and traffic analysis. Accelerated Domains does its magic without degrading the performance of your site in any way. In fact, it accelerates it.

Accelerated Domains proactive Security Engine automatically protects your website from DDoS attacks. With close to 60 Tbps network capacity, it is well equipped to withstand even some of the largest DDoS attacks on the internet. Similarly, it provides an effective defense mechanism against Bruteforce attacks through an auto rate-limiting feature where the number of requests generated from a single source is identified and limited to prevent malicious activities.           

Pros

  • Accelerated Domains mitigates the majority of security vulnerabilities associated with XMLRPC, hence no need to disable it. 
  • Allows the user to keep using the plugins like Jetpack, WooCommerce app, and other tools that are dependent on the xmlrpc.php file.
  • Hassle-free integration on any domain so no need to modify the .htaccess file.
  • No need to install additional plugins. 

Cons 

  • It has none.

Final Thoughts

Cyberattacks are getting sophisticated day by day and as a webmaster and business owner, it is vital for you to understand them and to know the tools to encounter them. The majority of the attacks are avoided with a proactive approach such as constant monitoring and updating the software or by adding tools like Accelerated Domains that do all of that on auto-pilot. Once enabled, Accelerated Domains intelligently filters traffic and takes necessary actions where needed to keep your origin server and your website protected from cyberattacks.

Ibad ur Rehman

Community & Content Manager

Ibad ur Rehman is a Community & Content Manager at Servebolt. Enthusiast about Cloud Computing, AI, and Digital Marketing. Technical content creator, JavaScript advocate, educator, and a lifelong learner.

Related Posts