Github Module 
The latest version of WordPress, version 3.5 was recently released on December 11, 2012. This latest version of WordPress comes pre-packaged with the XML-RPC interface enabled by default. This is just the type of configuration that us pentesters love to see during an engagment. This additional attack surface may be just the little extra that a pentester needs.
WordPress doesn’t actually give you an easy option in the settings to disabled the XML-RPC interface. It’s much more complicated than that. You must install an additional plugin (which can make your WordPress site more vulnerable) or edit the source code directly. With this in mind, you can be assured that there will be tons of WordPress 3.5 websites out on the internet with their XML-RPC interface enabled and publicly accessible.
You can quickly determine if a WordPress website is running the XML-RPC interface in the default location, by simply browsing to the default url. If you are not familiar with the basics of WordPress XML-RPC requests, check out this article to learn more.
Now that we know where the XML-RPC interface is located, lets send a test POST request to see if it’s actually enabled. WordPress comes with a couple test plugins that we can simply use to test out the functionality. We are going to demonstrate a simple ‘demo.sayHello‘ XML-RPC request. The XML file hello.txt that we have created for this looks like:
<?xml version="1.0" encoding="iso-8859-1"?>
Now that we have our XML file to send with the POST request, lets use curl to craft the proper request to ensure we get a valid response.
curl --data @hello.txt http://www.pentestgeek.com/xmlrpc.php
<?xml version="1.0" encoding="UTF-8"?>
Screenshot of demo.sayHello API XML-RPC request:
Now that we know the XML-RPC interface is available and functioning properly, we can try to take advantage of the Pingback API. The Pingback API is publicly available by default in WordPress 3.5 and doesn’t require any authentication. By using this API, we can essentially use a default WordPress 3.5 installation to perform port scanning for us. Not only can we relay scans through the website, but we can attempt to scan the web server itself (127.0.0.1) or even the internal network the server is part of.
There is already PoC code publicly available on the following github. Using this PoC, SmilingRaccoon and I recently wrote a metasploit module to accomplish this task as well. The module will essentially connect to an HTTP(S) Server to enumerate the XML-RPC interface. Once the XML-RPC interface is enumerated it will then attempt to determine if the Pingback API is enabled anywhere throughout the website. Once the Pingback API is found enabled within the website, the module will then utilize the API by port scanning whatever has been defined in the TARGET and PORT datastore.
Basic Module Info
Module in Action
You can see that we were able to connect to the XML-RPC interface on pentestgeek.com. Once connected to the XML-RPC interface we initiated a portscan against google.com using the PingBack API that comes configured by default. Lets pull up a packet sniffer to see what the actual HTTP requests look like to determine if the port is open or not.
From the packet dump above we can see both the request (red) and response (blue) that was made. In this case we were able to determine that port 21 is closed due to the value <int>16<int> in the response. We need a <int>17<int> in the response for a port to be open. Let’s take a look at an example of an open port.
From the screenshot above you can see that we got a response back with the value of 17. This means that the host and port we just scanned is open. We can look at the request that was made to determine its google.com and port 80 that is open. Well that makes sense, google.com does run an HTTP website on port 80.
So we’ve demonstrated relaying the scan through a wordpress website, but the real value comes in when you can scan the internal network that the wordpress site is part of. Below is an example where we scan an external-facing WordPress installation and using the XML-RPC interface we are able to port scan the internal 192.168.0.1/24 Class C network that the server is sitting on.
Scanning Internal Networks
From the screenshot above we can see that we were able to enumerate that port 80 is open on both 192.168.0.1 and 192.168.0.2. These are devices that are sitting on the internal network and not publicly available on the internet.
The best way to get the code currently is on the following Github. The module is currently submitted as a formal pull request in metasploit.