Keeper is an “easy” level box from HackTheBox - aside from being good fun it’s an excellent example of why password policies are so important!
Gaining user access
First of all, we’ll add keeper.htb to /etc/hosts, and fire off an nmap
$nmap keeper.htb -sC -sV -p -
Starting Nmap 7.93 ( https://nmap.org ) at 2023-11-08 10:00 GMT
Nmap scan report for keeper.htb (10.129.229.41)
Host is up (0.022s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 3539d439404b1f6186dd7c37bb4b989e (ECDSA)
|_ 256 1ae972be8bb105d5effedd80d8efc066 (ED25519)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.95 seconds
Looks like we have nginx on port 80 and ssh to play with - let’s take a look at the site…
Here there’s isn’t much, but we do find a link for a support ticket system, lets add tickets.keeper.htb to /etc/hosts and visit the link.
$ sudo nano /etc/hosts
10.10.11.227 keeper.htb tickets.keeper.htb
Looking at the new subdomain, we find a ticket system called “request tracker”, running version 4.4.4
From here there are two main things to try - firstly, we can try to guess (or find) a default password, and secondly we may be able to find an exploit.
Since we have a specific version number, I’ll start with a search for vulnerabilities. There are a few, the most noticeable is an XSS issue, however without users to interact with this will be difficult to chain into access. We’ll keep that in mind, but let’s now explore the default credentials route - a quick Google tells us they’re “root/password” this works!
There’s only one active ticket in the system, so we can assume that the details here are relevant!
So, it seems that there’s a valid user called lnorgaard, and that there’s a crash dump from keepass in their home directory. We can also speculate that rt@keeper.htb might be a valid login for something. I quickly try to ssh to the box as lnorgaard and as rt using “password” as the password (always worth a go) but this isn’t successful.
Let’s look around the application some more - since we’re root, can we view information about users? Perhaps a password? It looks like by default we shouldn’t be able to, but a password is added as a note to Lise’s account
Let’s try to ssh in with this:
$ssh lnorgaard@keeper.htb
lnorgaard@keeper.htb's password:
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-78-generic x86_64)
\* Documentation: https://help.ubuntu.com
\* Management: https://landscape.canonical.com
\* Support: https://ubuntu.com/advantage
You have mail.
Last login: Tue Aug 8 11:31:22 2023 from 10.10.14.23
lnorgaard@keeper:~$
And were in! I’ll grab user .txt from the home directory and keep exploring.
Privilege escalation to root
From the ticket we can be pretty sure the step to root will invoke keepass - however, let’s do some very basic enumeration just in case anything obvious jumps out - most importantly, let’s run sudo -l
lnorgaard@keeper:~$ whoami
lnorgaard
lnorgaard@keeper:~$ sudo -l
[sudo] password for lnorgaard:
Sorry, user lnorgaard may not run sudo on keeper.
I’d usually look to enumerate more than this, however, it’s looking pretty clear we need to explore that keepass dump, so let’s move right on to that.
A quick Google around for “keepass exploits” leads us to 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. The memory dump can be a KeePass process dump, swap file (pagefile.sys), hibernation file (hiberfil.sys), or RAM dump of the entire system. The first character cannot be recovered. In 2.54, there is different API usage and/or random string insertion for mitigation.
That sounds very much like the situation we have here! A little more digging reveals the POC code which accompanies this CVE, which can be found here: https://github.com/vdohney/keepass-password-dumper
We’ll clone the git reop, and take note that it’s important to ensure that dotnet is installed - I don’t have it installed on this machine so we’ll follow the isntructions here: https://learn.microsoft.com/en-us/dotnet/core/install/linux-debian to get it installed. I did need to install the full SDK if you’re wondering.
To use this exploit script well just need a memory dump from keepass (I’ll copy this from the box to my machine), and simply run the script:
Password candidates (character positions):
Unknown characters are displayed as "●"
1.: ●
2.: ø, Ï, ,, l, `, -, ', ], §, A, I, :, =, _, c, M,
3.: d,
4.: g,
5.: r,
6.: ø,
7.: d,
8.: ,
9.: m,
10.: e,
11.: d,
12.: ,
13.: f,
14.: l,
15.: ø,
16.: d,
17.: e,
Combined: ●{ø, Ï, ,, l, `, -, ', ], §, A, I, :, =, _, c, M}dgrød med fløde
I’m instantly curious about what this means…
This looks very much like the keepass master password, however this is an excellent example of why reading the documentation accompanying a tool is critical, since the README tells us that this is doesn’t include the first and second characters..
We could try to brute force these, but first how about we throw “dgrød med fløde” into Google - the suggestion is “rødgrød med fløde”. This is almost certainly the password. Do note too that while ChatGPT did give me a translation, it didn’t point out that I didn’t get it the whole term. Keep this kind of thing in mind when using generative AI, it’s an excellent way to get a quick answer, but always verify!
I’m confident I now have the master password, so let’s install Keepass and see if we can unlock the password file..
No, no joy… lowercase r?
OK, that works!
Let’s copy the key to our clipboard by clicking the entry - apparently, it’s “F4><3K0nd!” I try to SSH into the box as root, using this, however, I get access denied. A quick look back at the key (and expanding the column a bit) suggests we missed something important!
There’s a PuTTY key here!
PuTTY-User-Key-File-3: ssh-rsa
Encryption: none
Comment: rsa-key-20230519
Public-Lines: 6
AAAAB3NzaC1yc2EAAAADAQABAAABAQCnVqse/hMswGBRQsPsC/EwyxJvc8Wpul/D
8riCZV30ZbfEF09z0PNUn4DisesKB4x1KtqH0l8vPtRRiEzsBbn+mCpBLHBQ+81T
EHTc3ChyRYxk899PKSSqKDxUTZeFJ4FBAXqIxoJdpLHIMvh7ZyJNAy34lfcFC+LM
Cj/c6tQa2IaFfqcVJ+2bnR6UrUVRB4thmJca29JAq2p9BkdDGsiH8F8eanIBA1Tu
FVbUt2CenSUPDUAw7wIL56qC28w6q/qhm2LGOxXup6+LOjxGNNtA2zJ38P1FTfZQ
LxFVTWUKT8u8junnLk0kfnM4+bJ8g7MXLqbrtsgr5ywF6Ccxs0Et
Private-Lines: 14
AAABAQCB0dgBvETt8/UFNdG/X2hnXTPZKSzQxxkicDw6VR+1ye/t/dOS2yjbnr6j
oDni1wZdo7hTpJ5ZjdmzwxVCChNIc45cb3hXK3IYHe07psTuGgyYCSZWSGn8ZCih
kmyZTZOV9eq1D6P1uB6AXSKuwc03h97zOoyf6p+xgcYXwkp44/otK4ScF2hEputY
f7n24kvL0WlBQThsiLkKcz3/Cz7BdCkn+Lvf8iyA6VF0p14cFTM9Lsd7t/plLJzT
VkCew1DZuYnYOGQxHYW6WQ4V6rCwpsMSMLD450XJ4zfGLN8aw5KO1/TccbTgWivz
UXjcCAviPpmSXB19UG8JlTpgORyhAAAAgQD2kfhSA+/ASrc04ZIVagCge1Qq8iWs
OxG8eoCMW8DhhbvL6YKAfEvj3xeahXexlVwUOcDXO7Ti0QSV2sUw7E71cvl/ExGz
in6qyp3R4yAaV7PiMtLTgBkqs4AA3rcJZpJb01AZB8TBK91QIZGOswi3/uYrIZ1r
SsGN1FbK/meH9QAAAIEArbz8aWansqPtE+6Ye8Nq3G2R1PYhp5yXpxiE89L87NIV
09ygQ7Aec+C24TOykiwyPaOBlmMe+Nyaxss/gc7o9TnHNPFJ5iRyiXagT4E2WEEa
xHhv1PDdSrE8tB9V8ox1kxBrxAvYIZgceHRFrwPrF823PeNWLC2BNwEId0G76VkA
AACAVWJoksugJOovtA27Bamd7NRPvIa4dsMaQeXckVh19/TF8oZMDuJoiGyq6faD
AF9Z7Oehlo1Qt7oqGr8cVLbOT8aLqqbcax9nSKE67n7I5zrfoGynLzYkd3cETnGy
NNkjMjrocfmxfkvuJ7smEFMg7ZywW7CBWKGozgz67tKz9Is=
Private-MAC: b0a0fd2edf4f0e557200121aa673732c9e76750739db05adc3ab65ec34c55cb0
Well need to change this into OpenSSH format so we can SSH into the box, but when I try to use Puttygen to convert, I get an error:
puttygen: error loading `./root.ppk': PuTTY key format too new
A quick Google says to give it a go on Windows instead - and this works with no problem. We use puttygen to import the putty format key, and then export as an openssh.
from here we simply copy the key to a file on my attacker box, chmod the permissions to 600 and log in.
$ssh root@keeper.htb -i ./root.key
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-78-generic x86_64)
\* Documentation: https://help.ubuntu.com
\* Management: https://landscape.canonical.com
\* Support: https://ubuntu.com/advantage
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings
You have new mail.
Last login: Tue Aug 8 19:00:06 2023 from 10.10.14.41
root@keeper:~# whoami
root
And we’re root!
Avoiding the Hack - Lessons learned
So let’s now take a look at the vulnerabilities we found, and how they could have been avoided.
First up, we have the use of a default password in the ticketing system - it cannot be stressed enough how important changing default passwords is. Had this account been secured with a strong password this attack chain would have been impossible. Having a strong, but also understandable and enforceable password policy, for your company or just for yourself is the single most important step here.
Secondly, we have sensitive data being exposed in a comment within the ticket system. Passwords, access keys or any other credential information should never be stored in plain text. “I’ll delete it as soon as X has copied it” is also a bad strategy, as these things often get forgotten!
Let’s give this imaginary organisation a break and say they weren’t aware of the KeePass vulnerability - however, regularly checking for and installing software updates would quite possibly have prevented us from retrieving the master password. Despite this, the choice of master password - a common term - was a poor one. With the partial password, I was able to retrieve from the memory dump a brute force would still have been more than feasible, however the use of a common term (albeit one in Danish) made password guessing trivial.
Arguably, root SSH should also be disabled on the box, however, there are legitimate circumstances where an organisation might need to utilise this, so it isn’t always practical to remove it - if it’s not required however, it’s worth turning off.
See you in the next one!