Recently I have performed a large number of web application penetration tests against websites that use WordPress. I have found some of them quite secure and well configured but others allowed a full compromise of the WordPress administration section, with subsequent full control of the webserver.
In this article I am going to describe a scenario of a recent penetration test of a website using WordPress. Since WordPress is probably one of the most popular Content Management Systems (CMS), the following steps can be replicated against a large number of similar WordPress sites and with a few changes against other CMS such as Drupal, Joomla and so on.
One of the first things to do during a test is to identify which technology the target website is using and at the same time which version. Identifying the version of an unhardened WordPress is straight forward. By browsing the default “readme.html” WordPress lets us know the current version installed:
When this information is collected, it is possible to search online for public vulnerabilities related to that specific version. Unfortunately the research did not reveal any good vulnerabilities and the next step was to enumerate the WordPress plugins.
A good tool to do that is WPScan (http://wpscan.org/) which also shows the version of WordPress and if the identified plugins have publicly disclosed vulnerabilities. Another tool to enumerate WordPress plugins by brute-forcing the website is Dirbuster (https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project). Since the WordPress plugin web path is known it is possible to configure Dirbuster for searching the plugin readme file as below:
Note that the “intruder” in Burp or any other brute-forcing tools can be also used to achieve the same result.
However all these tools will be useless if you do not have a good wordlist. WPScan has the following plugin list which can be used along with Dirbuster or Burp.
Alternatively you can create your plugins list by crawling the official WordPress site at http://wordpress.org looking for the most popular plugins. The following Python code was used to generate a plugins list by crawling the first 20 pages of the website.
When the enumeration phase of WordPress plugins was completed I searched online for public vulnerabilities related to the identified plugins. Good websites are http://www.exploit-db.com/, http://packetstormsecurity.com, http://1337day.com and the new Shodan exploit searching engine https://exploits.shodan.io.
One of the plugins was vulnerable to a SQL Injection. A SQL Injection vulnerability in a WordPress site basically means obtaining WordPress administrator privileges and thus a PHP shell on the website. Through SQL injection in fact it was possible to read the reset password key from the database by resetting a WordPress administrator’s password at the following URL.
Then the following SQL query was used to retrieve the reset password key from the database:
And finally the following URL allowed resetting the WordPress administrator’s password.
And consequently it allowed logging into the WordPress administration section.
Before I mentioned that SQL injection in a WordPress allows uploading a PHP shell on the website as well. This is possible because by resetting an administrator’s password then you have privileges to access the WordPress theme editor, and in case you have write access, it allows adding arbitrary PHP code. As a result, a PHP shell was uploaded:
At this point WordPress was fully compromised and access to the webserver was obtained. Unfortunately the privileges on the webserver were restricted to a low privileged user “www-data”. A privileges escalation attack was thus necessary to elevate my privileges to root.
I tend to avoid local privilege escalation exploits on production systems in order to minimise denial of service as much as possible so for this reason I established a reverse shell connection and I started exploring the file system of the webserver. A large number of files and directories were found to have excessive privileges:
The “wp-cron.sh” bash script was also found to be executed with root permissions every 5 minutes in the “crontab” file. Since a low privileged user had write permission to the “wp-cron.sh” file I was able to add a line at the bottom of the file in in order to spawn a bash shell into a localhost connection on TCP port “8080”. When cron executed the script (after 5 minutes), I was able to obtain root access on the webserver by connecting to that port. These steps are illustrated below:
In summary, both the WordPress website administration section and the web server were fully compromised. Whenever you install a CMS, ensure that you only install the plugins you need, delete unnecessary default files, and keep the core CMS and plugins up-to-date.