Keeper

Introduction

In this walkthrough, we target a support ticketing system running on the machine, which uses default credentials. After logging in, we discover cleartext credentials within the interface that grant us SSH access. Once on the machine, we find a KeePass database dump, which we used to extract possible master secrets and then brute-force them secret using hashcat. The KeePass database contains the root user’s SSH private key in Putty format, which we will convert to OPENSSH format using putty-tools, extracted private-key allows us to authenticate as root and gain full access to the system.

Nmap

TCP

Run a quick Nmap TCP scan:

sudo nmap -sV $IP --open

UDP

Check top 100 UDP ports:

sudo nmap -sU -F $IP

Full Port Scan

sudo nmap -sV -sC -p- $IP -Pn -n -v --open

Services

Port 22 (SSH)

Version -OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)

We usually skip SSH.

Web

Port 80

Version - nginx 1.18.0 (Ubuntu)

Add the domain to /etc/hosts file:

We are redirected to login page, I used the following credentials to login:

root : password which are default credentials for application Request Tracker.

I found the following vulnerability but failed to exploit because every time i wanted to intercept the request it redirected me to Jenkins where I don’t know any credentials.

Request Tracker - ‘ShowPending’ SQL Injection

After some time spent on enumerating the website I found under users that we actually have 2 users,

lnorgaard and root.

And more interestingly I found that user password in their description;

I used these credentials to gain SSH access and was successful.

Privilege Escalation

• OSCP Checklist
  • Situational awareness
  • Exposed Confidential Information
  • Password Authentication Abuse
  • Hunting Sensitive Information
  • Sudo
  • SUID/SGID
  • Capabilities
  • Cron Jobs Abuse
  • Kernel Exploits
  • Check if sudoers file is writable
  • Try credentials you already obtained for various services admin roles

After checking my groups and sudo privileges. I decided to enumerate the file that is under our user directory called RT30000.zip. Unzipping the file I can see two files:

As we have kdbx file we can try to crack it using hashcat but first we need to convert it to hashcat compatible format using python2john.

keepass2john passcodes.kdbx > keepass.hash

hashcat -m 13400 keepass.hash /usr/share/wordlists/rockyou.txt

But it took a long time to crack that means we did something wrong. I analysed that this .dmp file could mean, and found many resources that this is related to vulnerability in KeePass.

While typing out the master key to unlock a KeePass database, the value of the input box is stored in memory. While it is visually hidden using ‘●’ characters, the last character was briefly visible in memory and keeps being stored there (CVE-2023-3278, fixed in KeePass 2.54 released June 3rd 2023). 

keepass-dump-extractor

I downloaded Linux version from releases and run the tool:

./keepass-dump-extractor ../KeePassDumpFull.dmp -f all > wordlist.txt

hashcat -m 13400 ../keepass.hash wordlist.txt

Now we cracked it.

Then download KeepassXC to open keepass file in Linux.

I found passwords for users root and our current user, but root user password didn’t work that’s why I decided to use their private key:

But this key format is .ppk file format which us Putty file format, we should convert it to SSH private key format using putty-tools.

sudo apt install putty-tools

After that use:

puttygen key.ppk -O private-openssh -o key_id_rsa

Now we are root!

Credentials

#SSH
lnorgaard : Welcome2023!

#Keepass
rødgrød med fløde

Mitigation

• Change all default credentials immediately after deploying any service.
• Avoid storing plaintext credentials in web interfaces or configuration files.
• Encrypt sensitive files (such as KeePass databases) with strong, unique passwords.
• Secure SSH access using key-based authentication, and avoid placing private keys on the system.
• Implement least privilege access controls and monitor for abnormal access patterns.