Fiche TP - Kali 03 - Boot2root
I. Introduction
Disclaimer : Merci de lire les notes suivantes avant d'aller plus loin dans ces TP.
- Il est essentiel d'avoir pris connaissance et signé le contrat remis par le moniteur chargé des cours en cybersécurité.
- Ces TP ont pour vocations à être utilisés dans les environnement de tests prévus à cet effet.
- Pour rappel, toute utilisation des compétences évoqués plus bas à des fins malveillantes sont sévèrement punies par la loi.
1.1 Contexte
|
|
L'entreprise à mis en place un nouveau système de monitoring sur une machine critique.
Celui-ci a été vibe codé par l'un des administrateur en s'aidant de l'IA locale. Mais cette IA reste simpliste et cela introduira invariablement des vulnérabilités dans le système.
Dans ce cadre, l'entreprise a initialement demandé à son équipe SOC de réaliser un audit de l'application web.
Mais comme vous le verrez, cela pourra aller bien plus loin que prévu. |
1.2 Objectifs
L'objectif de la team RED va être ici de dérouler le processus de l'attaque sur un serveur linux contenant un accès SSH protégé et un site en http.
Le but final est de prouver jusqu'où elle a pu aller en fournissant un rapport montrant les 3 étapes franchies.
- Celle sur le site de l'application prouvant l'accès initial.
- Celle sur le shell de l'utilisateur web prouvant la compromission de la machine.
- Celle de l'injection de la clé ssh prouvant la persistance.
- Celle montrant le contenu de /root, prouvant la réussite d'une escalade de privilège.
- Celle de la page du service web inaccessible, prouvant la réussite de l'arrêt du service.
L'objectif de la team BLUE est de répondre à l'incident en procédant pas à pas à une analyse forensique de l'attaque.
Le but final est de fournir un rapport sur les traces laissées par les attaquants.
II. Préparation du TP
| RED | BLUE |
|
|
III. Phase 1 : Reconnaissance
Info : l'équipe BLUE va fournir l'ip de ses machines à leurs collègue RED. On part en effet du principe que c'est un audit interne réalisé par l'équipe SOC.
Pour la RED team
Objectif : Identifier les surfaces d'attaques
La phase de reconnaissance s'effectue en 2 temps :
L'équipe RED va tout d'abord scanner la machine de l'équipe BLUE afin d'en déterminer la surface d'attaque.
nmap -sN -sV <ip machine>
Il est possible de voir que 2 angles d'attaques sont possibles.
- Le SSH (version 10.2p1)
- le serveur web (apache 2.4.66)
Un premier test est effectué sur le ssh :
ssh user@<ip machine>
Le serveur répond que seule l'authentification par clé publique est autorisée.
Cette voie parait donc compliquée mais le serveur web à répondu.
Il est possible de tenter une connexion.
Pour entrer ici, deux solutions sont possibles :
- Utiliser les outils de DEV du navigateur (F12).
- Scanner le site et trouver un fichier qui contiendrait des informations.
La méthode 1 sera explorée.
Ouvrir les outils de dev avec 'F12'. Il y a un onglet "Réseau".
Si la page est rechargée, l'ensemble des fichiers chargés côté client vont s'afficher.
Examiner les différents fichiers pour trouver la porte d'entrée.
Pour la BLUE team
Objectif : Observer les traces de la reconnaissance
L'équipe BLUE ne va pas pouvoir immédiatement voir les traces de l'équipe RED sur la partie scan. En effet, le nmap n'effectuant au niveau réseau qu'un TCP SYN mais n'établissant pas de connexion complète, les traces ne sont pas visibles.
En revanche, la tentative de connexion ssh échouée aura laissé des traces.
Celles-ci sont visibles ici :
tail -f /var/log/auth.log | grep sshd-session
Info : La donnée importante icci est la raison de l'échec de connexion [preauth]. C'est elle qui confirme que la méthode d'accès (login/mdp) est incorrecte car le SSH est paramétré pour accepter les clés.