Armageddon was a very fun and straightforward machine. The initial access to the machine was very simple, and we needed to do some crafty shell techniques to get access to the user’s credentials. The path to root was the most interesting because it required some modifications to an existing exploit.
Our target was at 10.10.10.233, and after a quick Nmap scan these were the results:
$ nmap -sV -p- 10.10.10.233
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack OpenSSH 7.4 (protocol 2.0)
80/tcp open http syn-ack Apache httpd 2.4.6 ((CentOS) PHP/5.4.16)
Nothing special at the moment, so on the web page the first thing I always check for is robots.txt
The first thing that caught my eye in this list is CHANGELOG.txt. This is because it might give us a hint as to what website software (and more importantly what version) is currently running on this page.
After checking this page, we see that Drupal 7.56 is hosted on the webserver.
Seems like this version is from 2017. There’s probably an exploit available for it. If we do a quick google search for “Drupal 7.56 exploit” one of the first results is a github page for something called Drupalgeddon2. Judging by the name of the machine, and the service running on the box, I’m going to assume that we’re supposed to use this exploit.
Here is a link to the exploit: https://github.com/dreadlocked/Drupalgeddon2
The usage of this script is very simple:
ruby drupalgeddon2.rb http://TARGET/
However, something that I noticed is that you need to have the gem highline installed in order for it to work correctly. This can be achieved by running the following command:
sudo gem install highline
Once that’s all done and the script is executed, we immediatly get a shell:
Nice! Now the next step is to try and escalate to user. I tried grepping around in the webroot for database credentials and I found some for the database drupal!
MySQL DB creds were found in sites/default/settings.php and the credentials were:
drupaluser:CQHEy@9M*m23gBVj
If you try and interact with the MySQL database from this shell, you’ll have a hard time. This isnt a proper (fully interactive) bash shell, so our inputs into the mysql commands are getting messed up. One way around this is setting the username and password as variables, and then calling them from the mysql command line tool like so:
mysql -u $user -p$password -Bse "command;command;"
After that, we are presented with a hash dump of the user accounts on the drupal site:
These hashes look a little unfamiliar. When checking the hashcat example hashes page, we can see that there is a Drupal 7 hash type! Time to crack!
Using the following command with the rockyou.txt wordlist, we can crack the password very quickly:
hashcat -m 7900 hash.txt rockyou.txt
After a couple seconds, our password is: booboo
We can use the password booboo with the user brucetherealadmin to ssh into the machine and get user.txt!
Now that we have a nice, fully functional SSH connection, we can focus on escalating to root. The first thing I did was run [LinPEAS.sh] to see if there was any low-hanging fruit for privesc.
Luckily, linpeas found something!
It seems that we are allowed to run sudo snap install * without a password! But because HTB machines don’t have internet access, we will probably have to create out own malicious package.
When researching snap privesc vulns I came across [dirty_sock] which installs a malicious snap package that creates a new root user that we can su to.
Unfortunately, this exploit doesn’t work in our case because the machine doesn’t have a vulnerable snap version. However, we can copy the malicious snap package data and install it locally without the use of the rest of the dirty_sock exploit.
I achieved this by decoding the base64 snap package in the ditry_sockv2.py file and saving it on the target machine. Then, all I had to do was install the malicious snap package:
sudo snap install --dangerous --devmode package.snap
From there, we can su to dirty_sock with the password: dirty_sock
I Hope this helped some of you!