> For the complete documentation index, see [llms.txt](https://kte-infosec.gitbook.io/htb-machine-writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kte-infosec.gitbook.io/htb-machine-writeups/keeper.md). # Keeper Linux, Easy (09/04/2023) ## Introduction Keeper is an easy-difficulty Linux machine that features a support ticketing system that uses default credentials. Enumerating the service, we are able to see clear text credentials that lead to SSH access. With `SSH` access, we can gain access to a KeePass database dump file, which we can leverage to retrieve the master password. With access to the `KeePass` database, we can access the root `SSH` keys, which are used to gain a privileged shell on the host. ## Enumeration First I began the engagement by scanning with `nmap`, applying flags to enumerate for versions, standard scripts, output a file in `nmap` format, and the IP designated for the `Keeper` machine. I placed this in a `Keeper` directory to organize my notes and findings along the way. ***

`nmapp -sV -sC -oN nmap.scan 10.129.70.209`

*** After the scan results were returned, it appeared that both `port 22` and `port 80` were open (as most Easy HTB machines usually), and there was some returned version numbers of services running like `OpenSSH 8.9p1` and `nginx 1.18.0`. Considering the difficulty of brute forcing `SSH` due to lockout policies, it's safe to say this port can be ignored for now. I proceeded to enter the IP into the `Firefox` web browser. ***

This appears to be a redirect with a revealed `domain name`

*** I hovered over the redirect to check the hyperlink, and it appeared to point to a resolved address of `http://tickets.keeper.htb/rt`. I went ahead and added both `keeper.htb` and `tickets.keeper.htb` to the `/etc/hosts` file. ***

Add both, as there could be more subdomains for enumeration

*** The link `http://tickets.keeper.htb/rt/` appeared to be a ticket tracking platform for IT tickets called `Request Tracker`. I immediately noticed a `version number`, so I performed a quick Google Search to see if any authentication bypass existed before `brute forcing`. It did not yield any immediate results, so I proceeded by searching for `default credentials`. Funny enough, a set of credentials was revealed (redact root:password), and I was able to successfully log into the application. ***

Login page with Request Tracker version 4.4.4 displayed

*** Once logged in, I began to poke around and see what secrets this application held. There are some tools, an Admin settings list, and a few other items that look a little interesting, but what really caught my eye was the `most recent ticket` on the tracker. Sometimes employees may request credential changes or reveal sensitive information, and in this case, a `crash dump of keepass`. `KeePass` is a free open source password manager. Passwords can be stored in an encrypted database, which can be unlocked with one master key. ***

Message thread between user Lise Norgaard and IT

*** ## Foothold It was safe to say that this `KeePass Crash Dump` was the priority target, so reading that its location was not on the application, it was time to dig further and determine a point of entry. Enumerating the user page for Lise didn't yield any results, but considering the compromised account is `root`, I had privileged access to edit user configurations. Taking a look at `lnorgaard's` user profile, a `comment` about the user shows the initial password for a new account. ***

The comment showing the new account password

*** Logging into the Request Tracker application was performed with `default credentials`, so it is safe to assume that this password could be a viable entry point to the machine. I tried the credentials over the `SSH` port from scanning earlier, and this theory held true. I could now obtain the `user flag` and begin enumerating for `privilege escalation` opportunities. ***

*** ## Privilege Escalation My first instinct landing on the machine was to find the original priority target, the `KeePass crash dump`. Recalling Lise's ticket in Request Tracker, the location of the file is in her `home directory`. A quick `ls -la` shows the zip file titled `RT30000.zip`. ***

The zip archive with some interesting permissions

*** Considering the permissions, all users are able to `read`, even though the owner of the file is `root`. I ran the `unzip` command to extract the files titled `KeePassDumpFull.dmp` and `passcodes.kdbx`. Being my first run in with these types of files for this program, I went straight to Google to perform some research on them and figure out how to extract credentials from the dump file. ***

*** I discovered a handy tactic that involved [CVE-2023-32784](https://nvd.nist.gov/vuln/detail/CVE-2023-32784). In KeePass 2.x before 2.54, it is possible to recover the cleartext master password from a memory dump, even when a workspace is locked or no longer running. A tool called [**keepass-dump-masterkey**](https://github.com/matro7sh/keepass-dump-masterkey) will be used with the extracted files in order to obtain the `master password` and view the `credential database`. I began by using \`scp\` to copy the \`RT30000.zip\` file to my attack box (no sense transferring 2 unzipped when I could extract them on my attack machine as well). \---

Secure Copy is the safest way to not corrupt the data in transit

*** I extracted the files on my attack machine with `unzip`, and then I ran the `keepass-dump-masterkey` tool against the `KeePassDumpFull.dmp` file. ***

*** I retrieved a list of options as to what the password could be (minus a few characters, based on how the CVE works), but a quick Google search shows that this password is the `Danish` name of `red porridge with cream`. The next steps involved using this password to crack the `passcodes.kdbx` database file. I opened the database with a tool called `KeePassXC` to interact with the database. ***

*** After installing the tool, I `opened an existing database` and utilized the master password discovered prior. ***

*** I began digging through the loot trying to find any interesting credentials or information, and Within the `Network` tab, I found the key to rooting this machine. A `PuTTY-User-Key-File-3:ssh-rsa` file can be used in tandem with `SSH` in order to login to the server `without` a password. Ironically this is a much safer way to login instead of a password anyways, but when a `private key` falls into the wrong hands, it can be devastating. ***

*** If the KeePass record for the PuTTY key is opened, there is a record of a `root password`, but I tried logging in over SSH and the password alone failed. It was clear the key was `absolutely necessary`. I copied it to a file, gave it the proper [`PuTTY Key file extension of key.ppk`](https://www.baeldung.com/linux/ssh-key-types-convert-ppk), and used the `puttygen` tool to split the key into `2 parts`. A `ppk` file is actually the combination of a `public and private key`, but to login through SSH, the `private key` needs to be isolated in its own file. Lastly, I changed the permissions of the `private key` to `600` with the `chmod` command. If any `SSH private key` does not have the set permissions of `600`, it will not function at login because the key is deemed `insecure`. ***

The public and private keys can be extracted

*** Now that the key was prepared, all that was left to compromise the machine fully was to `login over SSH` with the `-i id_rsa` flag. ***

*** ## After Action Report 1. Default Passwords - It is best security practice to change default credentials of all applications and devices. Even if this ticket service existed on the internal subnet, it still needs to be changed to a strong password that adheres to company password policies, especially if it is the root account. This also applies to user accounts, and notes or memos within user profiles need to be audited for any remaining credentials. Passwords should never be stored in cleartext; always use encryption. 2. Outdated Software - Ensure all applications, internal or external, are patched with the latest security updates to avoid a critical CVE such as the one exploited above. Implement a consistent patch management control within the organization to track releases of security updates and apply them after demo in a test environment accordingly. 3. Information Disclosure - The hint about the location of the KeePass dump file proved to make privilege escalation a breeze. If there is a file with that level of criticality, comments should be redacted or removed that reveal more information than necessary. Implement an acceptable use policy surrounding chat interfaces and messaging systems in the organization to avoid the disclosure of potentially sensitive information. It was definitely smart of the lnorgaard user to remove the attachment from the platform, she can take it a step further by not disclosing its location in the filesystem.