The XMLRPC Story
It started when I joined recently as DevOps Intern at Innovate Tech this summer. I worked with a team on the migration of monolithic services based on WordPress towards the microservice at the EKS cluster. Now, it gets deployed, it was at AWS EC2 instances before. I will share about migrations in the upcoming blog. I was being amazed by Sec teams auditing multiple services internally. I got permission to check out the flaws in the project I was working on. There might be a few questions that come into your mind about what XMLRPC is? Is it an XML parser or maybe anything else? Let’s remove that confusion that we possess right now if you are unknown about it.
XML-RPC is a remote procedure call (RPC) protocol that uses XML to encode its calls and HTTP as a transport mechanism. In early versions of WordPress, XML-RPC was turned off by default. Now XML-RPC is being enabled by default in WordPress from the 3.5 version. XML-RPC allows third-party apps to publish content on your WordPress website. For instance, if you use the WordPress mobile app to publish a post from your smartphone, XML-RPC allows you to do that. It’s being used for remote blog posting, deletion, and any other operations.
Exploitation
I have everything in the scope and reconnaissance took less amount of time. Thanking Nuclei for leveraging the time and effort. I got enabled XMLRPC within few minutes.
nuclei -t wordpress_templates.yaml -l domains.txt
You can also try it out in Google if it indexes.
inurl:"/xmlrpc.php?rsd"
If you got the endpoints and wanted to test them. You can use the below URL for it.
Now we got enabled XMPRC, Let’s try to exploit it. Make sure you configured the browser with the burp suite ca certificate. Open up your burp suite, intercept the request. Send it to the repeater and paste the below payload if you found the enabled XMLRPC on the site. Try out using POST request through burp.
POST /xmlrpc.php HTTP/1.1
Host: test.com
Content-Length: 135
<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>system.listMethods</methodName>
<params></params>
</methodCall>
Note: Payloads for several attacks can be easily available. You can test with others.
Look out for the response, chances are you might get the list of methods you can use out. Almost the wp services were being the victim of it. I reported in the slack group as I am working from home remotely.
Talking about the impact, I think it depends on the respective company. Some companies do a rewards bounty if you submitted through their VDP. Few reports are listed below.
It can be automated from multiple hosts and be used to cause a mass DDOS attack on the victim. Bruteforce one, since it can lead to steal the admin credentials and hijack the WordPress site. There is a chance they could eventually hit on the right one, giving them access to your site.
Prevention
There are many ways to resolve the issue. You can try it out through .htaccess, WordPress plugins, delete the xmlrpc.php(which I don’t recommend).
If your project uses Nginx, you can disable access through the xmlrpc.php file from the Nginx server block.
location ~* ^/xmlrpc.php$ {
deny all;
}
In the project where I was working, there are lots of things that need to consider. As mentioned, I will share migrations one where I will talk in more detail about it. Here, I will share the prevention part. We have a custom WordPress image registry on Gitlab.
Dockerfile
FROM resources
# Label and credit
LABEL \
maintainer "XXXX"\
description = "XXX"
# Restrict Xmlrpc POST method
COPY .htaccess /opt/bitnami/wordpress/
.........
.........
.........
Copy out the .htaccess file in the container directory so it can disable the XML-RPC. It will prevent config, cron, and other files too. Feel free to use the below snippets if you are using the WordPress site.
.htaccess
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
RewriteRule ^wp-admin/includes/ - [F,L]
RewriteRule !^wp-includes/ - [S=3]
RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>
<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php|wp-cron\.php|(?<!robots)\.txt|(liesmich|readme)\.*)">
Require all denied
</FilesMatch>
The image has been build in the pipeline, it will push towards the GitLab registry for the update. For the deployment part, we have a configured pipeline with eks cluster through kubeconfig credentials. Now helm chart of custom wp service came into the big picture, where it gets deployed through the pipeline in the staging environment. This is all tested in the dev cluster. It will get deployed once everything gets passed in the dev cluster.
Conclusion
The pipeline can be improved by enabling the nuclei or wpscan during the running job on the pipeline. This can alert the team about the common vulnerabilities that have been exposed. This might not be same in the all project workflow. At least defending one is clear out and can proceed in any project where XMLRPC is being enabled.