Hack The Box – Résoudre la box Keeper : outils, méthodes et recommandations pour se protéger
Sommaire
I. Présentation
Dans cet article, je vous propose la résolution de la machine Hack The Box Keeper, de difficulté "Facile".
Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.
Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs. 🙂
Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.
Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".
| Technologies abordées | Linux, web, CMS, Keepass |
| Outils utilisés | nmap, curl, bash, Python, Keepass Password Dumper |
Retrouvez tous nos articles Hack The Box via ce lien :
II. Résolution de la box Keeper
A. Découverte et énumération
Pour l'instant, nous ne disposons que de l'adresse IP de notre cible. Commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.
Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery
$ nmap -F --max-retries 1 -T4 --open -sV 10.10.11.227 -oA nmap-FastVersion
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)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelVous noterez ici que j'utilise l'option -oA de l'outil nmap. Celle-ci permet d'enregistrer la sortie du scan dans trois formats de fichier : texte, XML et un format "condensé" fait pour être utilisé par grep facilement. Lors d'un audit, il est très important de garder toutes les traces générées par nos attaques ou scans. Notamment pour être sûr de ne rien manquer lors de la phase de reporting, surtout si elle s'effectue "à froid" (après l'audit, sans accès à la cible). Je vous conseille de systématiquement utiliser les options intégrées dans vos outils pour générer les traces.
Seuls deux services sont accessibles, un service web et un service d'administration SSH. Tentons dans un premier temps de voir ce qui est présent sur le service web à l'aide de la commande "curl" :
$ curl http://10.10.11.227
<html>
<body>
<a href="http://tickets.keeper.htb/rt/">To raise an IT support ticket, please visit tickets.keeper.htb/rt/</a>
</body>
</html>Le virtual host par défaut du service web nous indique qu'un nom de domaine "tickets.keeper.htb" existe, il faut donc mettre à jour notre fichier "/etc/hosts" pour pouvoir le résoudre et y accéder :
$ echo "10.10.11.227 tickets.keeper.htb" |sudo tee -a /etc/hostsB. Des identifiants connus de tous
En arrivant sur l'application web "http://tickets.keeper.htb/rt/", on remarque qu'il s'agit d'une solution de type CMS (Content Management System) et non d'un développement "fait main". Dans ces cas-là, il est important d'identifier rapidement quelques informations comme la version du CMS installée, l'existence de vulnérabilités connues sur cette version ou les suivantes, mais également les identifiants par défaut utilisé (s'ils existent). Ici, le CMS utilisé est Request Tracker 4.4.4" :
La récupération d'information est facilitée, notamment grâce au logo du CMS qui affiche "Request Tracker", mais également via la version précise de l'instance installée, et même des informations concernant le système d'exploitation qui héberge l'application web. Pour en apprendre plus sur la récupération de ce type d'information, je vous oriente vers mon article : Qu’est ce que le Banner Grabbing ?
Sur une application web et sur de nombreux équipements, une installation toute fraiche comporte un compte d'administration par défaut. Celui-ci est utilisé pour une première connexion afin de configurer la solution et créer d'autres comptes. Une mauvaise pratique courante consiste simplement à laisser ce compte par défaut actif, en oubliant de le désactiver ou de changer son mot de passe. Il suffit alors de lire la documentation !
Nous retrouvons ici les identifiants par défaut du compte d'administration des CMS Request Tracker via une recherche Google, dans une documentation non officielle (wiki de la distribution Gentoo) :
Souvent, il est possible de retrouver cette information sur des sites dédiés qui référencent les identifiants par défaut (cirt.net), dans des wordlists dédiées (SecLists), sur des forums (comme ici sur Stackoverflow) ou simplement dans des tutoriels que les administrateurs sont susceptibles d'avoir suivi sans réfléchir !
Technique d'attaque (MITRE ATT&CK) : T1078.001 - Valid Accounts: Default Accounts
Nous parvenons à accéder en tant qu'administrateur à l'application web via les identifiants par défaut : "root:password".
Les applications de ticketing sont généralement très intéressantes pour un attaquant. Elles contiennent un grand nombre d'informations et de détails techniques, et parfois des mots de passe que s'échangent utilisateurs et supports (création de compte, mots de passe qui ne fonctionnent pas, réinitialisation d'un mot de passe, etc.).
C. Informations sensibles exposées
Étant administrateur de la solution, nous accédons à tous les tickets de la plateforme, ainsi qu'aux informations des utilisateurs. La description de l'un d'entre eux est particulièrement intéressante :
Technique d'attaque (MITRE ATT&CK) : T1552 - Unsecured Credentials
On note également un ticket intéressant qui mentionne un crash keepass :
Nous avons à présent un premier mot de passe et un nom d'utilisateur, tentons de les utiliser sur tous les services accessibles demandant une authentification :
Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH
$ ssh [email protected]
Last login: Thu Aug 24 14:44:17 2023 from 10.10.14.86
lnorgaard@keeper:~$ cat user.txt
f85d[REDACTED]4f3a0Nous avons un premier accès sur la machine ! Il faut à présent tenter d'élever nos privilèges jusqu'à obtenir un accès en tant que root, ce qui nous permettra d'être maitre de la machine.
Il est intéressant de noter que, dans la réalité, l'obtention des droits root sur un serveur web Linux en DMZ n'est pas systématiquement l'objectif principal de l'attaquant. Avec des droits non privilégiés, l'attaquant peut déjà installer des accès distants (reverse shell), des portes dérobées pour revenir sur son accès, mais aussi utiliser ce système comme un rebond vers le reste du réseau. Ici l'attaquant n'a probablement émis aucune alerte de sécurité (EDR/IDS/SIEM) puisque seul un accès SSH a été réalisé. Il serait idiot de tenter des opérations malveillantes potentiellement verbeuses pour passer root si cela n'est pas nécessaire.
D. Accès à la mémoire d'un process Keepass
Bref, notre objectif ici est de compromettre totalement la machine. Commençons par quelques opérations basiques, notamment en regardant les fichiers auxquels notre utilisateur "lnorgaard" a accès. J'utilise pour commencer cela l'outil "find" avec l'option "-user" :
Technique d'attaque (MITRE ATT&CK) : T1083 - File and Directory Discovery
lnorgaard@keeper:~$ find / -user $(whoami) 2>/dev/null |grep -v "/proc\|/sys"
/var/mail/lnorgaard
/run/user/1000
/run/user/1000/gnupg
/run/user/1000/gnupg/S.gpg-agent
/run/user/1000/gnupg/S.gpg-agent.ssh
/run/user/1000/gnupg/S.gpg-agent.extra
/run/user/1000/gnupg/S.gpg-agent.browser
/run/user/1000/gnupg/S.dirmngr
/home/lnorgaard
/home/lnorgaard/.bash_logout
/home/lnorgaard/.bashrc
/home/lnorgaard/RT30000
/home/lnorgaard/RT30000.zip
/home/lnorgaard/RT30000/KeePassDumpFull.dmp
/home/lnorgaard/RT30000/passcodes.kdbx
/home/lnorgaard/.ssh
/home/lnorgaard/.ssh/known_hosts
/home/lnorgaard/.ssh/known_hosts.old
/home/lnorgaard/.cache
/home/lnorgaard/.cache/motd.legal-displayed
/home/lnorgaard/.config
/home/lnorgaard/.gnupg
/home/lnorgaard/.gnupg/pubring.kbx
/home/lnorgaard/.gnupg/trustdb.gpg
/home/lnorgaard/.profileCette commande m'indique tous les fichiers et dossiers dont l'utilisateur est le propriétaire. Attention à bien noter la différence avec les fichiers accessibles en lecture par mon utilisateur, les groupes auxquels il appartient ou les fichiers "word readables". Comme mentionné dans le ticket découvert plus tôt, nous trouvons un coffre-fort Keepass et un fichier .dmp. Je décide de les exfiltrer pour analyse sur mon poste d'attaquant :
Technique d'attaque (MITRE ATT&CK) : T1048 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol
# Système Linux compromis
lnorgaard@keeper:~$ python3 -m http.server 9001
# Mon poste Kali
$ wget http://10.10.11.227:9001/RT30000.zip
$ unzip RT30000.zip
Archive: RT30000.zip
inflating: KeePassDumpFull.dmp
extracting: passcodes.kdbx Ici, j'utilise le module http.server de Python3 pour créer un "mini serveur web" qui exposera sur le port 9001 du système compromis un index correspond au home de l'utilisateur "lnorgaard". Il s'agit d'une méthode simple et rapide pour échanger des fichiers avec un autre système. Attention cependant, les données transitent un HTTP, et donc en clair.
Nous pourrions tenter d'effectuer une attaque par brute force sur le coffre-fort Keepass à l'aide d'outils comme hashcat ou John The Ripper. Néanmoins, la présence d'un fichier ".dmp" est assez inhabituelle.
Un fichier .dmp est généralement un fichier de vidage mémoire (core dump) qui enregistre l'état de la mémoire d'un processus au moment de son arrêt anormal, comme un crash. Ces fichiers sont utiles pour l'analyse post-mortem des erreurs et des problèmes logiciels (raison du crash). Ils peuvent notamment contenir des informations sensibles lorsque les programmes concernés en stockent en mémoire.
Technique d'attaque (MITRE ATT&CK) : T1212 - Exploitation for Credential Access
Après quelques recherches sur la façon dont je pourrais extraire des informations d'un dump mémoire du processus Keepass, je découvre la CVE-2023-32784 affectant les versions de Keepass 2.x antérieures à la version 2.54 :
D'après la description de cette CVE, il serait possible d'extraire le mot de passe du coffre-fort Keepass à partir d'un crash dump, nous ignorons si la version de Keepass utilisée est vulnérable, mais nous avons à disposition un crash dump, cela vaut donc le coup de tenter.
Il faut comprendre que, pour un logiciel "standard", le fait de retrouver des informations en clair d'un crash dump est plutôt normal. On s'attend cependant à ce qu'un outil de sécurité dissimule ces informations afin que l'obtention d'un crash dump ne donne pas lieu à la fuite d'un secret, c'est pourquoi il s'agit ici d'une vulnérabilité donnant lieu à une CVE. J'utilise pour "exploiter" ce dump mémoire et cette CVE l'outil Keepass Password Dumper :
Combined: ●{ø, Ï, ,, l, `, -, ', ], §, A, I, :, =, _, c, M}dgrød med fløde
â—ødgrød med fløde
â—Ãdgrød med fløde
â—,dgrød med fløde
â—ldgrød med fløde
â—`dgrød med fløde
â—-dgrød med fløde
â—'dgrød med fløde
â—]dgrød med fløde
â—§dgrød med fløde
â—Adgrød med fløde
â—Idgrød med fløde
â—:dgrød med fløde
â—=dgrød med fløde
â—_dgrød med fløde
â—cdgrød med fløde
â—Mdgrød med flødeCela ne me donne rien de compréhensible, même si le terme "dgrød med fløde" est constitué de caractères qui pourraient être ceux d'une langue étrangère. En effectuant une requête Google sur ces termes, je trouve le nom d'un plat danois : rødgrød med fløde :
Ce nom constituerait en soi une passphrase plutôt robuste avec de nombreux caractères et des caractères spéciaux/inhabituels (espace et "ø"). Il s'agit effectivement de la passphrase protégeant le coffre-fort KeePass récupéré ! Ce coffre-fort contient notamment une clé privée d'authentification :
Un dernier détail, il s'agit d'une clé SSH formatée pour l'outil Putty, qui n'est pas tout à fait le même que le format utilisé par OpenSSH. Une petite conversion est nécessaire :
$ sudo apt-get install putty-tools
$ puttygen /tmp/puttyKey.ppk -O private-openssh -o /tmp/openssh.keyNous pouvons à présent nous connecter en tant que root sur le système via SSH :
Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH
$ chmod 600 /tmp/openssh.key
$ ssh [email protected] -i /tmp/openssh.key
root@keeper:~# cat root.txt
d5d[REDACTED]fc8b81Et voilà, nous avons obtenu les droits "root" sur le système cible.
III. Résumé de l'attaque
Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :
| TTP (MITRE ATT&CK) | Détails |
| T1046 - Network Service Discovery | Réalisation d'un scan réseau via nmap, identification du CMS Request Tracker. |
| T1078.001 - Valid Accounts: Default Accounts | Authentification à l'aide des identifiants par défaut du CMS. |
| T1552 - Unsecured Credentials | Découverte d'un mot de passe utilisateur dans la description d'un utilisateur du CMS. |
| T1021.004 - Remote Services: SSH | Accès en SSH avec le compte lnorgaard |
| T1083 - File and Directory Discovery | Découverte d'une archive ZIP contenant une base KeePass et un dump mémoire |
| T1048 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol | Exfiltration via HTTP de l'archive ZIP vers le poste de l'attaquant |
| T1212 - Exploitation for Credential Access | Exploitation de la CVE-2023-32784 exposant le mot de passe du coffre-fort en clair lors d'un dump mémoire. |
| T1021.004 - Remote Services: SSH | Accès en SSH avec le compte root |
IV. Notions abordées
A. Côté attaquant
Ici, il s'agissait de revenir aux fondamentaux : le mot de passe du compte par défaut. Il s'agit d'une faiblesse très présente dans la réalité, la découverte de cette vulnérabilité permet de rappeler qu'il ne faut jamais négliger les tests les plus simples.
À l'inverse, il est aussi important de savoir identifier les éléments inhabituels au sein d'un système. C'est bien plus le cas dans les CTF que dans la vie réelle. Ici, nous aurions pu passer plusieurs heures à tenter de deviner le mot de passe de la base KeePass découverte, en vain. L'option du brute force étant la plus logique, il fallait également s'intéresser au dump mémoire (plutôt rare d'en trouver dans la vie réelle ou sur les exercices Hack The Box). Le lien avec la version de KeePass n'était pas forcément évident à faire sans avoir la version utilisée par l'utilisateur, mais les bons termes de recherche permettaient de nous orienter vers la bonne CVE.
Un avantage que nous avons aussi souvent sur Hack The Box est qui n'existe pas dans la vie réelle est que les CVE à exploiter (quand il y en a) sont souvent récentes, ce qui permet de faire un tri plus rapide. Dans des conditions réelles, il est fréquent de découvrir des applications qui n'ont pas été mises à jour depuis plusieurs années. Les CVE potentiellement applicables se présentent donc en grand nombre.
B. Côté défenseur
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : la principale recommandation ici concerne le premier élément de notre scénario d'attaque. Il est recommandé de modifier systématiquement les mots de passe par défaut des équipements et applications installés sur le système d'information, ou de désactiver ce compte par défaut pour le remplacer par un autre lorsque c'est possible (l'attaquant devra alors devenir le login en plus du mot de passe). Cela est notamment mentionné dans la directive n°12 du guide d'hygiène de l'ANSSI : Changer les éléments d’authentification par défaut sur les équipements et services.
Il est impératif de partir du principe que les configurations par défaut des systèmes d’information sont systématiquement connues des attaquants, quand bien même celles-ci ne le sont pas du grand public. Ces configurations se révèlent (trop) souvent triviales (mot de passe identique à l’identifiant, mal dimensionné ou commun à l’ensemble des équipements et services par exemple) et sont, la plupart du temps, faciles à obtenir pour des attaquants capables de se faire passer pour un utilisateur légitime.
Guide d'hygiène informatique - ANSSI
Recommandation n°2 : il est recommandé de protéger les clés SSH par une passphrase, ce qui empêchera ou ralentira leur réutilisation en cas de vol par un attaquant. Ce cas de figure est d'ailleurs mentionné par l'ANSSI comme un exemple d'authentification double facteur dans son guide Recommandations relatives à l'authentification multifacteur et aux mots de passe. La passphrase permet de chiffrer la clé privée.
Recommandation n°3 : il est également recommandé de mettre à jour les logiciels utilisés sur le système Linux concerné. Au-delà de la présence inhabituelle du dump mémoire Keepass (qui était situé dans le "home" de l'utilisateur propriétaire), c'est une CVE affectant une version non à jour qui a mené à la découverte du mot de passe du coffre-fort. De manière plus formelle, nous pouvons mentionner la directive n°34 du Guide d'hygiène de l'ANSSI : définir une politique de mise à jour des composants du système d’information.
J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !
Enfin, si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points 🙂 ) : Tester Hack the Box Academy
