Content Management Systems (CMS)
WordPress - Discovery & Enumeration
Search for robots.txtor try accessing /wp-admin or /wp-login.
WordPress stores its plugins in the wp-content/plugins directory. This folder is helpful to enumerate vulnerable plugins. Themes are stored in the wp-content/themes directory. These files should be carefully enumerated as they may lead to RCE.
There are five types of users on a standard WordPress installation.
Administrator: This user has access to administrative features within the website. This includes adding and deleting users and posts, as well as editing source code.
Editor: An editor can publish and manage posts, including the posts of other users.
Author: They can publish and manage their own posts.
Contributor: These users can write and manage their own posts but cannot publish them.
Subscriber: These are standard users who can browse posts and edit their profiles.
Getting access to an administrator is usually sufficient to obtain code execution on the server. Editors and authors might have access to certain vulnerable plugins, which normal users don’t.
Enumeration
From the output above, we know that the Contact Form 7 and mail-masta plugins are installed. The next step would be enumerating the versions.
Browsing to http://blog.inlanefreight.local/wp-content/plugins/mail-masta/ shows us that directory listing is enabled and that a readme.txt file is present. These files are very often helpful in fingerprinting version numbers.
Enumerating Users
A valid username and an invalid password results in the following message:
However, an invalid username returns that the user was not found.
This makes WordPress vulnerable to username enumeration, which can be used to obtain a list of potential usernames.
WPScan
WPScan is an automated WordPress scanner and enumeration tool. It determines if the various themes and plugins used by a blog are outdated or vulnerable. It’s installed by default on Parrot OS but can also be installed manually with gem.
WPScan is also able to pull in vulnerability information from external sources. We can obtain an API token from WPVulnDB, which is used by WPScan to scan for PoC and reports. The free plan allows up to 75 requests per day. To use the WPVulnDB database, just create an account and copy the API token from the users page. This token can then be supplied to wpscan using the --api-token parameter.
The --enumerate flag is used to enumerate various components of the WordPress application, such as plugins, themes, and users. By default, WPScan enumerates vulnerable plugins, themes, users, media, and backups. However, specific arguments can be supplied to restrict enumeration to specific components.
For example, all plugins can be enumerated using the arguments --enumerate ap
Attacking WordPress
There are several ways we can abuse built-in functionality to attack a WordPress installation. We will cover login brute forcing against the wp-login.php page and remote code execution via the theme editor. These two tactics build on each other as we need first to obtain valid credentials for an administrator-level user to log in to the WordPress back-end and edit a theme.
Login Bruteforce
WPScan can be used to brute force usernames and passwords. The scan report in the previous section returned two users registered on the website (admin and john). The tool uses two kinds of login brute force attacks, xmlrpc and wp-login. The wp-login method will attempt to brute force the standard WordPress login page, while the xmlrpc method uses WordPress API to make login attempts through /xmlrpc.php. The xmlrpc method is preferred as it’s faster.
The --password-attack flag is used to supply the type of attack. The -U argument takes in a list of users or a file containing user names. This applies to the -P passwords option as well. The -t flag is the number of threads which we can adjust up or down depending.
Code Execution
With administrative access to WordPress, we can modify the PHP source code to execute system commands.
After login, Click on Appearance on the side panel and select Theme Editor. This page will let us edit the PHP source code directly.
An inactive theme can be selected to avoid corrupting the primary theme.
Click on Select after selecting the theme, and we can edit an uncommon page such as 404.php to add a web shell.
The code above should let us execute commands via the GET parameter 0. We add this single line to the file just below the comments to avoid too much modification of the contents.
Click on Update File at the bottom to save. We know that WordPress themes are located at /wp-content/themes/<theme name>. We can interact with the web shell via the browser or using cURL. As always, we can then utilize this access to gain an interactive reverse shell and begin exploring the target.
The wp_admin_shell_upload module from Metasploit can be used to upload a shell and execute it automatically.
Many Metasploit modules (and other tools) attempt to clean up after themselves, but some fail. During an assessment, we would want to make every attempt to clean up this artifact from the client system and, regardless of whether we were able to remove it or not, we should list this artifact in our report appendices. At the very least, our report should have an appendix section that lists the following information:
Exploited systems (hostname/IP and method of exploitation)
Compromised users (account name, method of compromise, account type (local or domain))
Artifacts created on systems
Changes (such as adding a local admin user or modifying group membership)
Leveraging Known Vulnerabilities
We can use the waybackurls tool to look for older versions of a target site using the Wayback Machine. Sometimes we may find a previous version of a WordPress site using a plugin that has a known vulnerability. If the plugin is no longer in use but the developers did not remove it properly, we may still be able to access the directory it is stored in and exploit a flaw.
Vulnerable Plugins - mail-masta
Since 2016 it has suffered an unauthenticated SQL injection and a Local File Inclusion.
Vulnerable Plugins - wpDiscuz
Based on the version number (7.0.4), this exploit has a pretty good shot of getting us command execution.
The exploit script takes two parameters: -u the URL and -p the path to a valid post.
The exploit as written may fail, but we can use cURL to execute commands using the uploaded web shell. We just need to append ?cmd= after the .php extension to run commands which we can see in the exploit script.
In this example, we would want to make sure to clean up the uthsdkbywoxeebg-1629904090.8191.phpfile and once again list it as a testing artifact in the appendices of our report.
Joomla - Discovery & Enumeration
Discovery/Footprinting
Page source:
Joomla robots.txt typicial file:
We can also often see the telltale Joomla favicon (but not always). We can fingerprint the Joomla version if the README.txt file is present.
In certain Joomla installs, we may be able to fingerprint the version from JavaScript files in the media/system/js/ directory or by browsing to administrator/manifests/files/joomla.xml.
The cache.xml file can help to give us the approximate version. It is located at plugins/system/cache/cache.xml.
Enumeration
Let's try out droopescan, a plugin-based scanner that works for SilverStripe, WordPress, and Drupal with limited functionality for Joomla and Moodle.
We can clone the Git repo and install it manually or install via pip.
We can access a more detailed help menu by typing droopescan scan --help
We can also try out JoomlaScan, which is a Python tool inspired by the now-defunct OWASP joomscan tool.
JoomlaScan is a bit out-of-date and requires Python2.7 to run. We can get it running by first making sure some dependencies are installed.
While not as valuable as droopescan, this tool can help us find accessible directories and files and may help with fingerprinting installed extensions.
The default administrator account on Joomla installs is admin, but the password is set at install time, so the only way we can hope to get into the admin back-end is if the account is set with a very weak/common password and we can get in with some guesswork or light brute-forcing. We can use this script to attempt to brute force the login.
Attacking Joomla
Abusing Built-In Functionality
let's log in to the target backend at http://dev.inlanefreight.local/administrator. Once logged in, we can see many options available to us. For our purposes, we would like to add a snippet of PHP code to gain RCE. We can do this by customizing a template.
If you receive an error stating "An error has occurred. Call to a member function format() on null" after logging in, navigate to "http://dev.inlanefreight.local/administrator/index.php?option=com_plugins" and disable the "Quick Icon - PHP Version Check" plugin. This will allow the control panel to display properly.
From here, we can click on Templates on the bottom left under Configuration to pull up the templates menu.
Next, we can click on a template name. Let's choose protostar under the Template column header. This will bring us to the Templates: Customise page.
Finally, we can click on a page to pull up the page source. It is a good idea to get in the habit of using non-standard file names and parameters for our web shells to not make them easily accessible to a "drive-by" attacker during the assessment.
Also, we must always remember to clean up web shells as soon as we are done with them but still include the file name, file hash, and location in our final report to the client.
Let's choose the error.php page. We'll add a PHP one-liner to gain code execution as follows.
Once this is in, click on Save & Close at the top and confirm code execution using cURL.
From here, we can upgrade to an interactive reverse shell and begin looking for local privilege escalation vectors or focus on lateral movement within the corporate network. We should be sure, once again, to note down this change for our report appendices and make every effort to remove the PHP snippet from the error.php page.
Leveraging Known Vulnerabilities
At the time of writing, there have been 426 Joomla-related vulnerabilities that received CVEs. However, just because a vulnerability was disclosed and received a CVE does not mean that it is exploitable or a working public PoC exploit is available. Like with WordPress, critical vulnerabilities (such as those remote code execution) that affect Joomla core are rare. Searching a site such as exploit-db shows over 1,400 entries for Joomla, with the vast majority being for Joomla extensions.
Let's dig into a Joomla core vulnerability that affects version 3.9.4.
Researching a bit, we find that this version of Joomla is likely vulnerable to CVE-2019-10945 which is a directory traversal and authenticated file deletion vulnerability. We can use this exploit script to leverage the vulnerability and list the contents of the webroot and other directories.
The python3 version of this same script can be found here.
We can also use it to delete files (not recommended). This could lead to access to sensitive files such as a configuration file or script holding credentials if we can then access it via the application URL.
An attacker could also cause damage by deleting necessary files if the webserver user has the proper permissions.
We can run the script by specifying the --url, --username, --password, and --dir flags. As pentesters, this would only be useful to us if the admin login portal is not accessible from the outside since, armed with admin creds, we can gain remote code execution, as we saw above.
Drupal - Discovery & Enumeration
Discovery/Footprinting
A Drupal website can be identified in several ways, including by the header or footer message Powered by Drupal, the standard Drupal logo, the presence of a CHANGELOG.txt file or README.txt file, via the page source, or clues in the robots.txt file such as references to /node.
Another way to identify Drupal CMS is through nodes. Drupal indexes its content using nodes. A node can hold anything such as a blog post, poll, article, etc. The page URIs are usually of the form /node/<nodeid>.
Not every Drupal installation will look the same or display the login page or even allow users to access the login page from the internet.
Drupal supports three types of users by default:
Administrator: This user has complete control over the Drupal website.Authenticated User: These users can log in to the website and perform operations such as adding and editing articles based on their permissions.Anonymous: All website visitors are designated as anonymous. By default, these users are only allowed to read posts.
Enumeration
Newer installs of Drupal by default block access to the CHANGELOG.txt and README.txt files, so we may need to do further enumeration. Let's look at an example of enumerating the version number using the CHANGELOG.txt file. To do so, we can use cURL along with grep, sed, head, etc.
Trying this against the latest Drupal version at the time of writing, we get a 404 response.
Let's try a scan with droopescan as shown in the Joomla enumeration section. Droopescan has much more functionality for Drupal than it does for Joomla.
Attacking Drupal
Leveraging the PHP Filter Module
In older versions of Drupal (before version 8), it was possible to log in as an admin and enable the PHP filter module, which "Allows embedded PHP code/snippets to be evaluated."
Make sure that PHP Filter permissions has "PHP code text format" enabled
From here, we could tick the check box next to the module and scroll down to Save configuration. Next, we could go to Content --> Add content and create a Basic page.
We can now create a page with a malicious PHP snippet such as the one below. We named the parameter with an md5 hash instead of the common cmd to get in the practice of not potentially leaving a door open to an attacker during our assessment. If we used the standard system($_GET['cmd']); we open up ourselves up to a "drive-by" attacker potentially coming across our web shell. Though unlikely, better safe than sorry!
We also want to make sure to set Text format drop-down to PHP code. After clicking save, we will be redirected to the new page, in this example http://drupal-qa.inlanefreight.local/node/3
Once saved, we can either request execute commands in the browser by appending ?dcfdd5e021a869fcc6dfaef8bf31377e=id to the end of the URL to run the id command or use cURL on the command line. From here, we could use a bash one-liner to obtain reverse shell access.
From version 8 onwards, the PHP Filter module is not installed by default. To leverage this functionality, we would have to install the module ourselves. Since we would be changing and adding something to the client's Drupal instance, we may want to check with them first. We'd start by downloading the most recent version of the module from the Drupal website.
Once downloaded go to Administration > Reports > Available updates.
Location may differ based on the Drupal version and may be under the Extend menu.
From here, click on Browse, select the file from the directory we downloaded it to, and then click Install.
Once the module is installed, we can click on Content and create a new basic page, similar to how we did in the Drupal 7 example. Again, be sure to select PHP code from the Text format dropdown.
With either of these examples, we should keep our client apprised and obtain permission before making these sorts of changes. Also, once we are done, we should remove or disable the PHP Filter module and delete any pages that we created to gain remote code execution.
Uploading a Backdoored Module
Drupal allows users with appropriate permissions to upload a new module. A backdoored module can be created by adding a shell to an existing module. Modules can be found on the drupal.org website. Let's pick a module such as CAPTCHA. Scroll down and copy the link for the tar.gz archive.
Download the archive and extract its contents.
Create a PHP web shell with the contents:
Next, we need to create a .htaccess file to give ourselves access to the folder. This is necessary as Drupal denies direct access to the /modules folder.
The configuration above will apply rules for the / folder when we request a file in /modules. Copy both of these files to the captcha folder and create an archive.
Assuming we have administrative access to the website, click on Manage and then Extend on the sidebar. Next, click on the + Install new module button, and we will be taken to the install page, such as http://drupal.inlanefreight.local/admin/modules/install Browse to the backdoored Captcha archive and click Install
Once the installation succeeds, browse to /modules/captcha/shell.php to execute commands.
Leveraging Known Vulnerabilities
Over the years, Drupal core has suffered from a few serious remote code execution vulnerabilities, each dubbed Drupalgeddon. At the time of writing, there are 3 Drupalgeddon vulnerabilities in existence.
CVE-2014-3704, known as Drupalgeddon, affects versions 7.0 up to 7.31 and was fixed in version 7.32. This was a pre-authenticated SQL injection flaw that could be used to upload a malicious form or create a new admin user.
CVE-2018-7600, also known as Drupalgeddon2, is a remote code execution vulnerability, which affects versions of Drupal prior to 7.58 and 8.5.1. The vulnerability occurs due to insufficient input sanitization during user registration, allowing system-level commands to be maliciously injected.
CVE-2018-7602, also known as Drupalgeddon3, is a remote code execution vulnerability that affects multiple versions of Drupal 7.x and 8.x. This flaw exploits improper validation in the Form API.
Drupalgeddon
As stated previously, this flaw can be exploited by leveraging a pre-authentication SQL injection which can be used to upload malicious code or add an admin user. Let's try adding a new admin user with this PoC script. Once an admin user is added, we could log in and enable the PHP Filter module to achieve remote code execution.
Now let's see if we can log in as an admin. We can! Now from here, we could obtain a shell through the various means discussed previously in this section.
We could also use the exploit/multi/http/drupal_drupageddon Metasploit module to exploit this.
Drupalgeddon2
We can use this PoC to confirm this vulnerability.
We can check quickly with cURL and see that the hello.txt file was indeed uploaded.
Now let's modify the script to gain remote code execution by uploading a malicious PHP file.
Next, let's replace the echo command in the exploit script with a command to write out our malicious PHP script.
Next, run the modified exploit script to upload our malicious PHP file.
Drupalgeddon3
Drupalgeddon3 is an authenticated remote code execution vulnerability that affects multiple versions of Drupal core. It requires a user to have the ability to delete a node. We can exploit this using Metasploit, but we must first log in and obtain a valid session cookie.
Once we have the session cookie, we can set up the exploit module as follows.
If successful, we will obtain a reverse shell on the target host.
Last updated
