Analyse d’une architecture réseau

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

2. 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

3. Introduction

4. 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)

5. 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…)

6. 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é.

7. 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

8. Méthodologie - une introduction

9. 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

10. 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)

11. 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 • ...

12. 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

13. 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

14. 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 »

15. 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

16. 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)

17. 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)

18. 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

19. Limites des analyses

20. 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

21. 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

22. 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.

23. 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

24. La prise d’empreinte

25. 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

26. 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

27. 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

28. 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

29. 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 »)

30. 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)

31. 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.

32. 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

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

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

35. 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) pourleurrer cette technique (IP personality)

36. 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

37. 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 • ...

38. Utilisation des outils d’audit

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

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

41. 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

42. 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

43. 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)

44. Quelques outils complémentaires

45. Identification et exploitation des vulnérabilités

46. 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

47. Le rapport d’analyse

48. 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.

49. 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…)

50. 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.