Analyse d’une architecture réseau Mastère SSI Module M9 Jean-Christophe GALLARD jgallard@free.fr

Plan du Cours Introduction Méthodologie - une introduction Limites de telles analyses Prise d’empreinte Utilisation des outils d ’audit Identification et exploitation des vulnérabilités Le rapport d’analyse Conclusion

Introduction

Introduction A quoi sert un audit technique? => Fournir un « instantané » technique objectif de l’état de la sécurité d’un Système Deux grand types d’audit : « Boîte blanche » « Boîte noire » (red team, pen test - test intrusif en conditions quasi réelles)

Introduction Audit « boîte blanche » : type d’audit dans lequel l’auditeur dispose : de toutes les informations voulues (documentation, administrateurs…), d’un accès physique aux éléments constitutifs du Système d’Information volonté d’exhaustivité des vulnérabilités (vœux pieux…)

Introduction Audit « boîte noire » : type d’audit dans lequel l’auditeur se place dans la position d’un attaquant probable (dénommé également « test intrusif »). L’attaquant supposé n’est pas nécessairement un pirate sévissant sur l’Internet (attaquant interne à l’entreprise par exemple) Les informations utiles ne sont pas forcément toutes disponibles On cherche surtout à démontrer la faisabilité d’une attaque depuis un point donné.

Introduction Différences entre les deux méthodes: motivations furtivité (quoi que…) phase d’apprentissage plus lourde en boite noire résultats plus riches en boîte blanche Similitudes : mêmes outils à de rares différences près mêmes techniques PAS de garantie d’exhaustivité => raisons pour lesquelles ce même cours recouvre les deux aspects

Méthodologie - une introduction

Problématique de l’analyse de vulnérabilités Que cherche t-on ? Quelles sont les conditions initiales (accès local, distant…) Jusqu’où est on autorisé à aller ? Problèmes légaux

Traçabilité des actions (1/2) Toute analyse technique revêt une part de risque : pour l’audité (mise à mal de son système, déni de service, traces mal effacées…), et ses éventuels partenaires (dommages collatéraux ?) mais aussi pour l’auditeur (risque juridique - code pénal)

Traçabilité des actions (2/2) D’ou une nécessité de TOUJOURS tracer la moindre action : journal de bord logs des outils logs systèmes keylogger ...

Les bases de vulnérabilités (1/2) Domaine très vaste Présentes sous deux formes : bases formelles : souvent présentes dans les outils d’analyse automatique et couplées aux « exploits » correspondants, bases informelles : bases personnelles, mais surtout sites Internet spécialisés

Les bases de vulnérabilités (2/2) Quelques sites incontournables : Packetstorm http://packetstorm.dnsi.info/ (miroir France) SecurityFocus http://www.securityfocus.com/ La liste bugtraq / NTBugtraq http://www.ntbugtraq.com/ http://www.bugtraq.com/ Le site CVE : http://cve.mitre.org/ CERT http://www.cert.org Microsoft http://www.microsoft.com/technet/security/current.asp

La prise de renseignement technique (1/2) Notion de prise d’empreinte (fingerprinting) Principe de base : « Chaque système trahit son existence et ses paramètres par son comportement »

La prise de renseignement technique (2/2) Principalement utilisée en boîte noire, mais peut être une précieuse alliée même en boite blanche Techniques actives et/ou passives En boîte blanche ; sert de complément indispensable à l’analyse des documentations fournies => vérification de leur justesse et situation réelle comparée à celle supposée

L’identification des vulnérabilités (1/2) Un seul outil reste vraiment indispensable : Un cerveau (standard et de préférence en état de fonctionnement)

L’identification des vulnérabilités (2/2) Des outils + ou - automatiques peuvent être employés : scanners de services (port scanners) scanners de vulnérabilités (spécifiques ou généralistes) outils standards détournés de leur utilisation normale (telnet, traceroute, nslookup…) outillage réseau complémentaire (sniffers, générateurs de paquets)

L’exploitation des vulnérabilités La mise de jour de certaines vulnérabilités peut amener à progresser plus avant dans le système si on les exploite En boite boire : c’est un peu le but du jeu… En boîte blanche : ATTENTION à ne pas outrepasser ses droits A tracer avec la plus extrême minutie

Limites des analyses

Limites techniques / exhaustivité des résultats La qualité des résultats obtenus reste fortement dépendante des facteurs suivants : caractéristiques des moyens de com (débit du point d’accès, QoS…) efficacité des outils de tests à disposition efficacité des moyens de filtrages entre « l’attaquant » et sa cible présence ou non de contres-mesures (IDS, systèmes réactifs, honeypot…) types de protocoles utilisés... Dans tous les cas il n’existe AUCUNE garantie d’exhaustivité => problème du niveau d’assurance

Contraintes Certaines contraintes techniques et/ou organisationnelles peuvent s’avérer particulièrement pénalisantes pour l’auditeur : méfiance des utilisateurs / administrateurs (boîte blanche) => rétention d ’information, voire désinformation débit du point d’accès insuffisant pour mener certains tests nécessité de mener des tests furtifs délais d’audit très courts Déni de service

Problématique du déni de service De nombreuses vulnérabilités en déni de service ne peuvent être mises en évidence qu’en réalisant le test « en live ». => si le test est positif, le système cible devient hors service ! => l’auditeur censé améliorer la sécurité devient alors celui qui la dégrade... Une règle : ne JAMAIS réaliser de test en DoS sauf en cas de demande écrite explicite.

L’abaissement du niveau de sécurité d’origine Un mal nécessaire ? Progresser dans un SI nécessite parfois que l’auditeur (en particulier en red team) s’installe une ou plusieurs portes de services dans le système cible. Conséquence : cette action dégrade la sécurité du système cible Si cette action apparaît inévitable ; faire en sorte de protéger ces entrées de services. Toujours avertir le responsable avant l’introduction d’une telle porte d’entrée

La prise d’empreinte

Techniques passives (1/2) Technique de base : le « sniffing » Analyse de flux binaires sur un réseau : identifier les machines et leurs rôles, les services utilisés, les utilisateurs, les habitudes de fonctionnement De très nombreux outils disponibles (de 0 à 40.000 €), plus ou moins performants et spécialisés

Techniques passives (2/2) Reconstitution de l ’architecture d ’un réseau : Cette phase, souvent utilisée en Red Team simulant une attaque interne, consiste à tenter de reconstituer l ’architecture d’un SI à l ’aide d’informations récupérées passivement. sera par la suite complétée par des investigations actives

Techniques actives (1/9) Exploitation des particularités des protocoles réseau : En-têtes Ethernet (id constructeur) Protocoles ARP/RARP ICMP (traceroute, enregistrement de routes, messages de paquets détruits, pings…) broadcasting (ethernet, IP) Bannières de connexions

Techniques actives (2/9) Environnements commutés : dans un environnement switché, il n’est plus possible de capturer tout le traffic sur un segment de réseau. Cependant, il est parfois possible de contourner la difficulté : Trames de broadcast (passif) passage du switch en mode « diffusion » (aggressif) manipulation ARP/RARP

Techniques actives (3/9) Le « port scanning » : « déterminer la liste exhaustive des services réseaux disponible sur une machine donnée » Utilise les particularités des protocoles TCP-UDP/IP : Syn Scan (scan classique) Half Syn Scan (furtivité de base) Idle Host Scanning (furtivité évoluée) … Très nombreux outils (nmap : la « star »)

Techniques actives (4/9) Principe de base de détection de port TCP ouvert : Client Serveur SYN ACK, SYN ACK Toute réponse d’acquittement à une trame de type SYN implique que le port TCP correspondant est ouvert (poursuite des échanges)

Techniques actives (5/9) Technique du Half-Syn Scan : Identique au SYN scan à ceci près que, lors d’une réponse « ACK,SYN », l’attaquant ne poursuit pas les échanges => comme la connexion n’est pas menée à son terme, rien n’apparaît dans les éventuels logs du système.

Techniques actives (6/9) Technique de l’Idle Host Scanning : on utilise une machine tierce, inactive et dont les numéros de séquence TCP sont prévisibles utilisation de Hping pour émettre des paquets IP à la cible et dont l’adresse source est falsifiée (source = machine tierce) envoi de trames (hping) à la machine tierce et analyse des numéros de séquences renvoyés Vu de la victime : c’est la machine tierce qui réalise les scans

Techniques actives (7/9) Cas 1 : port TCP ouvert C A 1 : Src = B Cible Attaquant 2 : ACK, SYN 3: RST 4 : requêtes IP 5 : Réponses IP car paquets RST émis dans (Sauts de séquences l’intervalle) B Machine Tierce Plus de prévisibilité des numéros de séquence : => Le port est ouvert

Techniques actives (8/9) Cas 2 : port TCP fermé C A 1 : Src = B Cible Attaquant 2 : RST 3 : requêtes IP (pas de sauts de séquences) 4 : Réponse IP Poubelle ! B Prévisibilité des numéros de séquence maintenus => Le port est fermé Machine Tierce

Techniques actives (9/9) OS Fingerprinting : détection de système d’exploitation Plusieurs techniques « ancestrales »: état global des services disponibles (+ ou - fiable) bannières de connexion (problèmes de falsification ou d’absence) exploitation de certains services réseaux (ex : Netbios) Méthode de Fyodor (nmap): technique la plus aboutie « repérer les particularités des piles TCP/IP des OS par analyse des réponses à des requêtes IP données » il existe cependant des patchs (Linux) pour leurrer cette technique (IP personality)

Détection des paramètres de configuration d’un OS (1/2) Les services « bavards » : certains services réseau donnent de nombreuses informations sur l’état de configuration d’un OS => exploiter ces particularités pour se renseigner. Finger, SNMP FTP E-Mail et bien sûr : SMB-CIFS / NetBios

Détection des paramètres de configuration d’un OS (2/2) Cas de Windows Les services réseau de Windows sont TRES bavards En outre, selon la configuration choisie, la récupération d’information peut se faire sans être authentifié sur le système cible. LanGuard NetWork Scanner Winfingerprint Hyena ...

Utilisation des outils d’audit

Les scanners de vulnérabilités (1/2) Les « Stars » : ISS Nessus Saint Cybercop Scanner (anciennement Balista)

Les scanners de vulnérabilités(2/2) Offre du marché (non exhaustif):

Mise en œuvre de scanners de vulnérabilités (1/2) Ciblage et paramétrage : ne mener que les tests utiles Démarche incrémentale : Zero knowledge Anonymous mode User mode Admin mode

Mise en œuvre de scanners de vulnérabilités (2/2) Dépouillement des résultats : quelles vulnérabilités retenir ? Sont elles pertinentes ? Sont elles exploitables ? Dans quelles conditions ? Peut-on s’en protéger ? Comment ? => détermination du chemin d’attaque

Tests Manuels Complément aux tests automatiques Constitue un « ciment » pour l’audit technique Exemples en boîte blanche : vérification de la configuration locale d’une machine analyse d’un fichier de filtrage (routeur ou firewall)

Quelques outils complémentaires

Identification et exploitation des vulnérabilités

Identification et exploitation des vulnérabilités La phase de dépouillement doit permettre la mise en évidence des vulnérabilités exploitables sur le système cible. Cette liste peut être exploitée afin de poursuivre les investigations : démarche incrémentale Mise en évidence de chemin(s) d’attaque et, surtout, des chemins critiques : permettra de valuer les vulnérabilités... ...et de prioriser les corrections

Le rapport d’analyse

Généralités L’objectif du rapport d’audit est de fournir à l’audité les éléments nécessaires à une meilleure sécurité de son système d ’information A ce titre, il ne doit pas constituer une simple liste « à la Prévert » des failles décelées. Chaque faille doit être pondérée en fonction : de sa gravité, de son caractère exploitable ou non, et dans quelles conditions.

Généralités Un rapport d’audit doit également préciser une proposition de plan d’action personnalisé pour améliorer la sécurité : du général au particulier ne pas hésiter à regrouper les failles décelées sous une même contre-mesure lorsque cela est possible proposer des jalons temporels chiffrer les coûts (financiers, mais surtout humains), même approximativement adapter le plan d’action à l’audité (capacités financières et humaines, temps nécessaire…)

Quelles informations donner ? Deux approches : Exhaustive : toutes les vulnérabilités sont listées Synthétique : on ne donne que les points les plus durs Solution optimale : opter pour un mélange des deux approches : une synthèse courte des problèmes rencontrés, essentiellement à l’attention des décideurs une ou plusieurs annexes, plutôt destinées aux administrateurs.

Quelles informations donner ? Ne pas hésiter à marquer les esprits en disant les choses telles qu’elles sont : un auditeur est avant tout une personne extérieure au système, présentant ses résultats sans compromis et de la façon la plus objective. Toujours rester factuel, bannir le « flou artistique ».

Conclusions