Nmap scan:
An Nmap vuln scan reveals there is a robots.txt file on port 80.
We can head to that directly.
The robots.txt file gave us the /admin-dir directory.
However, visiting it gives us a 403.
I used gobuster on this directory and found a credentials.txt file.
We can view this file to find some FTP credentials.
Then, we can login to FTP.
Within FTP, we can find a backup of the website.
When we extract this file and unzip it, we would be able to find a few directories of use.
There are 2 directories, the utility-scripts and w4ld0s stuff. The secret directory revealed one more credential.
The utility-scripts folder revealed some database credentials.
The index.php folder also revealed some credentials.
Afterwards, I was stumped here because I did not find any place to work on this. I understood that there was some kind of admirer-sounding application running somewhere, but gobuster was revealing nothing. Then, googling loads led me to the Adminer software, which was accessible on this website at adminer.php.
So far, none of the credentials work with FTP or SSH. The next logical step is to take a look at this directory to find an Adminer instance at /utility-scripts/adminer.php.
Adminer is a tool for managing MySQL databases within the machine. There is one specific LFI that can be exploited here:
This requires us to start a local MySQL server, which can be done using this: (alternatively, run mysql on the attacking system)
After setting up the SQL server, we can change the IP address to the host's within our /etc/mysql/mariadb.conf.d/50-server.cnf file. Then, we need to execute these commands:
This would create a new database for our LFI contents to go to. Within Adminer, we can login with OUR own root user credentials. Within the database, we would want to execute these queries to load files. I tried reading the /etc/passwd file but it didn't work (for some reason).
It seems that we aren't given permission to load certain files. Going back to the backup folder we retrieved, we can attempt to read the /var/www/html files based on the FTP backup we retrieved earlier.
We can find a credential within the /var/www/html/index.php folder, which has been updated to &<h5b~yK3F#{PaPB&dA}{H> instead of the previous one we found.
This credential works with SSH as waldo.
It seems that we have permission to set the environment variables for this script.
This was the script:
Of all the functions within this, option 6, which is the backup_web() one looked the most vulnerable:
It was the only one that wasn't running a stock binary from Linux. The backup script was as follows:
Whenever Python imports a module, it checks the PYTHONPATH variable for the directories to import it from, kind of like regular PATH. The SETENV privilege would let us change this variable to anything we want.
So to exploit this, we would simply need to change the PYTHONPATH variable to make the script import a malicious script that we have created. Because the module checks for shutil, we would need to name our malicious script shutil.py with a function make_archive() that takes 3 parameters but does nothing.
Afterwards, we need to find a directory that works. For some reason, the /home/waldo and /tmp directories were consistenly being cleared in this machine. As such, I used the /var/tmp directory, which seemed to be alright.
A quick Python script to echo our public key into the authorized_key folder AND create a SUID binary should work:
Afterwards, we can change the PYTHONPATH used for the script.
Then, we can SSH in as root using the key we have.
