#defaultpassword #passwordreuse #memorydump ## User Flag ### [[NMAP]] Scan ```shell sudo nmap 10.10.11.227 -sC -sV [sudo] password for cwalker: Starting Nmap 7.94 ( https://nmap.org ) at 2023-08-13 09:43 MDT Nmap scan report for tickets.keeper.htb (10.10.11.227) Host is up (0.057s latency). Not shown: 998 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-trane-info: Problem with XML parsing of /evox/about |_http-title: Login |_http-server-header: nginx/1.18.0 (Ubuntu) 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 11.07 seconds ``` ### Initial Enumeration I performed an [[NMAP]] scan that revealed ports 22 and 80 open. Visiting http://10.10.11.227 gives me a webpage with a link to a ticketing system. ![[Pasted image 20230813094734.png]] Clicking the link brings me to a ticketing system login page that looks to be using the Best Practical Request Tickets software. `Note: for the box tickets.keeper.htb needs to be added to hosts file` ![[Pasted image 20230813094923.png]] ### Research For research clicking the Best Practical logo in the top right corner brings us to the softwares homepage. In the bottom left corner of the webpage I saw that the version was 4.4.4. Googling the version and if there are any vulnerable versions, yields some interesting results. There are no premade exploits but a few CVE's that affect the version running on the webserver. Specifically [CVE-2022-25802](https://www.cvedetails.com/cve/CVE-2022-25802/), and XSS vulnerability that the software is vulnerable to and [CVE-2021-38562](https://www.cvedetails.com/cve/CVE-2021-38562/), which is a timing attack that can expose usernames and passwords. The cross site scripting vulnerability didn't seem to be applicable to getting into the box. However the timing attack did seem to be something that we could use to get the information we needed. Looking at the references for the CVE shows the github page where the exploit existed before it was patched. This shows what leads to the timing attack on the page. ![[Pasted image 20230813095751.png]] #### Exploiting CVE's I opened burpsuite and captured the login packet. I then sent the packet to burpsuites Intruder to try and brute force the login and see if I could compare the timings to see a valid login. Ultimately, I figured this was not the route to go as the attack seemed to complicated for the type of box I was doing. #### Thinking Simple I reset and tried to think simpler, those were the only CVE's I found that could be used to exploit the software. I tried some logins that I thought would be to easy but `admin:admin`, `root:root`, `root:toor` but nothing was working. I then just googled the default login credentials for Best Practical RT and the first result gave me credentials `root:password`. ![[Pasted image 20230813100606.png]] ### Exploiting Simple Trying these credentials I was able to get in to the ticketing software. ![[Pasted image 20230813100728.png]] Clicking around and looking at different tabs and tables I found a list of users under the Admin tab. In there there is the current user, root, and another user with a Danish name, lnorgaard. ![[Pasted image 20230813101025.png]] Clicking on the user we can see that he was given an initial password to login with. Its very likely this is still the same, either because the user did not change it or was not forced to at the time of first login. ![[Pasted image 20230813101157.png]] Trying these credentials to ssh into the machine was successful. ```shell ssh [email protected] [email protected]'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 settings You have mail. Last login: Sun Aug 13 01:02:28 2023 from 10.10.16.8 lnorgaard@keeper:~$ ``` In the home directory is the user flag. ## Root Flag ### Enumeration Once inside the machine I did the first enumeration steps of running linpeas and pspy64. Downloading and running Linpeas did not return anything super obvious and neither did pspy64. However, in the users home directory is a zip file called `RT30000.zip`. Unziping in place exposes two files that are very interesting. ```shell lnorgaard@keeper:~$ ls KeePassDumpFull.dmp passcodes.kdbx RT30000.zip user.txt ``` One being a dump file from the popular Password manager KeePass and then the KeePass file itself. ### Initial Escalation My initial thought was to convert the KeePass file into a hash with keepass2john. First I copied the zip file over to my machine using scp. ```shell scp [email protected]:/home/lnorgaard/RT30000.zip . ``` Unziping the file I then converted the password file to a hash with [[john]]. ```shell keepass2john passcodes.kdbx > kee.hash ``` I use Windows Subsystem for Linux(WSL) on my PC with a 3080ti. Unfortunately, WSL doesn't recognize my GPU so I used hashcat on my windows host machine. I rant the hash through the popular wordlist Rockyou.txt. However after about 6 minutes the entire wordlist was exhausted with no password found. ### More Research I then thought to see what the dump file in the zip file was all about. Usually files with the .dmp extension are dumped from memory or interesting locations. Googling `KeePass dump file` led me to a few pages [KeePass Discussion](https://sourceforge.net/p/keepass/discussion/329220/thread/f3438e6283/) and the most valuable [vdohney / keepass-password-dumper ](https://github.com/vdohney/keepass-password-dumper) talking about a vulnerability that exposes master passwords stored in memory, by saving each character at the end of a memory location in plaintext. ![[Pasted image 20230813104849.png]] ### Inspecting the Dump It seems the dumpfile in question is a dump from memory and should contain the master password. I cloned the repository to my windows machine ```PowerShell git clone https://github.com/vdohney/keepass-password-dumper ``` Running the command listed in the repo, gave me an error about not having DotNet SDK installed. After downloading the SDK I was able to successfully run the program. It outputted the results of the memory dump file. ```powershell dotnet run .\KeePassDumpFull.dmp ``` ```powershell ---SNIPPED--- 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 ``` At first glance this looks like random characters. However, remembering the users name and the message in the ticketing system shows that the password might be in another language. Looking at the git repo shows that Unknow characters are represented as stars while the master password should appear after the squiggly brackets. ![[Pasted image 20230813110000.png]] Its seems the master password as unknown characters in the vowels. This further lead me to believe that it was a word in the language of the user as there are accents above alot of the vowels. Googling the master password as displayed `dgr*d med fl*de` tells me the missing vowels and the language being swedish. ![[Pasted image 20230813110245.png]] ### Opening the Password Manager Of course, I have to make the password all lowercase `rødgrød med fløde`. I downloaded KeePass to my machine to interact with the password file. Loading the password file and entering in the dumped password allows me access to the passwords contained within. ![[Pasted image 20230813111113.png]] Inside the password manager it has roots password and a putty SSH key. The root password is `F4><3K0nd!`, however, SSH with the password gives me access denied. Trying to run the command `su` also doesnt allow me to use the found password. This led me to believe that the password is not valid anymore. So then I had to use the SSH key. I tried creating a SSH private key RSA file, however, anytime I tried to authenticate with it, I would get a `invalid format` error. ```shell ssh [email protected] -i id_rsa Load key "id_rsa": invalid format [email protected]'s password: ``` I instead generated a key with putty and then copy/pasted the found key into that key and connected to the host machine. This gave me root access and I was able to get the flag in the /root directory.