Hack the Box Writeup: Fortune

This was a very tough box for me and I needed a hint from the forums to complete it - the box is rated 'insane' for a reason!

Nmap scan:

HTTP shows:

I tried HTTPS but it looks like it needs a certificate. Gobuster and dirb came up with absolutely nothing.

Openssl showed some stuff:

'charlie' and 'bob' are potential usernames.

I fired up Burp and took a look at what was going on:

I threw this into Burp's Repeater and was stuck here for quite a while because I didn't think to URL encode things. Once I tried that, experimentation showed that the special characters & and / were what stymied me before but now we have RCE:

Time to do some more enumeration. There are some interesting users:

The webapp is running as _fortune:

After a lot of poking around, I find /home/bob/ca/openssl.cnf:

At this point it was becoming pretty clear that the path forward was to grab the proper certificates to generate a p12 file so I could access the HTTPS portion of the machine. There are a lot of files in /home/bob/ca:

I cat'ed /home/bob/ca/intermediate/private/intermediate.key.pem and /home/bob/intermediate/certs/intermediate.cert.com and saved them on my machine then used openssl to generate a p12 file:

I then imported the certificate into Chrome. From settings:

Click on 'Import', select the new .p12 file and get prompted for a password:

Now when I load up https://fortune.htb, I'm prompted to choose the certificate:

Finally the page loads:

I clicked on the 'generate' link and received this:

I copied and pasted the key to a file 'rsa.key.'

From the page, we can see it's a key for AuthPF. When I initially enumerated the system, /etc/passwd had 'nfsuser' with the shell '/usr/sbin/authpf':

I tried nfsuser with the key and was able to login:

It did not respond to any commands so I ran the ssh command again with a '-v' flag for debugging and see this:

The port-forwarding thing made me run nmap again and now we see additional ports open:

I list the NFS mounts:

Let's try mounting it:

Contents:

I see that the owner/group of charlie's home directory is my Kali machine's unprivileged user so I run 'su <user>' and am now able to get into Charlie's directory:

User flag:

I take a look at the mbox file and learn the pgadmin4 password is the same as the root password:

With write access to charlie's home directory, the next logical step was to give myself ssh access. I use ssh-keygen to generate a key pair:

I then edited the 'authorized_keys' file in charlie's ssh folder and pasted in the contents of the newly generated id_rsa.pub. After that, I was able to ssh in as charlie:

While numerating the system, I found the pgadmin4.db was located in /var/appsrv/pgadmin4/pgadmin4.db so I transferred that to my machine over scp. I then used the built-in 'SQLite database browser' to open it. After some clicking around, I find some hashes:

The email said the dba password is the same as the root password so I kept looking and found this:

I ran grep -R crypt * from /usr/local/pgadmin4/pgadmin4-3.4 and found some interesting files:

I checked out crypto.py and saw this:

Connection.py:

This is where I got stuck for a long time. As a python beginner, I didn't really know what to do from here other than learning that the current user's password is used as the key to decrypt the encoded password. After a whole lot of flailing and failing at trying to cobble together code to decrypt the password, I finally got a hint that crypto.py is a library (in retrospect I should have figured that out when I saw a function being defined - oh well).  I then transferred crypto.py to my machine and wrote a very short script that imported its decrypt function and used it:

'encpass' is the encrypted dba password and 'userpassword' is Bob's hashed password as he is the one who set this up.

I ran the script and was very happy that it worked:

With the password, I could now su root and get the root flag: