Analysez la trace réseau pour déterminer comment l'attaquant a pu obtenir
l'accès au serveur de fichiers.
L'administrateur réseau a avoué avoir laissé les identifiants par défaut sur le
serveur d'impression. Cependant, il affirme que celui stockant les films a des
mots de passe robustes.
L'objectif est de comprendre comment l'attaquant a pu obtenir une connexion au
serveur de fichiers. Analysez le réseau pour trouver comment l'attaquant s'est
propagé.
Lors de la première phase, nous observons une série de requêtes ICMP envoyées
par l'attaquant depuis le serveur d'impression (10.0.2.129) vers la cible
(10.0.2.128).
Ensuite, l'attaquant envoie une requête TCP SYN vers le port 445 (SMB) de la
cible, qui répond avec un SYN-ACK, indiquant que le port est ouvert.
L'attaquant sait maintenant que le service SMB est actif sur la cible et peut
procéder à l'exploitation.
Une première chose à noter est la version utilisée du protocole par le serveur.
Pour cela, il suffit de regarder le champ Dialect d'une réponse de négociation
de protocole.
Par la suite, nous observons un envoi de paquets SMB compressés malformés
depuis l'attaquant vers la cible.
Filtre utilisé : smb2
Nous pouvons compter 2012 paquets marqués avec [Malformed Packet] (filtre :
smb2 && _ws.col.info contains "Malformed") et 3593 marqués avec
Comp. SMB3 (invalid) (filtre : smb2 && _ws.col.info contains "invalid").
Toutes ces requêtes ont pour point commun d'avoir le contenu de leurs données
compressées rempli de A, B, ou \0, indiquant un lien avec un dépassement
mémoire.
À ce point, il est encore difficile d'identifier avec exactitude la
vulnérabilité exploitée ici.
Au bout d'un certain temps, l'envoi massif de paquets SMB compressés malformés
cesse, et nous observons 3 derniers envois de requêtes SMB.
Filtre utilisé : smb2 && not _ws.col.info contains "Negotiate"
Elles se démarquent par le contenu de la donnée compressée, qui n'est plus une
répétition du même octet, comme précédemment.
Il est donc pertinent de penser que ce contenu est une charge utile à l'attaque.
En recherchant des CVE pour la version utilisée de SMB, et exploitant la
compression pour permettre une exécution de code arbitraire (voir partie
suivante), le résultat le plus pertinent est SMBGhost.
Il s'agit ici des 3 dernières requêtes SMB envoyées.
Mais il est difficile de l'exploiter autre que pour causer un écran bleu sans
avoir connaissance de certaines adresses mémoire spécifiques.
C'est la raison pour laquelle elle est souvent exploitée conjointement avec
d'autres vulnérabilités, la plus commune étant SMBleed.
SMBleed permet de lire des données sensibles en mémoire.
L'objectif de l'attaquant est de récupérer des informations sur la disposition
de la mémoire du serveur cible, afin d'exploiter efficacement SMBGhost.
Dans les paquets TCP qui suivent, nous pouvons voir les différentes commandes
exécutées par l'attaquant sur le serveur de fichiers, la première étant un
whoami dans le segment 94245.
La réponse à cette commande est trouvable dans le segment 95469.
Depuis SMB 3.1.1, il est possible de compresser la donnée pour réduire la
quantité transmise sur le réseau.
Cette méthode est différente de celle utilisée par NTFS ou les archives ZIP.
Elle agit uniquement pendant la transmission réseau.
Cette CVE, surnommée SMBGhost, est une vulnérabilité découverte dans SMB
3.1.1.
Lorsqu'un paquet SMB compressé est malformé, le code interne calcule mal les
tailles, ce qui alloue un tampon plus petit que nécessaire.
Cela fait que plus de données sont recopiées dans ce tampon que prévu,
entraînant un dépassement mémoire côté serveur.
Puisque la surface d'attaque est accessible à distance et sans authentification,
un attaquant peut exploiter cette vulnérabilité à distance et sans
authentification pour exécuter du code arbitraire sur le système cible.
Cette CVE, surnommée SMBleed, utilise le même principe que la CVE-2020-0796,
mais au lieu d'exécuter du code arbitraire, elle permet de lire des données
sensibles en mémoire.
En envoyant des paquets SMB compressés malformés, un attaquant peut déduire la
valeur de certains octets en mémoire, selon si une réponse est reçue ou non.
Autrement dit, une bonne exploitation de cette vulnérabilité permet de
recomposer la valeur de certaines adresses provenant de zones du noyau ou du tas
qui peuvent contenir des informations sensibles.
En pratique, une corruption de mémoire via SMBGhost à l'aveugle est
difficile d'exploiter de manière fiable à cause des randomisations d'adresses et
des variations de structures entre les différentes versions de Windows.
Cependant, en la combinant avec SMBleed, un attaquant peut d'abord utiliser
la seconde pour lire la mémoire du serveur et découvrir les adresses nécessaires
et calculer les décalages pour exploiter la première de manière fiable.
Avec ces informations, l'attaquant peut transformer le débordement en une
exécution de code à distance reproductible.
La combinaison de ces deux exploitations est souvent appelée
SMBleedingGhost.