Node HackTheBox (Writeup)

Reconnaissance

Création de l'espace de travail :

Nous établirons notre espace de travail en créant trois dossiers pour stocker les contenus importants, les exploits et les résultats de la reconnaissance à l'aide de Nmap.

Vérification de la Connectivité VPN

Vérification de la connexion VPN pour assurer une communication stable avec la machine cible.

Recherche des ports ouverts avec Nmap :

Exploration des ports ouverts et exportation dans le fichier "allPorts" dans le répertoire Nmap:

Analyse des ports ouverts avec extractPorts (22,3000)

Utilisation de la fonction extractPorts pour afficher de manière synthétique les ports ouverts et les copier dans le presse-papiers.

Scan de la version des ports avec Nmap:

Utilisation de Nmap pour scanner la version des ports et extraction des informations dans le fichier "targeted" :

Port 22 - SSH

Nous constatons que la version est vulnérable à l'énumération des utilisateurs car elle est inférieure à la version 7.7. Cela permet de tenter une énumération des utilisateurs.

Utilisation de searchsploit pour trouver un exploit

Nous utilisons cet exploit pour vérifier si un utilisateur est valide ou non :

Port 3000 - HTTP

Nous trouvons plusieurs utilisateurs potentiels : tom, mark, rastating.

Énumération SSH avec 45939.py pour tester les utilisateurs :

Nous constatons que tom et mark sont des utilisateurs valides.

Énumération des répertoires :

Nous utilisons gobuster pour effectuer une énumération de répertoires sur le port 3000 :

Aucune information intéressante n'est trouvée. Cependant, en explorant les requêtes réseau dans Firefox, nous trouvons un fichier latest qui appelle une API.

Exploration de l'API :

L'API contient une route /users qui retourne des informations sensibles, notamment des hachages de mots de passe pour plusieurs utilisateurs :

  • myP14ceAdm1nAcc0uNT : dffc504aa55359b9265cbebe1e4032fe600b64475ae3fd29c07d23223334d0af

  • tom : f0e2e750791171b0391b682ec35835bd6a5c3f7c8d1d0191451ec77b4d75f240

  • mark : de5a1adf4fedcce1533915edc60177547f1057b61b7119fd130e1f7428705f73

  • rastating : 5065db2df0d4ee53562c650c29bacf55b97e231e3fe88570abc9edd8b78ac2f0

Crackage des mots de passe :

Nous utilisons crackstation pour cracker les mots de passe des utilisateurs.

Les mots de passe décodés sont les suivants :

  • myP14ceAdm1nAcc0uNT : manchester

  • tom: spongebob

  • mark: snowflake

Nous réussissons à nous connecter avec l'utilisateur myP14ceAdm1nAcc0uNT dans le panneau d'administration.

Téléchargement du Backup :

L'utilisateur myP14ceAdm1nAcc0uNT nous permet de télécharger un fichier de sauvegarde.

Le fichier téléchargé contient une chaîne Base64.

Nous la décodons en un fichier ZIP :

Brute Force sur le fichier ZIP :

Extraction du hash avec zip2john :

Nous allons donc utiliser zip2john pour extraire le hash

Cracking du mot de passe avec john :

Résultat : Mot de passe trouvé - magicword

Nous réussissons à décompresser le fichier ZIP, qui contient un backup du site dans le répertoire /var.

Exploration de app.js :

Dans le fichier app.js, nous trouvons des informations sensibles, notamment un utilisateur (mark) et son mot de passe associé pour accéder à la base de données :

  • mark : 5AYRft73VtFpc84k

Connexion SSH avec mark :

Nous utilisons les informations récupérées pour nous connecter en SSH avec l'utilisateur mark :

Mot de passe : 5AYRft73VtFpc84k

Nous avons désormais accès à la machine cible.

Pivoting User Tom

Nous devons maintenant pivoter vers l'utilisateur tom.

Connexion à la base MongoDB

En observant les processus en cours, nous remarquons que tom exécute un fichier app.js avec Node.js.

Ce fichier se connecte à la base de données scheduler en utilisant les mêmes identifiants que ceux de l'utilisateur mark.

Pour accéder à la base de données, nous utilisons les identifiants de mark :

Reverse Shell MongoDB

Le script app.js exécute des commandes système provenant des documents MongoDB (via doc.cmd). Cela présente une vulnérabilité critique, car des commandes arbitraires peuvent être injectées et exécutées.

Pour confirmer que nous pouvons exécuter des commandes via MongoDB

Créer un serveur web local

Sur la machine attaquante, lancez un serveur web pour observer les requêtes :

Insérer une commande de test dans la collection tasks

Dans MongoDB, insérez une commande qui effectue une requête HTTP vers votre machine attaquante

Observer les requêtes

Si vous voyez une requête dans les logs du serveur web, cela confirme que les commandes sont exécutées.

on lance un revrselll

on se met en ecoute port 443

Lancer un Reverse Shell

Configurer un écouteur sur le port 443 Sur la machine attaquante :

Insérer une commande de reverse shell

Dans MongoDB, insérez une commande pour établir un reverse shell :

Connexion réussie Une fois la commande exécutée, vous obtenez un shell interactif sur la machine cible sous l'utilisateur tom.

Traitemeent de la terminal

Flag user.txt :)

Élévation de Privilège

SUID - Binaire (backup)

Pour rechercher les fichiers avec le bit SUID activé, on utilise la commande suivante :

Cela nous permet de trouver un binaire nommé backup.

Le propriétaire du binaire est root, ce qui signifie qu'il s'exécute avec les privilèges de l'utilisateur root.

Lorsque nous essayons d'exécuter ce binaire directement, rien ne se passe. Cependant, en testant différentes entrées, nous découvrons qu'il accepte une chaîne de trois caractères séparés par des espaces, ce qui révèle les fonctions disponibles :

En examinant le fichier app.js, nous trouvons des informations sur l'utilisation du binaire, ainsi qu'une clé nécessaire pour son exécution. La clé est située en haut du fichier.

Pour utiliser le binaire, nous devons fournir la clé, suivie du chemin du répertoire à sauvegarder.

45fac180e9eee72f4fd2d9386ea7033e52b7c740afc3d98a8d0230167104d474

Cela génère une sortie en Base64.

La sortie en Base64 peut être décodée en un fichier .zip à l'aide de la commande suivante :

Le fichier zip est protégé par un mot de passe. Nous utilisons le mot de passe trouvé précédemment

  • password: magicword

Cependant, le fichier root.txt contenu dans l'archive est un leurre (rabbit hole).

Analyse approfondie avec ltrace

En utilisant ltrace, nous observons que le binaire compare le chemin /root avec celui fourni en argument. Si les chemins correspondent, il affiche une caricature de troll.

Pour contourner cette vérification, nous exécutons le binaire depuis la racine (/) en demandant un backup de root

La nouvelle sortie est également en Base64. Nous la décodons pour obtenir le contenu final :

Flag root.txt :)

En extrayant le fichier final, nous accédons au contenu désiré.

Mis à jour

Ce contenu vous a-t-il été utile ?