Prevent WordPress hacking using this Pen Testing guide

Welcome back to the next edition of “Hacking WordPress”. Find Part 1 if you missed it. Let me start with a PSA message. It is illegal to hack, log in to, penetrate, take over or even hack, a system or network of systems without the explicit permission of the owner. Criminal hacking is illegal and punishable under Federal Law. I am describing methods to learn more about WordPress so you can protect your sites better.

The Computer Fraud and Abuse Act of 1986, enacted into law today as United States Code Title 18 Section 1030, is the primary federal law governing cybercrime in the United States today. It has been used in such famous cases as the Morris Worm and in the prosecution of notorious TJX hacker Albert Gonzalez.

Stress testing your own WordPress site with penetration testing

Now, in this edition we are going to use Kali Linux and WPScan to run a few commands against a WordPress site built in the lab for testing purposes. In the last episode I told you about Bitnami. They provide a fully virtualized version of WordPress in an .ovf format, which is ready to spin up with VMWare ESXi server. You can find the download here: https://bitnami.com/stacks

In this episode we are going to pen test a WordPress site for a couple of things. These will not give us access to the site but would be more around reconnaissance of the site. Recon will tell you a lot about a site and its security. Once you find out basic information, it’s easier to move on to deeper penetration efforts and possibly even breaching the site through a brute force attack.

How to find your WordPress vulnerabilities

First you must prepare your instance of WPScan on Kali Linux to ensure you have the latest scan patterns, definition and updates to plug-ins and templates, as these updates will contain information about weaknesses and exploits within the assorted accessories that work with WordPress.

When you run the command below the output below that is what you should get in your Kali Linux terminal screen.

root@kali:~# wpscan –update

   wps tool

        WordPress Security Scanner by the WPScan Team

                       Version 3.3.1

          Sponsored by Sucuri - https://sucuri.net

      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_

_______________________________________________________________

[i] Updating the Database ...

[i] Update completed.

This command runs a basic scan of the website, in this case the IP address. You can run this command with the FQDN if you prefer. I am running this with IP because it’s in the lab.

root@kali:~# wpscan --url 10.25.100.22

       wps tool

        WordPress Security Scanner by the WPScan Team

                       Version 3.3.1

          Sponsored by Sucuri - https://sucuri.net

      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_

_______________________________________________________________

[+] URL: http://10.25.100.22/

[+] Started: Tue Jun 25 23:59:58 2019

Interesting Finding(s):

The interesting finding here are that the website is running on an Apache Server powered by PHO 7.2.13 and all of this info was found in the headers. This is not uncommon for headers to hold all of that information, however for a secure site, info like that can either be deleted or encrypted in the header for recon purposes.

[+] http://10.25.100.22/

 | Interesting Entries:

 |  - Server: Apache

 |  - X-Powered-By: PHP/7.2.13

 |  - X-Mod-Pagespeed: 1.13.35.2-0

 | Found By: Headers (Passive Detection)

 | Confidence: 100%

The WPScan Robot ran down all the URI’s in the site and showed us the link to the “-/wp-admin” which is the gateway to the login page and is the gateway also for the administrative section of the website. It is wise to change the directory of the login page and to use site encryption so that it is not easily discoverable nor susceptible to a brute force dictionary attack, which I will be performing in a later episode.

[+] http://10.25.100.22/robots.txt

 | Interesting Entries:

 |  - /wp-admin/

 |  - /wp-admin/admin-ajax.php

 | Found By: Robots Txt (Aggressive Detection)

 | Confidence: 100%

This is a particularly interesting piece of the puzzle right here. The scan has discovered the link to the “/xmlrpc.php” page. This is a very important page in the system. XMLRPC is based on Python.

xmlrpc — XMLRPC server and client modules. XML-RPC is a Remote Procedure Call method that uses XML passed via HTTP as a transport. With it, a client can call methods with parameters on a remote server (the server is named by a URI) and get back structured data.”

https://docs.python.org/3/library/xmlrpc.html

What this means is there is a public facing page in WordPress that can be manipulated simply by sending a Remote Procedure Call (RPC) in Extensible Markup Language (XML) which is pretty much clear text to get a response from a server. In this case the scan sent a request and got ack a response for the .php page that handles the XMLPRC and also the link to the codex page carries the XMLRPS Pingback for the WordPress API. Interesting, yes…. Safe? only time will tell.

[+] http://10.25.100.22/xmlrpc.php

 | Found By: Direct Access (Aggressive Detection)

 | Confidence: 100%

 | References:

 |  - http://codex.wordpress.org/XML-RPC_Pingback_API

 |  - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_ghost_scanner

 |  - https://www.rapid7.com/db/modules/auxiliary/dos/http/wordpress_xmlrpc_dos

 |  - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_xmlrpc_login

 |  - https://www.rapid7.com/db/modules/auxiliary/scanner/http/wordpress_pingback_access

Finding the Readme page is a shot in the dark. It may have valuable info or it may just be a page full of gibberish. Usually the latter.

[+] http://10.25.100.22/readme.html

 | Found By: Direct Access (Aggressive Detection)

 | Confidence: 100%

Here the WordPress version is identified. From here the scanner will tell you about any vulnerabilities that are contained in the source code which makes running an exploit against those vulnerabilities much easier. It also tells you about the RSS feed which is interested because with the right plug in installed you can actually feed content into the site to be created into posts and pages without having a login to the WordPress site thus essentially pwning the site without having any credentials.

[+] WordPress version 5.0.4 identified.

 | Detected By: Rss Generator (Passive Detection)

 |  - http://10.25.100.22/feed/, https://wordpress.org/?v=5.0.4

 |  - http://10.25.100.22/comments/feed/, https://wordpress.org/?v=5.0.4


[+] WordPress theme in use: twentynineteen

 | Location: http://10.25.100.22/wp-content/themes/twentynineteen/

 | Last Updated: 2019-05-07T00:00:00.000Z

 | Readme: http://10.25.100.22/wp-content/themes/twentynineteen/readme.txt

 | [!] The version is out of date, the latest version is 1.4

 | Style URL: http://10.25.100.22/wp-content/themes/twentynineteen/style.css?ver=1.1

 | Style Name: Twenty Nineteen

 | Style URI: https://github.com/WordPress/twentynineteen

 | Description: A new Gutenberg-ready theme....

 | Author: the WordPress team

 | Author URI: https://wordpress.org/

 |

 | Detected By: Css Style (Passive Detection)

Here we have CSS information which is very interesting. CSS or Cascading Style Sheets generally control the look and feel of the entire site, including color references, image references and more. With a complete CSS and a few snippets of code you could effectively build a duplicate website for spoofing and phishing activity.

 | Version: 1.1 (80% confidence)

 | Detected By: Style (Passive Detection)

 |  - http://10.25.100.22/wp-content/themes/twentynineteen/style.css?ver=1.1, Match: 'Version: 1.1'

Reviewing WordPress plugin security

Here we should see an enumerated list of plugins, which with a production website should provide a great deal of opportunity for vulnerabilities to exploit, based on the open source nature and often poor updating practices of many web-designers and developers.

[+] Enumerating All Plugins

[i] No plugins Found.

[+] Enumerating Config Backups

 Checking Config Backups - Time: 00:00:00 <=========================================================================> (21 / 21) 100.00% Time: 00:00:00

Here we would see a list of backups of the almost all content in the site plus database backups if they are performed and stored on the same server as the application. This is really not a best practice, so I would not expect to see this often, but if you do it is hacking gold and could provide a pen testing with everything they need to penetrate and pwn a site in a matter of minutes.

[i] No Config Backups Found.

[+] Finished: Wed Jun 26 00:00:03 2019

[+] Requests Done: 51

[+] Memory used: 69.875 MB

[+] Elapsed time: 00:00:04

The themes-version-all command is a good command to use to not only recon the themes assigned into the system but also to see the version numbers. In this case there are nothing but default themes so there is not a lot in the way of exploits as the generic WordPress themes do not make use of a lot of the application’s deeper functionalities such as plugins or APIs. So, there is not a lot to see here. We will dig deeper into this with more complicated themes in a future episode.

wpscan --url 10.25.100.22 themes-version-all

root@kali:~# wpscan --url 10.25.100.22 themes-version-all

    wps tool

        WordPress Security Scanner by the WPScan Team

                       Version 3.3.1

          Sponsored by Sucuri - https://sucuri.net

      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_

_______________________________________________________________

[+] URL: http://10.25.100.22/

[+] Started: Wed Jun 26 00:11:00 2019

Interesting Finding(s):

[+] http://10.25.100.22/

 | Interesting Entries:

 |  - Server: Apache

 |  - X-Powered-By: PHP/7.2.13

 |  - X-Mod-Pagespeed: 1.13.35.2-0

 | Found By: Headers (Passive Detection)

 | Confidence: 100%

The command below is good to use if you have managed to find a list of users or usernames for a particular site. You can save the list in a .txt file and use is as a dictionary of users to company against a brute scan that WPScan compares against several areas of the website including pages, posts and images by the user that uploaded the file or created the page or post.

wpscan –url 10.25.100.22 –usernames LIST (replace the LIST with the directory url of the dictionary of usernames)

root@kali:~# wpscan –url 10.25.100.22 -e  –users-list ‘/root/Downloads/dictionary/user_dictionary’

  wps tool

        WordPress Security Scanner by the WPScan Team

                       Version 3.3.1

          Sponsored by Sucuri - https://sucuri.net

      @_WPScan_, @ethicalhack3r, @erwan_lr, @_FireFart_

_______________________________________________________________

[+] URL: http://10.25.100.22/

[+] Started: Wed Jun 26 00:23:19 2019

Interesting Finding(s):

I deleted all the previously printed data to save space and reduce redundancy of data in the blog.

Everything that has be printed back from the command to this point is standardized scanning fodder. You will pretty much get this above information with every scan unless you run a command to obfuscate the data and not print it. In this article I am just showing you basic commands to get familiarized with.

Below is the meat of the command we just ran. Here we have enumerated the users of the site that were found through the published posts in the site. In this case the only user we found was “user”. This is a new setup of the site so the only user in the site is “user”, so our scan was a 100% success. We will get deeper into this in future episodes.

[+] Enumerating Users

 Brute Forcing Author IDs - Time: 00:00:00 <==================================> (10 / 10) 100.00% Time: 00:00:00

[i] User(s) Identified:

[+] user

 | Detected By: Author Posts - Author Pattern (Passive Detection)

 | Confirmed By:

 |  Rss Generator (Passive Detection)

 |  Wp Json Api (Aggressive Detection)

 |   - http://10.25.100.22/wp-json/wp/v2/users/

 |  Rss Generator (Aggressive Detection)

 |  Author Id Brute Forcing - Author Pattern (Aggressive Detection)

 |  Login Error Messages (Aggressive Detection)

[+] Finished: Wed Jun 26 00:24:51 2019

[+] Requests Done: 3069

[+] Memory used: 167.984 MB

[+] Elapsed time: 00:01:32

This concludes this episode. In the next episode we will move from reconnaissance to actually working with a populated website (lab site only) so that we can get some good data back and actually run a username dictionary attack and a password dictionary attack to see if we can penetrate this site and pwn it. From there we will dig into some much cooler aspects of pen testing WordPress like db injections and more. So check back soon and check back often. Until then, Happy Testing.