Keeper
Linux, Easy (09/04/2023)
Last updated
Linux, Easy (09/04/2023)
Last updated
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
I discovered a handy tactic that involved . 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 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).
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 , 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.
nmapp -sV -sC -oN nmap.scan 10.129.70.209domain name
