Les tests d'intrusion
Pour vérifier l'état de son réseau, un administrateur doit se comporter comme un pirate et tenter de pénétrer ses propres défenses. Cet article présente la démarche à suivre.
Introduction
Il est important de tester la sécurité de son propre réseau en se mettant à la place du pirate pour découvrir d'éventuelles failles. Ces tests se décomposent en plusieurs étapes :- phase d'approche : récupération d'informations sur le réseau cible ;
- phase d'analyse : détermination, à l'aide des résultats obtenus à l'étape précédente, des vulnérabilités potentielles et des outils nécessaires à leur exploitation ;
- phase d'attaques : passage à l'acte.
- Article 323-1 : Le fait d'accéder ou de se maintenir, frauduleusement, dans tout ou partie d'un système de traitement automatisé de données est puni d'un an d'emprisonnement et de 100 000 F d'amende.
Lorsqu'il en est résulté soit la suppression ou la modification de données contenues dans le système, soit une altération du fonctionnement de ce système, la peine est de deux ans d'emprisonnement et de 200 000 F d'amende. Article 323-2 : Le fait d'entraver ou de fausser le fonctionnement d'un système de traitement automatisé de données est puni de trois ans d'emprisonnement et de 300 000 F d'amende. Article 323-3 : Le fait d'introduire frauduleusement des données dans un système de traitement automatisé ou de supprimer ou de modifier frauduleusement les données qu'il contient est puni de trois ans d'emprisonnement et de 300 000 F d'amende. Le 323-1 concerne l'intrusion en elle-même. Lorsque que, de plus, elle induit des altérations des données du système, la peine est majorée. Le 323-2 porte sur des nuisances faites au réseau (virus, mail bombing, DoS, ...). Enfin, le 323-3 punit les modifications faites volontairement aux données présentes sur le réseaux (comprendre par "données" aussi bien les meilleurs scores à xbill que les fichiers de configuration du réseau).
Mettre à l'épreuve la sécurité d'un réseau signifie en général "résistance aux menaces externes". Cependant, de nombreuses opérations malveillantes sont facilement menées depuis une machine du réseau lui-même (virus, backdoor, sniffer...). Ces sources de danger sont rarement prises en considération lors de l'évaluation du réseau. De même, la plupart des attaques présentées dans l'article d'Éric Detoisien doivent également être évaluées (spoofing, (D)Dos...).
Des scénarii variés sont envisageables en guise de tests d'intrusion :
- le testeur ne connaît rien du réseau cible et ne dispose d'aucun accès à celui-ci, nous sommes dans le cas d'un test d'intrusion externe ;
- le testeur dispose de privilèges minimaux sur le réseau cible (compte utilisateur quelconque). Il cherche à accroître ses privilèges depuis l'intérieur même du réseau (écrans de veille non activés, sniffing, exploitation de vulnérabilités locales..). Dans ce cas, il s'agit d'un test d'intrusion interne.
La guerre de l'information
Nous nous plaçons donc dans la peau d'une personne qui cherche à récolter un maximum de renseignements sur un réseau cible. Cette collecte se divise en deux étapes. Dans un premier temps, nous allons récupérer toutes les informations disponibles sans accéder directement aux ressources de la cible. Ensuite, lorsque nous commencerons à avoir une idée plus précise de ce dont il retourne, nous accéderons directement aux moyens fournis par la cible.- des informations administratives comme des noms, téléphones et adresses pour différents contacts (admin-c, tech-c, zone-c, bill-c...) ;
- des informations techniques telles que le(s) nom(s) du(des) DNS(s), les adresses emails des responsables évoqués ci-dessus, les ensembles d'adresses IP alloués à la cible...
Les sociétés qui enregistrent les noms de domaine offrent généralement un service d'interrogation en ligne (voir le tableau 1). Sous Unix, il existe également la commande whois.
Pour vous montrer la richesses des inforamtions contenues dans ce type de base, rien de tel qu'un petit exemple sur un nom de domaine (fictif pour des raisons de confidentialité) :
[root@testeur -> ~]$ whois pigeons.fr@whois.nic.fr
[whois.nic.fr]
Tous droits reserves par copyright.
Voir http://www.nic.fr/outils/dbcopyright.html
Rights restricted by copyright.
See http://www.nic.fr/outils/dbcopyright.html
domain: pigeons.fr
descr: PIGEON ET CIE
descr: 10 RUE DE PARIS
descr: 75001 Paris
admin-c: BPxxx-FRNIC
tech-c: LPxxx-FRNIC
zone-c: CPxxx-FRNIC Nous apprenons que la société Pigeon et Cie est en fait hébergée par Heberge Telecom. Les adresses emails correspondent sans doute à des alias, mais elles nous fournissent également une piste sur l'existence de comptes sur des machines : si les mots de passe correspondant sont faibles (comme les prénoms, dates de naissance...), cette information peut se révéler utile.
Toujours via les bases whois des recherches plus poussées à partir d'une adresse IP appartenant à la société Pigeon et Cie nous amènent à découvrir les classes d'adresses IP qui lui ont été allouées. Pour cela, nous utilisons la base whois de RIPE qui se révèle être la plus pertinente :
En outre, des recherches croisées sur les noms récupérés peuvent nous donner des informations supplémentaires sur la cible (découvrir de nouvelles adresses IP ou de nouveaux serveurs DNS).Le bilan des recherches via les bases whois est très concluant puisque nous avons récupéré :
- les serveurs DNS ayant autorité sur le domaine pigeons.fr ;
- les coordonnées des contacts administratifs et techniques liés à Pigeon et Cie ;
- les classes d'adresses IP alloués à la société Pigeon et Cie.
Du point de vue de la cible, nous verrons également comment déjouer certaine interrogation. A la différence des étapes précédentes, la cible contrôle maintenant les données que le testeur recherche. C'est donc à elle de faire en sorte de les limiter au minimum.
Pour obtenir des informations de ces serveurs, il suffit de les interroger dans un langage qu'ils comprennent à savoir le protocole DNS. Plusieurs requêtes sont à notre disposition :
- Récupération de tous les serveurs DNS ayant autorités sur le domaine
- Le transfert de zone renvoie toute la configuration du serveur DNS
Le but du scan est similaire à celui de l'éclaireur. Le testeur (ou le pirate) détermine ainsi le rôle des machines, les services accessibles, les protocoles supportés... A la fin de l'opération, les informations suivantes sont obtenues :
- les adresses IP des machines du réseau ;
- la liste des services disponibles ;
- la liste des différents protocoles supportés (TCP, UDP, ICMP...)
- pour un maximum de machines, l'état de chacun de ses ports.
Il existe différentes solutions pour échapper à ce genre de détecteurs, en spoofant des adresses IP ou en distribuant le scan depuis plusieurs machines.
Par exemple, lorsque l'adresse source du paquet est spoofée, la machine de test reste inconnue de la machine cible, bien que celle-ci sache alors qu'elle a été scannée :
- kelly (192.168.1.3) la machine de tests
- bosley (192.168.1.2) une machine calme (i.e. qui ne génère pas beaucoup de trafic) ;
- charly (192.168.1.1) la machine cible.
Au contraire, lorsque le port cible n'est pas ouvert, charly n'émet aucun paquet. Le champs id ne varie alors pas :
Le port cible (hping -a bosley -p 80 -S charly) est donc fermé. Les logs de charly contiennent une tentative de connexion provenant de bosley.Pour induire un scan en erreur, il est également possible de laisser tourner un pot de mielhonney pot). Ceci ressemble à un serveur, a le goût d'un serveur, mais ce n'est pas un vrai serveur : (
Il suffit alors de le mettre sur le port de son choix : Nous lançons notre serveur fake sur le port 21 (ftp). lsof nous révèle bien qu'un serveur écoute sur ce port 21. Toutefois, nmap (scanner de port) se laisse abuser car il tente juste d'ouvrir une connexion sur le port 21. Comme il réussit, il croit que c'est bien un serveur ftp. L'illusion fonctionne avec ce type de scanners réseau car ils ne cherchent pas réellement à se connecter. Toute connexion plus approfondie révélera la supercherie, à moins d'affiner le faux serveur (par exemple en ajoutant les bannières pour simuler le service désiré). Signalons enfin que la commande nc (netcat) produit un résultat similaire (nc -l -p 21 pour écouter sur le port 21).Ce genre de défense s'appelle pot de miel. Les projets honeynets et honneypots mettent en place des réseaux, ou des machines, destinés à attirer les pirates pour apprendre leurs techniques.
Scanner une machine se résumé toujours à envoyer un paquet de la machine de tests à la machine cible, indépendamment de la méthode employée. Selon les moyens de la machine cible (i.e. la sécurité attendue sur celle-ci), une tentative avec 2 paquets par jour suffit pour détecter le scan. Il faut alors de gros disques et enregistrer tous les paquets qui arrivent sur la machine pour analyser ces données sur plusieurs jours afin de reconstituer le scan.
Chaque OS possède sa propre conception de la gestion des protocoles réseaux. D'une part, certains champs sont laissés à la charge de l'OS (TTL, ToS, Win, DF...). D'autre part, même si les RFC définissent l'essentiel, elles ne sont pas toujours scrupuleusement respectées. De plus, si elles interdisent bien certaines configurations de paquets, elles ne précisent toutefois pas comment y répondre. Par exemple, que faire d'un paquet qui contient le flag 64, non défini ? Chacun a sa solution.
- le champs TTL (time to live) des paquets sortants ;
- la taille de la fenêtre (window) ;
- le bit DF (Don't Fragment) ;
- le champs TOS (Type Of Service).
- ...
Par exemple, le champs id permet de distinguer facilement les linux 2.2.x des 2.4.x (la commande hping -1 -c 3 émet 3 paquets de type 1 i.e. ICMP) :
Une méthode plus performante consiste à analyser les réponses de l'OS cible face à certains paquets : le testeur connaît alors le comportement de la pile TCP/IP de la cible, ce qui est suffisant pour identifier l'OS si les t ests sont bien choisis.
nmap (encore et toujours ;) utilise exactement cette démarche lorsque l'option -O (OS identification) est activée. Une base de données contient les réponses types selon les OS. Ainsi, l'empreinte des noyaux Linux 2.4.0 - 2.4.5 correspond à :
Les tests en eux-mêmes sont décrits par les lignes Ti. La lecture de l'article de Fyodor paru dans phrack vous les détaillera (phrack 54, fichier 9/12). Toutefois, dévoilons succinctement la signification de chacun :- TSeq : décrit la nature de l'incrémentation des numéros de séquence ;
- T1 : paquet TCP avec le flag SYN|64 (comme 64 ne correspond à aucune valeur de flag, le paquet est "syn-bogué") vers un port ouvert ;
- T2 : paquet TCP NULL, i.e. ne contenant aucune option ni aucun flag, vers un port ouvert ;
- T3 : paquet TCP avec les flags SYN|FIN|URG|PSH vers un port ouvert ;
- T4 : paquet TCP avec le flag ACK vers un port ouvert ;
- T5 : paquet TCP avec le flag SYN vers un port fermé ;
- T6 : paquet TCP avec le flag ACK vers un port fermé ;
- T7 : paquet TCP avec le flag FIN|PSH|URG vers un port fermé ;
- PU : paquet UDP envoyé à un port fermé afin de récupérer un paquet ICMP "port unreachable".
- FTP (port 21)
Souvent la version est dévoilée dès le login : Cependant, certains serveurs autorisent la dissimulation de la bannière. La commande STAT peut nous sauver : telnet (port 23):
Avant même que la connexion soit validée par le mot de passe, le serveur renvoie les informations recherchées : Si vous tenez vraiment à utiliser telnet, l'option -h ne les affichera qu'une fois le client authentifié.
DNS (port 53) :
Nous avons vu qu'il était assez simple de récupérer la version d'un serveur DNS. Il est cependant possible de fausser cette information en modifiant le champs options dans /etc/named.conf : HTTP (port 80) :
La commande HEAD ne renvoie que les méta-informations constituant l'en-tête HTTP :