• Save
Pinhole story
Upcoming SlideShare
Loading in...5
×
 

Pinhole story

on

  • 418 views

Histoire d’une technique pour faire des trous d’épingles ou la difficile gestion d’un problème de sécurité. La découverte d’une attaque sur les pare-feu à état m’a amené à devoir ...

Histoire d’une technique pour faire des trous d’épingles ou la difficile gestion d’un problème de sécurité. La découverte d’une attaque sur les pare-feu à état m’a amené à devoir gérer les problèmes de la correction et de la divulgation de la faille. Le but de cette présentation est de faire un retour sur l’expérience acquise dans la gestion d’une telle problématique.

Statistics

Views

Total Views
418
Views on SlideShare
418
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Pinhole story Pinhole story Presentation Transcript

  • Histoire d’une technique pour faire des trous d’épingles ou la difficile gestion d’un problème de sécurité Éric Leblond OISF Kernel Recipes 2012Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 1 / 14
  • Eric Leblond (Regit) Spécialiste de la sécurité des réseaux Créateur du projet NuFW, co-fondateur de la société EdenWall Auteur de coccigrep, un grep sémantique basé sur coccinelle Développeur Netfilter : Ulogd2: démon de journalisation de Netfilter Contributions diverses: Bibliothèques NFQUEUE et dépendances. Travail sur le journalisation. Actuellement : Consultant indépendant en sécurité Développeur financé de l’IDS/IPS Suricata Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 2 / 14
  • Une "nouvelle" technique d’attaqueDes couches OSI indépendantes Les couches 2 et 3 sont traités indépendamment Il est donc possible d’usurper une identité du niveau 3 En utilisant une couche 2 valide Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 3 / 14 View slide
  • Une "nouvelle" technique d’attaqueDes couches OSI indépendantes Les couches 2 et 3 sont traités indépendamment Il est donc possible d’usurper une identité du niveau 3 En utilisant une couche 2 valideUne attaque locale L’attaquant doit être connecté sur le même réseau Ethernet que le pare-feu Pas d’ouverture distante possible Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 3 / 14 View slide
  • Essai sur Netfilter Video Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 4 / 14
  • Essai sur Netfilter VideoPrenons un pare-feu avec une politique de filtrage autorisantseulement le port 21 et ouvrons une connexion vers le port 22 duserveur FTP. Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 4 / 14
  • Violation de la politique de sécurité Nous sommes parvenus à ouvrir une connexion sur le port 22. Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 5 / 14
  • Violation de la politique de sécurité Nous sommes parvenus à ouvrir une connexion sur le port 22. Avec une politique de filtrage ne le permettant pas. Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 5 / 14
  • Violation de la politique de sécurité Nous sommes parvenus à ouvrir une connexion sur le port 22. Avec une politique de filtrage ne le permettant pas. Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 5 / 14
  • Violation de la politique de sécurité Nous sommes parvenus à ouvrir une connexion sur le port 22. Avec une politique de filtrage ne le permettant pas. Tout doux, chaton, tout doux! Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 5 / 14
  • Contre-mesures L’anti-spoofing est suffisant pour bloquer l’attaque. Reverse path filtering est notre ami: Accepter seulement les paquet arrivant sur une interface si on a une route vers cette source passant par cette interface. Le noyau ne traitera alors pas le paquet d’attaque. C’est si facile d’être protégé? Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 6 / 14
  • Contre-mesures L’anti-spoofing est suffisant pour bloquer l’attaque. Reverse path filtering est notre ami: Accepter seulement les paquet arrivant sur une interface si on a une route vers cette source passant par cette interface. Le noyau ne traitera alors pas le paquet d’attaque. C’est si facile d’être protégé? Oui Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 6 / 14
  • Contre-mesures L’anti-spoofing est suffisant pour bloquer l’attaque. Reverse path filtering est notre ami: Accepter seulement les paquet arrivant sur une interface si on a une route vers cette source passant par cette interface. Le noyau ne traitera alors pas le paquet d’attaque. C’est si facile d’être protégé? Oui Mais il reste quelques surprises. Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 6 / 14
  • Protection de Netfilter Il suffit d’utiliser la fonctionnalité rp_filter. Elle est disponible depuis le siècle dernier dans tout les noyaux Linux. Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 7 / 14
  • Protection de Netfilter Il suffit d’utiliser la fonctionnalité rp_filter. Elle est disponible depuis le siècle dernier dans tout les noyaux Linux. Désactivée par défaut. Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 7 / 14
  • Protection de Netfilter Il suffit d’utiliser la fonctionnalité rp_filter. Elle est disponible depuis le siècle dernier dans tout les noyaux Linux. Désactivée par défaut. Une vérification de routage pour chaque paquet est trop couteuse Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 7 / 14
  • Protection de Netfilter Il suffit d’utiliser la fonctionnalité rp_filter. Elle est disponible depuis le siècle dernier dans tout les noyaux Linux. Désactivée par défaut. Une vérification de routage pour chaque paquet est trop couteuse Activée par tous les scripts de filtrage décents Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 7 / 14
  • Protection de Netfilter Il suffit d’utiliser la fonctionnalité rp_filter. Elle est disponible depuis le siècle dernier dans tout les noyaux Linux. Désactivée par défaut. Une vérification de routage pour chaque paquet est trop couteuse Activée par tous les scripts de filtrage décents Pour l’activer: echo " 1 " > / proc / sys / n e t / i p v 4 / c o n f / a l l / r p _ f i l t e r Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 7 / 14
  • Protection de Netfilter Il suffit d’utiliser la fonctionnalité rp_filter. Elle est disponible depuis le siècle dernier dans tout les noyaux Linux. Désactivée par défaut. Une vérification de routage pour chaque paquet est trop couteuse Activée par tous les scripts de filtrage décents Pour l’activer: echo " 1 " > / proc / sys / n e t / i p v 4 / c o n f / a l l / r p _ f i l t e r Hummmmm Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 7 / 14
  • Protection de Netfilter Il suffit d’utiliser la fonctionnalité rp_filter. Elle est disponible depuis le siècle dernier dans tout les noyaux Linux. Désactivée par défaut. Une vérification de routage pour chaque paquet est trop couteuse Activée par tous les scripts de filtrage décents Pour l’activer: echo " 1 " > / proc / sys / n e t / i p v 4 / c o n f / a l l / r p _ f i l t e r Hummmmm et pour IPv6 ? Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 7 / 14
  • Protection de Netfilter Il suffit d’utiliser la fonctionnalité rp_filter. Elle est disponible depuis le siècle dernier dans tout les noyaux Linux. Désactivée par défaut. Une vérification de routage pour chaque paquet est trop couteuse Activée par tous les scripts de filtrage décents Pour l’activer: echo " 1 " > / proc / sys / n e t / i p v 4 / c o n f / a l l / r p _ f i l t e r Hummmmm et pour IPv6 ? Trop facile, positionnons la valeur dans /proc: echo " 1 " > / proc / sys / n e t / i p v 6 / c o n f / a l l / r p _ f i l t e r / proc / sys / n e t / i p v 6 / c o n f / a l l / r p _ f i l t e r : No such f i l e o r d i r e c t o r y Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 7 / 14
  • Protection de Netfilter Il suffit d’utiliser la fonctionnalité rp_filter. Elle est disponible depuis le siècle dernier dans tout les noyaux Linux. Désactivée par défaut. Une vérification de routage pour chaque paquet est trop couteuse Activée par tous les scripts de filtrage décents Pour l’activer: echo " 1 " > / proc / sys / n e t / i p v 4 / c o n f / a l l / r p _ f i l t e r Hummmmm et pour IPv6 ? Trop facile, positionnons la valeur dans /proc: echo " 1 " > / proc / sys / n e t / i p v 6 / c o n f / a l l / r p _ f i l t e r / proc / sys / n e t / i p v 6 / c o n f / a l l / r p _ f i l t e r : No such f i l e o r d i r e c t o r y Okay, Houston, we’ve had a problem here. (Jack Swigert) Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 7 / 14
  • Phase 1 (mai 2011) : contacter les développeurs Envoi d’un mail à des membres de la Coreteam de Netfilter Ils reconnaissent le problème Des règles de filtrage manuelles permettent de prévenir l’attaque Nécessité de communiquer sur le sujet Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 8 / 14
  • Phase 2 (juin 2011)Prévenir les développeurs de frontend Les implémentations testées sont vulnérables en IPv6 Les développeurs sont très coopératifsPrévenir les gens du noyau La solution de protection manuelle est complexe à mettre en oeuvre Envoi d’un mail à security@kernel.org pour évoquer la nécessité de rp_filter pour IPv6 Réponse d’un des principaux développeurs : Security issues are just bugs, and we report bugs on the public mailing list and try to fix them. Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 9 / 14
  • Phase 3 (juin 2011) : proposer un patchUtilisation d’un code déjà proposé Code déjà proposé en 2006 par Denis Semmau Rebasé sur la branche net-next Eric Dumazet me signale que la RFC sur le sujet n’est pas respectée Je modifie le patch en conséquence et resoumetDavid Miller n’aime pas Mauvais pour les performances Ce type de sécurité doit être fait dans Netfilter Les détails: http://permalink.gmane.org/gmane.linux.network/197607 Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 10 / 14
  • Phase 5 (juin 2011) : contacter les CERTsUne attaque à prendre en compte Nécessité de protection sur les frontends Et sur les scripts maisons Une coordination de haut niveau semble parfaite Contacter de nombreux acteurs Faire des annonces suffisamment publiques pour attirer l’attentionLes CERTs refusent de traiter Le CERT français ne m’a même par répondu (malgré relance) Le CERT US a refusé de traiter Alors que l’attaque est générique et Que des pare-feu comme Checkpoint sont impactés en configuration par défaut Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 11 / 14
  • Phase 6 (aout 2011) : définition d’un plan d’actionPrésentation de l’attaque au Netfilter Workshop Présentation de l’étude sur les helpers Description de l’attaque Discussion ouverte sur les mesures à prendrePlan d’action Rédaction d’un document expliquant les contre-mesures: https://home.regit.org/netfilter-en/ secure-use-of-helpers/ Assistance à Florian Westphal pour son implémentation Ajout d’une option pour désactiver l’assignation automatique des helpers Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 12 / 14
  • Phase 7 : divulgationCansecWest (mars 2012) Description détaillée de l’attaque Annonce de la mise à disposition sur demande d’un outil de testsPrésentation au SSTIC (juin 2012) Description détaillée de l’attaque Mise à disposition publique de opensvp Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 13 / 14
  • Questions Avez-vous des questions ?Merci à Pablo Neira, Patrick McHardy: les développeurs noyaux peuvent être sympas. Florian Westphal: pour son implémentation Netfilter de RP filter.Plus d’information Mon blog : https://home.regit.org Secure use of Iptables and connection tracking helpers: http://home.regit.org/netfilter-en/secure-use-of-helpers/Me joindre Courriel: eric@regit.org Twitter: @Regiteric Éric Leblond (OISF) Histoire d’une faille de sécurité Kernel Recipes 2012 14 / 14