titanic.htb
Un scan initial montre que seuls les ports 22 et 80 sont ouverts.
En accédant au site via HTTP, une redirection vers titanic.htb
empĂȘche l'accĂšs direct. Il est nĂ©cessaire d'ajouter ce domaine dans le fichier /etc/hosts
.
Une fois sur le site, un formulaire d'inscription est disponible. Lors de la soumission, un JSON est retourné.
En interceptant la requĂȘte avec BurpSuite, on remarque que la rĂ©ponse JSON repose sur un paramĂštre manipulable, ce qui permet une tentative de LFI.
En testant des chemins relatifs, on observe une fuite dâinformation avec le fichier /etc/passwd
, révélant un utilisateur nommé developers.
La lecture du fichier /etc/hosts
via la faille LFI révÚle un hÎte supplémentaire : dev.titanic.htb
.
Une fois le sous-domaine ajouté dans /etc/hosts
, une nouvelle plateforme devient accessible.
En parcourant les fichiers accessibles, on tombe sur un Dockerfile. Celui-ci contient les images utilisées et un mot de passe root hardcodé.
Cette découverte permet de déduire l'emplacement de la base de données de l'application.
Une fois le chemin correct identifié, la base est téléchargée.
Elle est reconnue comme étant au format SQLite3.
En l'ouvrant, on explore les tables présentes et on extrait les hash contenus dans la table user
.
Le hash extrait est converti Ă lâaide dâun script gitea2hashcat.py
pour ĂȘtre compatible avec Hashcat.
Une fois le hash crackĂ©, on obtient le mot de passe de lâutilisateur developers.
Avec les identifiants valides, on se connecte via SSH et on récupÚre les flags utilisateurs et root.
â Machine pwned avec succĂšs.