HTB - Admirer

Zweilosec's write-up on the easy difficulty Linux machine 'Admirer' from https://hackthebox.eu.

Overview

An easy difficulty Linux machine that has an interesting take on database manipulation to obtain a local file inclusion vulnerability. It also has an interesting new (to me) way to leverage sudo privileges to gain privilege escalation. In all, this was a fun machine that taught me some interesting new tricks!

Enumeration

Nmap scan

I started my enumeration with an nmap scan of 10.10.10.187. The options I regularly use are: -p-, which is a shortcut which tells nmap to scan all ports, -sC is the equivalent to --script=default and runs a collection of nmap enumeration scripts against the target, -sV does a service scan, and -oA <name> saves the output with a filename of <name>.

Looking at the results of my nmap scan I saw that only ports 21 (FTP), 22 (SSH), and 80 (HTTP) were open.

I started out by trying to log into FTP, but it did not allow anonymous access.

Next, I opened a browser to see what was being hosted over HTTP and found a website of someone who was an "Admirer of skills and visuals". There did not seem to be anything useful on the site itself.

robots.txt

Nmap pointed out that there was a robots.txt file, so I checked it out. I found a potential username waldo and also a folder admin-dir.

Navigating directly to that page gave me an access forbidden error, so I fired up Dirbuster and ran it on this directory. This led me to a few useful sounding files: contacts.txt and credentials.txt.

The file contacts.txt contained some more potential usernames and a potentially useful email address format. I also noticed that waldo seemed to be a fan of The Big Bang Theory tv show, which could also be useful information.

credentials.txt contained credentials for a few services, so I added them to my users and passwords files.

Initial Foothold

Next I used hydra to attempt a brute-force attack against SSH to see if any of the credentials would allow me to log in.

The FTP credentials seemed to also work for SSH! However, the connection was closed immediately upon logging in. After trying various ways to bypass this and failing, I moved on to try the credentials for FTP instead.

Using the ftp credentials, I was able to log into the FTP server. I found a few interesting files and exfiltrated them back to my machine for analysis.

The database backup

The file dump.sql contained a dump of the website database. Unfortunately, it seemed as if the only useful information was the server version information and the database name and the name of a deleted table that looked to contain website files. I thought that this information could come in handy so I made note of it.

  • Database: admirerdb

  • Table: items (deleted)

  • Version: MySQL dump 10.16 Distrib 10.1.41-MariaDB, for debian-linux-gnu (x86_64)

The Employees3 table had another list of potential usernames and email addresses that I added to my lists.

Back-end code backup

After fully checking out the database, I moved on to the file html.tar.gz. I decompressed the tar file with gunzip and found that it contained a backup of the website's back-end code, including a very interesting PHP file called admin_tasks.php in the /utility-scripts/ folder.

This file looked like a nice little backdoor that the admin had left for me called the "Admin Tasks Web Interface (v0.01 beta)". I was very interested in options 4 through 7, which could potentially give me very sensitive system information.

in the same folder was db_admin.php which contained another set of credentials, this time for the user waldo who I had seen in the robots.txt.

There was also another password for waldo in the index.php file. This also referenced the items table that had been deleted from the database I exfiltrated. If I could get a web shell into this table, the page would run it for me when the page loaded.

Inside this HTML backup was a different version of the robots.txt. This time the disallowed folder was called /w4ld0s_s3cr3t_d1r/, which I had access to as a folder in the backup. This folder contained the files contacts.txt and credentials.txt which appeared at first to be the same as before.

The credentials.txt had most of the same information as before, but waldo seemed to have left his bank account password in this one. Despite finding a couple more passwords, none of these worked for logging into SSH for any user.

I navigated to http://10.10.10.187/utility-scripts/admin_tasks.php which brought me to a website for running administrative tasks on the server.

I didn't find much useful other than the fact that the page was running in the context of the www-data user.

I tried to run the disabled scripts, which gave the message: Insufficient privileges to perform the selected operation.

After I checked back on my Dirbuster scan of the /utility-scripts/ folder, I noticed it had found a new page adminer.php where I found an adminer database management portal.

I noticed the version was 4.6.2, though the page said right next to it that there was a version 4.7.7 available to download. A search for adminer 4.6.2 exploit brought me to https://sansec.io/research/adminer-4.6.2-file-disclosure-vulnerability. This led to https://sansec.io/research/sites-hacked-via-mysql-protocal-flaw, which in turn linked to a MySQL exploit on GitHub at https://github.com/Gifts/Rogue-MySql-Server/blob/master/rogue_mysql_server.py. I also found a few other references that gave a pretty clear picture of how to exploit this particular web SQL management portal.

To sum all of this up, the easiest way to exploit this portal is to set up a local MySQL database and have the remote server connect to it. I found instructions for how to do this at https://www.microfocus.com/documentation/idol/IDOL_12_0/MediaServer/Guides/html/English/Content/Getting_Started/Configure/_TRN_Set_up_MySQL_Linux.htm

Road to User

The rogue MySQL server

I did a bit more research to figure out exactly how to set up the MySQL database. The following articles gave me the last bits of information I didn't already know (specifically, how to create a user and assign it permissions).

After creating the database and a table called admirer, I created a user named test and gave it full permissions to manage the database.

Next I had to set the binding for the server to the address 0.0.0.0 so that the external service could connect to it by my IP. The default is 127.0.0.1 which is localhost only.

After changing the server bind-address setting to 0.0.0.0 I had to restart the mysql service for it to take effect. After that I was able to login to my database in the Adminer portal.

Finding user creds

This bug bounty write-up detailed what I needed to do next. Essentially, I logged into the remote server's database management portal, but it was my own local database that I logged into. After that, I abused a feature of MySQL that allows for local files to be imported into the database. This is a type of local file inclusion (LFI) vulnerability.

To test for the local file inclusion vulnerability I first tried to get /etc/passwd but was denied access to that file. Since I was fairly sure that this portal was still only running in the context of www-data I decided to try to get a file I knew I could access: index.php.

I wasn't even sure that this was going to work, but to my surprise it retrieved the file and added it to my database. I now had a way to read through the source code of the production website as opposed to the backups I downloaded earlier.

Much to my surprise...there was yet again another password contained in this file. Before trying to download any more files I decided to try to brute force SSH login again with this new password.

I had finally found a usable password for waldo! I hoped that it wouldn't just kick me out like it had with ftpuser.

User.txt

Luckily it logged me right in, and I was able to collect my hard-earned loot!

Path to Power (Gaining Administrator Access)

Enumeration as user waldo

One of the first things I always do when gaining access to a new user is to check what privileges I have with sudo -l. I was pleasantly surprised to get a result back that I was able to do something with a bash script called admin_tasks.sh. I was curious about what this script did, and also what the group admins could access.

Hmm...so the admins group only has access to this scripts folder. Time to check out the bash script.

This bash script seemed to be a completed version of the PHP version of admin-tasks I had seen earlier. Inside the script it references a few other files:

  • /opt/scripts/backup.py

  • /srv/ftp/dump.sql - this is the one I found through the ftp server I think

  • /var/backups/dump.sql

I ran the option for viewing the root crontab and noticed that it was set to clear out files every 3 minutes. It looked like putting files in /tmp/ or files with an extension starting in p in waldo's home directory would be a short-lived affair.

I was also able to run the script to backup the SQL database, /etc/passwd, and /etc/shadow. Unfortunately, each of the backup files were owned by root so I had no way to read them.

The one function that looked a bit different from the others was the one that backed up the HTML files for the website. This one called a separate python script, which would also be run as root, so I decided to check it out as well.

The file /opt/scripts/backup.py that the bash script referenced to do the web backup contained code that seemed potentially useful.

SETENV and sudo

I had an idea that since this python script was being run as root that maybe I could get it to read a file of my choice, however all of the files referenced in the python script has absolute paths so no no hijacking seemed possible there.

I did some research for sudo setenv python since I saw in my sudo -l output the word SETENV listed in front of the bash script I could run. In the search results was a very interesting article that talked about hijacking python library imports.

SCENARIO 3: Redirecting Python Library Search through PYTHONPATH Environment Variable

The PYTHONPATH environment variable indicates a directory (or directories), where Python can search for modules to import.

It can be abused if the user got privileges to set or modify that variable, usually through a script that can run with sudo permissions and got the SETENV tag set into /etc/sudoers file.

This sounded exactly like the situation I had found.

Armed with this information, I wrote a short python library to replace the one referenced in the script. I named it shutil.py so the script would call it instead of the real one, and also made a function named make_archive() since this was what was specifically being imported. I wrote my function so that it would create a bash shell, and then echo my new username.

After trial and error, I was able to get my library to be loaded and executed, though I did not get a shell like I expected. However, I could see that the output of the whoami command did appear, so I had proof that I could run commands as root.

I got an error when trying to exploit this with version one of my evil python library, but that error also confirmed that I was making progress. It told me that my make_archive() function takes 0 positional arguments but the script that was calling it was feeding it three.

I modified my function to take 3 arguments (which I didn't use for anything), and also added a line to send me a reverse shell since calling a new shell wasn't working, and then it worked just fine. I didn't expect the version of nc that was installed to have -e capability, but I was happy it did!

Root.txt

Thanks to polarbearer and GibParadox for creating this fun and interesting machine that taught me some new ways to take advantage of some common vulnerabilities and misconfigurations.

If you like this content and would like to see more, please consider buying me a coffee!

PreviousHTB - TracebackNextHTB - Blunder

Last updated

Was this helpful?