HTB - ForwardSlash
Overview

Useful Skills and Tools
Enumeration
Nmap scan
I started my enumeration of this system with an nmap scan of 10.10.10.183. The options I regularly use are: -p-, which is a shortcut which tells nmap to scan all TCP 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 -oN <name> saves the output with a filename of <name>.
This machine only had two ports open, 80 - HTTP & 22 - SSH. Since I had no credentials to use for SSH I fired up a browser and navigated to http://10.10.10.183.

When I connected to port 80 it automatically redirected to forwardslash.htb. In order to redirect my request to get to this pageI had to add the following line to /etc/hosts:
After adding the hostname to /etc/hosts I navigated to http://forwardslash.htb and was greeted by webpage that had been defaced by the "Backslash Gang".

The Backslash Gang left a message behind:
Defaced • This was ridiculous, who even uses XML and Automatic FTP Logins
This looked like clues as to how they managed to get into the site. I made note to look for services related to FTP and XML during my enumeration. Other than this defaced page, there was not much to go off so I continued my enumeration.
Dirbuster - forwardslash.htb

Using Dirbuster I found what initially looked like a large number of files, but after doing some closer inspection, the server was simply giving a 403 - Access Denied error to any request that contained .htaccess or .htpasswd in it. One accessible file stuck out, however.

It appeared that one of the server owners had left the other a note. The file note.txt mentioned two potential usernames: pain and chiv and also mentioned that there is a backup site.
Virtual Host Enumeration
Ippsec's video on HTB - Player describes "vhost enumeration" and explains how to search for other virtual hosts which map to the same IP address. From watching this video before I knew that you could enumerate these sites using the tool gobuster:
I used a wordlist of the top 110,000 most common subdomain names, and quickly found the backup site that chiv had mentioned in his note. Once again, I added this domain name to /etc/hosts and tried to access the site.
The Backup site

Navigating to http://backup.forwardslash.htb auto-redirected me once again, this time to a login page at http://backup.forwardslash.htb/login.php. Since I did not have any credentials, I signed up for a new account and logged in.

Once I was logged in, I was greeted by this page. This so-called dashboard did not offer much to do.

The machine creator left behind a message for everyone playing with a friendly public service announcement. Don't smoke, folks. Its disgusting and think of all of the cat-girls you can save.
Since I wasn't finding much to use, I started employing cewl to create a wordlist from each of the pages on this site and from the main page.
This is a good habit to get into: always add new sites to cewl word list just in case. This will often give you potential usernames, passwords, or new subdomain and sites to explore.
Dirbuster redux - backup.forwardslash.htb

Around this time my Dirbuster report from this new subdomain had finished. There were a lot of results to go through, so I decided to finish going through the ones I had seen when I logged in before exploring further.

The URL and Submit sections on the http://backup.forwardslash.htb/profilepicture.php page were disabled, but I wondered if it was something I could easily bypass by checking the HTML code.

As I suspected, they had simply used the "disabled" attribute for the two sections. Removing this code made it so the fields were again active.
Local File Inclusion testing
used burp to enumerate the potential for LFI

got /etc/passwd
I found two users with login capability: chiv and pain. I have seen them both leaving notes to the other in the HTML code, and note.txt earlier.
While testing different methods of both uploading files and downloading files from the server, I accidentally pasted in the URL for http://backup.forwardslash.htb/config.php and got the back-end code file back.
I now had what looked to be a password hash for the www-data user, but I knew from /etc/passwd that the user was not able to log into a shell. I kept trying for all of the other sites I had seen in my enumeration using dirbuster such as api.php, login.php, profilepicture.php but each time I just got back the message "Permission Denied; not that way ;)". The winking smiley and the "not that way" line made it sound as if I was headed in the right direction, but I just needed to try a bit harder.
Bypassing web filtering
My initial thought was that there was a web-application firewall, so I searched around a bit until I found https://www.secjuice.com/php-rce-bypass-filters-sanitization-waf/. I kept looking for more ways after testing different bypass methods, as nothing seemed to even get a response. I started doing a bit of research into bypassing PHP web filtering and came across a section on PayloadsAlltheThings that was made just for this situation with PHP file inclusion. https://github.com/swisskyrepo/PayloadsAllTheThings/blob/73aa26ba6891981ec2254907b9bbd4afdc745e1d/File Inclusion/README.md#wrapper-phpfilter
There were various code examples for bypassing PHP filters, such as by encoding the request in base64 or rot-13. I decided to just try using the base64 encoding first, trying pHp://FilTer/convert.base64-encode/resource=login.php. Luckily for me, it worked right away! I was able to retrieve the login.php page, encoded in base64. I simply had to use the decode function in Burp to get the page code. Unfortunately there was nothing useful in that page. After that I went through and downloaded all of the pages I had seen in dirbuster until I got to pHp://FilTer/convert.base64-encode/resource=dev/index.php which returned the base64 string:
which decodes to: dev/index.php
Here was the hardcoded FTP-Autologin code that the Backslash Gang had so disdained, and I now had credentials for the user chiv . I then tried using this username/password combo to SSH into the machine, and was greeted with a shell.
Initial Foothold
Enumeration as user chiv
chivUnfortunately, this user was not the one with the flag, so I assumed that I would need to move laterally to pain in order to get my first score.
linpeas.sh my go-to enumeration all-in-one script
open ports -nope
users
usr/bin/backup
The python script
I had access to pain's home folder, which was a bit unusual. Inside was another note, and a python script with some ciphertext in the encryptorinator/ folder.
I exfiltrated the two files to my machine to make analysis easier.
The python script encrypter.py was redacted, and no longer contained the code to decrypt the ciphertext.
At first, I thought "lets check the backups I saw while enumerating with linpeas and see if the whole script is available". (By the way, there is no "whole script" and you could go ahead and decrypt it right now.)
Road to User
Further enumeration
In the /usr/bin/ folder there was an interesting program that stuck out to me.
This program had the setuid bit set and was owned by pain. I thought that I may be able to use this binary to escalate privileges laterally to pain.
In the /var/backups folder, I found a bunch of files that had been backed up, as well as another note from pain.
I assumed he was talking about this file: -rw------- 1 pain pain 526 Jun 21 2019 config.php.bak since I had found another password in the config.php file on the backup site earlier. Perhaps this password was not encrypted like the previous one.
and we do not have access to /var/backups/recovery. Will need to go back and check out that backup binary again. Since its in $PATH I just ran it.
hmmm...its looking for the hash of something, and says something about only working if the backup is taken in the same second, and displays the time. After some experimentation, discovered that the hash is an md5 hash of the current time in HH:MM:SS format. echo $(date +%T) | md5sum | cut -c1-32 will get me a hash of the time that matches the time in the backup program, now need to script reading the file and sending the hash at the same time (cut because md5sum adds - <filename>at the end of its output).
Try it on the config backup. I had seen a long hash in the one I found before, maybe this one is pre-encryption.
Oooohhhh...need to make a symbolic link of the file, to the proper hash; also don't need to call backup ON the file, just run it in the directory you want it to work in
After much trial and error: getting the hash of the time wasn't working (machine or network lag perhaps?) so I decided to pull the hash directly from the program and symlink the backup file to it
after some more trial and error...found out that the script must be executed from user's home directory. Successfully got my test file to be read. Next, the config backup/.
Finding user creds
Tried to decrypt the password at first, though it was not a hash despite its looks, was the actual password
User.txt
Path to Power (Gaining Administrator Access)
Enumeration as User pain
painEnumeration as this user was pretty short, since I had already found most everything as chiv. As I always to when logging in as a new user, I checked my privileges with sudo -l and groups.
The backupoperator group sounded familiar. I had seen it earlier on a folder I couldn't access in /var/backups.
The encrypted backup file
I navigated to this folder and found the file encrypted_backup.img. This had to be the backup file that pain had sudo rights to manipulate.
When trying to use luksOpen to decrypt the backup file, however, it prompted me for a passphrase. The note in pain's home folder had mentioned some "crypto magic" that had been applied to the key, so I went back to try to decrypt that ciphertext with the python script.
Python decryption script revisited
Working on script, lots of trial and error
Fixing UnicodeDecodeError in Python scripts
recieved error: while trying to decrypt. (have seen this with rockyou.txt in the past as well). https://github.com/wpscanteam/wpscan/issues/190 - encoding problems with rockyou.txt and ciphertext solved by using 'latin' encoding
final script:
Python script ouput
Since I had now done the hard part and decrypted the backup password with my python script, the next part was fairly straightforward. The commands we are allowed to use with sudo spell out what we can do.
From the CryptSetup man page: http://manpages.ubuntu.com/manpages/xenial/man8/cryptsetup.8.html.
luksOpen (old syntax)
Opens the LUKS device <device> and sets up a mapping <name> after successful verification of the supplied passphrase. If the passphrase is not supplied via --key-file, the command prompts for it interactively.
the device name will be our backup file, the <name> will be backup (command says /bin/mount /dev/mapper/backup ./mnt/) and we will need to make a directory called ./mnt/
Getting a shell
I now had an SSH key. Since neither pain or chiv needed an RSA key to login using SSH I assumed this was root's private key.
Root.txt
Trying to login with this key, I encountered an error I had seen before.
I knew I was right that this was root's key. Though, as always, you have to make sure to apply chmod 600 <file> to your SSH private keys before use!
and...root. While logging in, I received the error load pubkey "root.id_rsa": invalid format, though it didn't cause any issues. According to https://askubuntu.com/questions/698997/key-load-public-invalid-format-with-scp-or-git-clone-on-ubuntu-15-10/700172#700172 this happens when the public key is missing or corrupted. In this case it wasn't present, therefore the error.
Thanks to InfoSecJack chivato& for <something interesting or useful about this machine.
If you like this content and would like to see more, please consider buying me a coffee!
Last updated
Was this helpful?