Nous savons maintenant que l'attaquant a eu accès au PC d'un administrateur. Nous pensons qu'il a pu compromettre un de nos serveurs.
Votre mission est de repérer dans des logs pare-feu et dans le dump simplifié d'un de nos serveurs ce que l'attaquant a pu faire.
## Objectif de la mission:
- Identifier le moyen utilisé par l'attaquant pour effectuer des téléchargements depuis un serveur interne
- Repérer les URL/ressources téléchargées
- Déterminer la nature de la tentative d'exploitation et ses conséquences: CVE visée, binaire compromis, fonction exploitée et moment où l'attaquant a obtenu des privilèges élevés
## Documents mis à votre disposition:
- Logs pare-feu montrant le trafic initié depuis le serveur de supervision
- Dump simplifié du serveur contenant les fichiers système et les journaux
- Schéma réseau de l'infrastructure
## Votre rôle:
Croiser les éléments temporels et techniques pour retracer au mieux les mouvements de l'attaquant !
Dans un premier temps il suffit d'analyser les logs du pare-feu.
Etant donné que le but de cette question est de comprendre comment le serveur de supervision télécharge des fichiers,
on peut se focaliser sur les connexions sortantes du serveur de supervision.
On peut voir que beaucoup de logs sont sur le port 53, donc des logs DNS. Ce qui nous intéresse pas.
On peut donc filtrer pour retirer ces logs.
Maintenant en regardant les logs on observe ceci:
On peut comprendre que 10.0.1.1 en passant par le port 8080 demande quelque chose à 10.0.2.101.
En reprenant le schéma de l'architecture, on se rend compte qu'un serveur fait une requête à un PC admin.
De plus en reprenant le contexte, l'attaquant a accès au PC admin et au serveur.
Plus loin on observe qu'une requête a été faite entre le PC admin et une autre adresse IP mais sur le port 80. On peut donc déduire que l'attaquant passe par un proxy sur le pc admin, pour faire des téléchargements sur le serveur.
En prenant le dump simplifié du système, on se rend dans home/usr1.
On peut observer 3 paquets installer.
En prenant le paquet sudo, on le décompile.
En regardant le fichier ChangeLog, on observe que nous sommes sur la version sudo-1.9.16p2.
Il suffit de chercher sur internet les CVE sur cette version de sudo.
Et on trouve la CVE:
Pour ce faire il faut aller regarder les logs dans /var/log.
On y retrouve 2 fichiers de logs.
Quand on ouvre les logs de journalctl on peut y retrouver qu'un binaire a segmentation fault plusieurs fois.
Ensuite on peut voir dans les logs de audit que le fichier a été appelé plusieurs fois au même moment.
On y retrouve donc le binaire path vers ce binaire, il suffit juste de prendre le sha256 de ce binaire.
Lorsqu'on analyse sur le binaire, on peut tomber sur la fonction process_config_line.
On peut voir ici un strcpy sur un buffer de 64.
De plus dans les logs, on peut voir ceci que backup_tool segmentation fault à l'adresse 6 161 616 151.
On peut donc déduire que l'attaquant a essayé d'exploiter un buffer overflow avec un fichier contenant plein de a.
Pour ce faire nous devons le reverse.
En prenant Ghidra par exemple on peut traverser le code.
Lorsqu'on observe la fonction vulnérable commençant par copy.
On peut observer un appel vers la fonction system.
Juste au-dessus il y a la chaîne de caractères vulnérable.
Comme on le voit. Il suffit de créer une chaîne de caractères ressemblant à ceci :
cp -f ; /bin/bash # .
Ce qui va faire échouer le cp, et ensuite exécuter le bash.
Pour créer cette chaîne de caractères, on remonte dans la fonction main.
Ici on peut voir qu'un fichier est lu ligne par ligne, et ensuite donné à la fonction vulnérable.
En remontant dans la fonction main, on comprend que ce fichier-là correspond à l'argument. Et donc il suffit de mettre dans notre fichier, la ligne montrée plus haut.
En explorant les logs de audit, on peut observer ceci:
En analysant, on peut voir que le binaire backup_tool a été lancé avec des arguments, que un cp a été fait mais sans argument supplémentaire.
Puis un bash a été ouvert avec le userid à 0 et le groupuid à 0 aussi, puis la commande id a été faite.
Il suffit donc de prendre le timestamp associé à l'id et on obtient l'heure à laquelle il est passé root.
