De nos jours, les exécutions de code à distance ou RCE (Remote Code Execution) font partie des attaques web les plus redoutées. Les risques qui en découlent sont critiques, car ce type de vulnérabilité permet en somme une prise de contrôle du système et d’être présent au sein du réseau de la victime (selon le contexte du serveur : dédié, mutualisé, interne etc.).
Au sein de cet article, il sera expliqué :
- Ce qu’est un interpréteur de commandes interactif et pourquoi un attaquant nécessite ou préfère son utilisation lorsqu’il dispose d’une vulnérabilité de type RCE.
- S’en suivra une analyse de deux manières d’obtenir un interpréteur en ligne de commandes interactif avec une RCE et des options existantes pour contraindre son obtention à un attaquant.
- Enfin, il sera expliqué une méthode spécifique appelée Forward shell qui peut être mise en place lorsque les deux autres font défaut.
Reverse shell
Le concept
La seconde méthode, et la plus utilisée afin d’obtenir un interpréteur de commandes interactif après l’exploitation d’une RCE, est appelée Reverse shell.
Celle-ci consiste à mettre en écoute un port sur la machine attaquante et de forcer la machine victime à s’y connecter tout en liant un interpréteur de commandes.
À l’aide de cette méthode, le problème de NAT est contourné, car il n’est pas nécessaire de contacter directement le serveur vulnérable à la RCE. En forçant la victime à se connecter à la machine attaquante, des règles de NAT particulières peuvent être configurées sur le routeur de l’attaquant afin de recevoir l’interpréteur de commandes.
Il existe également des services cloud permettant de lier une IP privée à une adresse publique en fonction d’un port facilitant le travail des attaquants.
De la même manière que pour le Bind shell, l’interpréteur de commandes obtenu après cette méthode ne sera pas interactif et il faudra également renseigner la commande python présentée précédemment pour y remédier.
En reprenant notre exemple, l’attaquant commence par mettre en écoute le port sur sa machine
L’attaquant force ensuite la machine victime à se connecter au port en écoute (4444) sur sa machine via une commande envoyée à l’aide de la RCE :
L’attaquant peut alors rendre interactif l’interpréteur de commandes obtenu sur sa machine à l’aide de la commande python citée précédemment et faire les mêmes opérations que pour le Bind shell
Les limitations…
Bien que cette technique soit la plus utilisée par les attaquants, il est possible de bloquer son obtention à l’aide de règles de pare-feu spécifiques.
Afin d’obtenir un Reverse shell, un attaquant a besoin que les flux sortants soient autorisés. De manière habituelle, ce sont les flux entrants qui sont particulièrement restreints et les restrictions sur les flux sortants sont plus permissives.
En prenant cet exemple d’architecture réseau minimaliste :
La table de pare-feu suivante permettrait de restreindre l’obtention d’un Reverse shell à un attaquant :
En effet, avec ces règles de pare-feu, uniquement les flux entrants HTTPS seraient autorisés et tous les autres flux seraient bloqués ne permettant pas un attaquant d’obtenir un Reverse shell.
Il existe alors une autre méthode afin d’obtenir un interpréteur de commandes interactif lorsque les
deux autres manières présentées ci-dessus ne peuvent être implémentées.
Découvrir d'autres articles
-
PentestTour d’horizon des attaques et vulnérabilités sur le gestionnaire de mots de passe KeePass
Lire l'article
