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
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
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
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.
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
Vulnerable Plugins - mail-masta
Vulnerable Plugins - wpDiscuz
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
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
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.
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.
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
Let's dig into a Joomla core vulnerability that affects version 3.9.4.
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.
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."
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.
Once downloaded go to Administration > Reports > Available updates.
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
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.
Drupalgeddon
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.
Drupalgeddon2
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
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
