This box was rather basic, but the privilege escalation did not work the intended way and I am not sure if that was my fault. That is why I used a different way in the end. Either way, the main exploit was a lot of fun and I edited the commands for it to script a basic PoC myself.
The version is striking here as this searchsploit query confirmed:
searchsploit drupal 7.5
Considering the name Armageddon and the Drupal version, it will be either Drupalgeddon2 or 3 for the RCE. There are metasploit modules for it, but I want to do it without for now.
Great, this worked perfectly. As you can see, this exploit has two stages. First you obtain the form-build-id via an authentication bypass, already giving the injected command, in this case uname -a. Then you obtain the output of the command, querying the page for the according form build id. Here you can see the full process as it worked out for me:
As you can see, I already achieved RCE with this. Now I want more automation and a shell.
Shell Access
I assembled this command, which executes the uname -a command in one line of bash code:
From that I created a bash poc to simplify the execution:
Output:
Using my poc and the following payload, I could write a simple php shell that can hopefully enable me to get a proper shell:
Great! So far so good. Though, I did not manage to get a bash shell with this at first. I did some more enumeration:
Output:
'settings.php' looks interesting. I used cat and saved the output to search it for credentials. In such cases I like to run something along those lines: cat file | grep -i 'password'
This yielded me a database user with a password:
Using cat to get /etc/passwd from the server I also found the user 'brucetherealadmin'.
The password does not work with the user, so I will try cracking the hash.
After these attempts did not work and I also failed to get a bash shell, I searched for other options, using my php shell. Python seems feasible and I don't know why I did not think about this so far.
This finally worked the get an actual shell on the host:
User Access
Since we still have the SQL credentials, we can try to dump the sql database for drupal again and search it. I am certain it did not work before because of some encoding issue. From the box it should work. And indeed:
Using this page I identified the hash type to be Drupal7:
Running some enumeration commands returned some possible privilege escalation vectors:
There was an SUID binary and the kernel was very old too. Since these results were already pretty interesting I did not bother enumeration further for now.
Privilege Escalation
I searched for snap as a GTFOBin, but the two exploits I tried did not work. This is about creating a malicious snap package to then install it with elevated permissions.
It already took me a while to find a working snap package generation method. This one was it:
But whatever I tried, I always received the error 'snap is unusable due to bad permissions; contact developer'. Since the intended way seemed to be broken I resorted to a different way, this time using metasploit. Of course it could also be that I just found broken exploit generators. But I focused on the old kernel from there on. local_exploit_suggester returned some output to work through:
Well, now it was easy. Though I would have preferred the snap way. I might look into that another time as this was obviously the intended way to get root.
[user@thonkpad chisel]$ nc -lnvp 4444
Listening on 0.0.0.0 4444
Connection received on 10.10.10.233 56148
sh: no job control in this shell
sh-4.2$ pwd
pwd
/var/www/html
1 exploit/linux/local/cve_2021_4034_pwnkit_lpe_pkexec Yes The target is vulnerable.
2 exploit/linux/local/network_manager_vpnc_username_priv_esc Yes The service is running, but could not be validated.
3 exploit/linux/local/pkexec Yes The service is running, but could not be validated.
4 exploit/linux/local/su_login Yes The target appears to be vulnerable.
5 exploit/linux/local/sudo_baron_samedit Yes The target appears to be vulnerable. sudo 1.8.23 is a vulnerable build.
6 exploit/linux/local/sudoedit_bypass_priv_esc Yes The target appears to be vulnerable. Sudo 1.8.23 is vulnerable, but unable to determine editable file. OS can NOT be exploited by this module