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:
