Test d'intrusion sur un serveur Linux

What's going on guys, c'est Zack et bienvenue dans cette nouvelle leçon dans laquelle on va réaliser un cas pratique de test d'intrusion sur un serveur Linux.

Comme nous l'avons expliqué dans la leçon précédente, cela va vous aider à acquérir de l'expérience en conditions réelles.

Dans le domaine du pentest, les technologies à auditer sont très variées : tests d'intrusion mobiles, applications web, analyse de malwares, reverse engineering, pentest d'infrastructures et de systèmes d'exploitation, etc.

Aujourd'hui, nous allons étudier un système d'exploitation Linux, en intégrant également l'analyse de son application web.

Pour ce qui est de Linux, les seuls prérequis sont de savoir utiliser les commandes de base de Linux et de maîtriser les concepts fondamentaux de la sécurité informatique.

Si vous débutez sur Linux, je vous renvoie à mon cours complet sur Kali Linux disponible sur Udemy.

Nous verrons le cas d'un système Windows dans la prochaine leçon.

Pour ce challenge sur TryHackMe, nous allons utiliser la salle appelée « Basic Penetration Testing ».

Cette salle comporte également une démonstration de John Hammond qui explique sa résolution, mais nous allons le faire ensemble.

Je clique sur le bouton vert « Start Machine » et je m'assure d'abord d'être bien connecté au réseau VPN en pingant l'adresse `10.10.10.10`.

Le ping répond, la connexion est donc active.

Sur TryHackMe, j'ai plusieurs onglets de challenges ouverts, car je m'entraîne quotidiennement sur la plateforme pour perfectionner mes compétences de pentesteur.

Dans ce laboratoire, nous allons aborder plusieurs techniques : le brute forcing de mots de passe, le cassage de hashs, l'énumération de ports et de services, ainsi que l'énumération d'un système Linux.

L'objectif est d'apprendre un maximum de concepts.

Ce challenge a été créé par Josiah Pearce et était initialement disponible sur VulnHub.

La première tâche consiste à déployer la machine et à se connecter au VPN, ce qui est déjà fait.

L'étape suivante consiste à identifier les services exposés par la machine.

L'adresse IP de la cible s'affiche sur la page du challenge (dans mon cas, j'ai un compte premium donc la machine est réservée pour deux heures, contre une heure pour le forfait gratuit).

Si vous n'avez pas de machine d'attaque locale, vous pouvez lancer l'Attack Box de TryHackMe.

Pour énumérer les services actifs sur la cible, nous allons utiliser Nmap.

Nous lançons un scan agressif complet avec la commande `sudo nmap -A -Pn <IP_cible>`.

Dans un pentest réel, on évite généralement d'utiliser le paramètre agressif `-A` car il génère un trafic réseau très important et se fait immédiatement repérer par les systèmes de détection d'intrusion (IDS/IPS).

Nous ajoutons `-Pn` pour ignorer le ping de découverte (ICMP) au cas où le pare-feu de la cible le bloquerait.

Pendant que le scan s'exécute, nous vérifions notre connectivité.

Pensez également à maintenir vos outils à jour sur Kali Linux en lançant régulièrement un `sudo apt update && sudo apt upgrade`.

La question suivante du challenge nous demande le nom d'un répertoire caché sur le serveur web.

Il y a donc un serveur HTTP actif.

En ouvrant l'adresse IP dans notre navigateur, on tombe sur une page web en cours de maintenance.

En affichant le code source de la page (« View page source »), on repère un commentaire intéressant : « Check our dev_note section if you need to know what to work on ».

Cela nous indique l'existence d'une note de développement.

Le scan Nmap se termine.

Il nous révèle plusieurs ports ouverts : le port 22 (SSH running OpenSSH 7.2p2 sur Ubuntu), le port 80 (Apache httpd 2.4.18), les ports 139 et 445 (Samba/NetBIOS sur Linux/Ubuntu), le port 8009 (AJP13) et le port 8080 (HTTP Apache Tomcat 9.0.7).

L'OS detection confirme que la cible est une machine Linux 64-bit.

L'analyse du protocole SMB montre que la signature des messages est activée mais non requise, ce qui constitue une faiblesse de configuration classique.

Pour le port 8080, si nous l'ouvrons dans notre navigateur (`http://<IP_cible>:8080`), nous tombons bien sur l'interface par défaut d'Apache Tomcat version 9.0.7.

Pour répondre à la question concernant le répertoire caché sur le serveur web (sur le port 80), nous allons effectuer un brute forcing de répertoires (directory brute forcing) avec un outil de fuzzing.

Au lieu de DirBuster, Gobuster ou dirb, j'utilise Feroxbuster, qui est beaucoup plus rapide et performant.

Je lance la commande : `feroxbuster -u http://<IP_cible> -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -k`.

L'option `-k` permet d'ignorer les erreurs de certificats SSL/TLS.

Feroxbuster commence le fuzzing et découvre rapidement un répertoire nommé `/development/`.

En naviguant sur `http://<IP_cible>/development/`, nous accédons au dossier.

Il contient deux fichiers : `dev.txt` et `j.txt`.

Dans `dev.txt`, on peut lire une note d'un développeur qui indique qu'il a testé la technologie Struts (version 2.5.12) et qu'il a configuré le serveur Apache et le partage SMB, précisant qu'il ajoutera du contenu plus tard.

Dans `j.txt`, un utilisateur écrit qu'il a audité le fichier `/etc/shadow` (qui contient les hashs des mots de passe sous Linux) pour s'assurer de la solidité des mots de passe des utilisateurs, et qu'il a réussi à casser très facilement l'un des hashs.

Il demande à son collègue de modifier son mot de passe au plus vite pour respecter la politique de sécurité de l'entreprise.

À cette étape, nous n'avons pas encore de noms d'utilisateurs précis.

Le challenge nous demande ensuite de faire du brute forcing pour trouver un couple d'identifiants.

Pour cela, nous devons continuer notre énumération.

Une bonne pratique consiste à rechercher des vulnérabilités connues (les « low-hanging fruits ») associées aux versions des services que nous avons identifiées.

Nous pouvons utiliser l'outil `searchsploit` qui interroge localement la base de données d'exploits de Exploit-DB.

Si nous tapons `searchsploit openssh 7.2p2`, nous voyons plusieurs vulnérabilités, notamment une faille d'énumération d'utilisateurs (username enumeration) et des dénis de service (DoS).

Rappelons qu'en pentest professionnel, l'exploitation de failles de déni de service est proscrite car elle perturbe l'activité du client, mais il convient de la mentionner dans le rapport.

Nous faisons de même pour Apache 2.4.18.

Nous allons maintenant auditer le protocole SMB.

C'est un protocole historique très intéressant en sécurité car il comporte régulièrement des faiblesses.

Nous utilisons l'outil `enum4linux` avec la commande `enum4linux -a <IP_cible>`.

Cet outil va énumérer les partages Samba, les groupes de travail, les politiques de sécurité et les comptes utilisateurs.

L'analyse révèle l'existence de partages ouverts, notamment un partage nommé `Anonymous` accessible sans authentification, ainsi que le partage par défaut `IPC$`.

Nous découvrons également la politique de mots de passe (longueur minimale de 5 caractères).

Surtout, `enum4linux` parvient à énumérer les utilisateurs locaux via les requêtes SID et identifie deux comptes : « Kay » et « Jan ».

Nous avons maintenant nos deux utilisateurs cibles.

La question « What is the username? » correspond à l'un de ces deux comptes.

Après avoir testé Kay, c'est bien l'utilisateur « Jan » qui est validé.

Nous devons maintenant trouver son mot de passe par force brute.

Pour attaquer le service SSH sur le port 22, nous allons utiliser l'outil `hydra` (on pourrait également utiliser Patator, ou Burp Suite s'il s'agissait d'une interface web).

La commande est la suivante : `hydra -l jan -P /usr/share/wordlists/rockyou.txt <IP_cible> ssh`.

Si vous avez besoin d'aide pour configurer d'autres protocoles avec Hydra (comme FTP, RDP ou POP3), vous pouvez consulter la « Hydra Cheat Sheet » disponible sur GitHub qui liste les commandes types.

Après quelques minutes de brute-force avec le dictionnaire `rockyou.txt`, Hydra trouve le mot de passe de Jan : « armando ».

Nous pouvons maintenant valider cette étape sur TryHackMe.

La question suivante nous demande quel service nous avons utilisé pour nous connecter, la réponse est « SSH ».

Nous nous connectons en SSH sur la machine cible avec la commande `ssh jan@<IP_cible>` et le mot de passe « armando ».

Nous validons la clé de l'hôte et nous voilà connectés avec un shell sur la machine dont le nom d'hôte est « basic2 ».

La commande `whoami` confirme que nous sommes connectés sous l'identité de Jan.

Nous devons maintenant énumérer le système pour trouver un vecteur d'escalade de privilèges.

La première étape consiste à lister les autres utilisateurs de la machine en consultant le fichier `/etc/passwd` via la commande `cat /etc/passwd`.

Nous y retrouvons les utilisateurs système classiques, ainsi que le compte « Kay », ce qui confirme nos découvertes SMB.

En explorant le système, nous nous rendons dans le dossier `/home`.

Nous y trouvons le répertoire de Jan et celui de Kay.

Dans le dossier de Kay (`/home/kay`), il y a un fichier nommé `pass.bak` (une extension classique pour les sauvegardes de mots de passe).

Cependant, en vérifiant ses permissions avec `ls -la pass.bak`, nous constatons que ce fichier appartient exclusivement à Kay et que nous n'avons pas les droits de lecture en tant que Jan (« Permission denied »).

C'est la même chose pour son fichier d'historique `.bash_history`.

En revanche, en analysant son dossier SSH caché (`/home/kay/.ssh`), nous constatons que nous avons les droits de lecture sur les fichiers qu'il contient.

Si nous faisons un `ls -la`, nous découvrons la clé privée SSH de Kay (`id_rsa`), ainsi que le fichier `authorized_keys`.

C'est une erreur de configuration critique : la clé privée d'un utilisateur est accessible en lecture par un autre utilisateur.

Nous allons récupérer cette clé privée `id_rsa` pour nous connecter en SSH sous l'identité de Kay.

Pour copier ce fichier vers notre machine d'attaque Kali Linux locale, nous pouvons utiliser l'utilitaire `scp` (Secure Copy).

Dans le terminal de la machine victime, nous lançons : `scp id_rsa userX@<IP_Kali>:/home/userX/`.

Nous acceptons la connexion et renseignons le mot de passe de notre machine Kali.

Le fichier `id_rsa` est bien transféré.

Sur notre Kali locale, nous modifions les permissions de la clé pour qu'elle soit sécurisée : `chmod 600 id_rsa`.

Nous tentons ensuite de nous connecter sous l'identité de Kay avec la commande `ssh -i id_rsa kay@<IP_cible>`.

Cependant, la clé privée est protégée par une clé de chiffrement (passphrase).

Nous devons donc casser cette passphrase.

Pour ce faire, nous allons d'abord convertir la clé SSH dans un format compréhensible par John the Ripper en utilisant le script utilitaire `ssh2john` (ou `ssh2john.py`) : `/usr/share/john/ssh2john.py id_rsa > rsa.hash`.

Nous obtenons le fichier de hash `rsa.hash`.

Nous lançons ensuite John the Ripper avec le dictionnaire `rockyou.txt` pour casser ce hash : `john --wordlist=/usr/share/wordlists/rockyou.txt rsa.hash`.

En quelques secondes, John the Ripper découvre la passphrase de la clé privée : « beeswax ».

Nous relançons notre connexion SSH : `ssh -i id_rsa kay@<IP_cible>` et saisissons la passphrase « beeswax ».

La connexion réussit et nous sommes connectés en tant que Kay.

La commande `whoami` nous confirme notre nouvelle identité.

À présent, nous pouvons lire le fichier de sauvegarde `/home/kay/pass.bak` qui nous était interdit auparavant.

Nous y découvrons le mot de passe de Kay.

Cela nous permet de répondre à la dernière question et de terminer ce challenge.

Dans un cas réel de test d'intrusion, nous pousserions l'attaque jusqu'à obtenir les privilèges root (l'administrateur suprême de Linux), par exemple en vérifiant les droits sudo (`sudo -l`), en recherchant des fichiers SUID, ou en testant si l'utilisateur réutilise ses mots de passe.

Ce challenge montre bien les étapes clés d'un audit de sécurité sous Linux.

J'espère que cette démonstration vous a plu.

N'hésitez pas à vous entraîner sur TryHackMe sur des thèmes comme le pivoting ou l'escalade de privilèges.

Si vous avez des questions, posez-les en commentaire.

On se retrouve dans le prochain cours !