Again, we start with sudo /home/kali/AutoRecon/src/autorecon/autorecon.py 10.10.10.233
Sidenote: Newer versions of Kali that do not use root by default require sudo whenever checking UDP ports.
So, we have SSH (TCP 22) and Apache 2.4.6 running Drupal 7 (TCP 80). Judging by the name of the box (Armageddon) and the Drupal 7 instance, we can reasonable assume that this will be a Drupalgeddon (CVE 2018-7600) box. A simple Duck Duck Go search will reveal a GitHub repository dedicated to Drupalgeddon's exploit. That repo can be found here.
git clone https://github.com/dreadlocked/Drupalgeddon2
Now we need to know where to point the drupalgeddon2.rb file. Visiting http://10.10.10.233 shows us a login page. In order for this to work, you may need to install kernel_require.rb using:
sudo gem install highline
And now we have a small shell. Looking through the files, we find the settings.php file that contains a password.
From here, we need to get the database names and (hopefully) a username and password for/from that database. We can do this by using:
mysql -u drupaluser -pCQHEy@9M*m23gBVj -e 'show databases;'
mysql -u drupaluser -pCQHEy@9M*m23gBVj -e 'use drupal; show tables;'
mysql -u drupaluser -pCQHEy@9M*m23gBVj -e 'use drupal; select * from users;'
Success! We have a mysql/Drupal DB password hash. We can echo it into a file and hopefully crack it with hashcat.
echo '$S$DgL2gjv6ZtxBo6CdqZEyJuBphBmrCqIV6W97.oOsUf1xAhaadURt' > hash
sudo hashcat -m 7900 -a 0 -o cracked.txt hash /usr/share/wordlists/rockyou.txt --force
If done correctly, it should crack the hash to 'booboo'
This can also be done in the Windows version of hashcat as I have done below.
Now we need to see if 'brucetherealadmin' reused his Drupal Password for SSH. It appears that he has! Password reuse is one of the worst and common problems in the wild. Use of Password Managers with randomly generated passwords, or a Privileged Account Management solution (such as CyberArk, Thycotic, One Identity, and many others) with a privileged account rotation schedule all but eliminates this as a possible attack vector!
During our system enumeration, we see that brucetherealadmin can sudo snap install without a password. So we now need to craft a malicious snap install in order to privesc, but before we do let's grab the user.txt flag!
There is a wonder exploit already prepared for us called Dirty Sock. It can be found here. Following the example, we come up with the below:
Executed on the Victim Machine, we can then run:
[brucetherealadmin@armageddon ~]$ sudo /usr/bin/snap install --devmode installation.snap
Now we can sudo su to dirty_sock with the password dirty_sock. Last but not least, we check the sudo privileges and can see we can execute everything!!!
[brucetherealadmin@armageddon ~]$ su dirty_sock
[dirty_sock@armageddon ~]$ sudo /bin/bash
and we now have a root shell!
And with that, another box down!