WordPress Pingback Portscanner – Metasploit Module

jackass johnny knoxville 1 Wordpress Pingback Portscanner   Metasploit Module

Github Module [1]

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.

wordpress 1 1024x418 Wordpress Pingback Portscanner   Metasploit Module

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:

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.

Response:

Screenshot of demo.sayHello API XML-RPC request:

wordpress 2 1024x378 Wordpress Pingback Portscanner   Metasploit Module

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

wordpress 3 1024x803 Wordpress Pingback Portscanner   Metasploit Module

Module in Action

wordpress 4 1024x737 Wordpress Pingback Portscanner   Metasploit Module

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.

wordpress 5 954x1024 Wordpress Pingback Portscanner   Metasploit Module

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.

wordpress 6 962x1024 Wordpress Pingback Portscanner   Metasploit Module

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

wordpress 8 Wordpress Pingback Portscanner   Metasploit Module

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.

Share this article

facebook Wordpress Pingback Portscanner   Metasploit Moduletwitter Wordpress Pingback Portscanner   Metasploit Modulegoogle plus Wordpress Pingback Portscanner   Metasploit Modulereddit Wordpress Pingback Portscanner   Metasploit Modulepinterest Wordpress Pingback Portscanner   Metasploit Modulelinkedin Wordpress Pingback Portscanner   Metasploit Modulemail Wordpress Pingback Portscanner   Metasploit Modulefacebook Wordpress Pingback Portscanner   Metasploit Moduletwitter Wordpress Pingback Portscanner   Metasploit Modulegoogle plus Wordpress Pingback Portscanner   Metasploit Modulereddit Wordpress Pingback Portscanner   Metasploit Modulepinterest Wordpress Pingback Portscanner   Metasploit Modulelinkedin Wordpress Pingback Portscanner   Metasploit Modulemail Wordpress Pingback Portscanner   Metasploit Module

8 Comments

  1. Tim March 31, 2015 2:36 pm 

    Hi, satishb3, the best solution is remove xmlrpc.php from your WordPress sites.

  2. Jon March 31, 2015 11:45 am 

    In case you are not aware (sorry if you already know this), but XMLPRC is used for posting content remotely. The xmlrpc.php file is what WordPress uses to allow you to post remotely.

    As you know, one of the things we all love about WordPress is how easy it is to create new websites and to manage the content. These are the very same reasons why hackers also love WordPress.

    If you are not posting comments to your website remotely, one of the quickest way to get yourself out of this situation is to rename the xmlrpc.php file to some fictitious name. Make sure you change the file type to anything other than “.php.” This way, you will remove the possibility that the server may accidentally run the code.

    If you are doing posts remotely, here’s some code you can add to your .htaccess file:

    order deny,allow
    deny from all
    allow from 123.456.789.123 allow {where “123.456.789.123” is the IP address of the computer that can use xmlrpc.pgp}

    WordPress has a bunch of security holes and we have been victimized many times. I a solution that so far has helped me secure our sites more than anything else we have tried.

    Here is the link ==> http://jvz8.com/c/9278/20094

    Hopefully, WordPress will not open up new holes with the next WP update.

  3. smilingraccoon January 8, 2013 1:41 pm 

    There isn’t an official patch out for it yet. The only crappy fix I’ve seen as of yet is to rename or delete the xmlrpc.php file.

  4. satishb3 January 8, 2013 5:01 am 

    Btw, what is the recommended solution for it?

  5. satishb3 January 8, 2013 4:57 am 

    Awesome post. Interesting read.

Leave a comment

Your email address will not be published. Required fields are marked *


× six = twelve