Faille de sécurité dans les protocoles IPSec

Posté par . Modéré par Christophe Guilloux.
Tags :
0
13
mai
2005
Sécurité
Des chercheurs anglais ont découvert une grave faille de sécurité dans les protocole IPSec, utilisés pour le cryptage des paquets dans les réseaux VPN.

Cette faille concerne les tunnels IPSec ESP (Encapsulating Security Payload) et certaines configurations utilisant AH (Authentification Header), et permet à l'attaquant de récupérer en clair le contenu d'un paquet qui ne lui est pas destiné par un message d'erreur ICMP. Elle est considérée comme grave, et cible potentiellement un grand nombre de réseaux d'entreprise.

Des solutions sont d'ors et déjà disponibles, mais elles imposent la modification de la configuration du VPN. IPSec est composé de trois protocoles :

- Authentification Header, qui garantit l'authenticité des paquets grâce à des checksums cryptés.

- Encapsulating Security Payload, qui garantit la confidentialité des paquets en les cryptant. Il peut aussi les authentifier.

- Internet Key Exchange, qui permet d'échanger les clefs de manière sécurisée

Les deux premiers protocoles fonctionnent soit en mode transport, soit en mode tunnel. C'est le deuxième cas qui est concerné par la faille. Sans vérification d'intégrité, l'attaquant peut modifier le contenu des données des paquets cryptés, altérant leur header afin de forcer la passerelle ou le poste qui reçoit et décrypte le paquet à renvoyer alors un message d'erreur ICMP qui contient le paquet original, non crypté. L'attaquant peut alors récupérer le paquet qui l'intéresse en sniffant le réseau et prendre connaissance de son contenu.

Trois méthodes différentes ont été découvertes pour obtenir ce résultat : la modification de l'IP de destination, des options IP, ou du protocole.

Afin de se protéger, trois solutions existent :

- configurer IPSec pour vérifier l'authenticité ET l'intégrité des paquets dans un tunnel ESP (solution recommandée)

- Utiliser HA avec ESP pour vérifier l'intégrité des paquets (attention certains configurations sont encore vulnérables)

- Empêcher l'envoi de message ICMP

Aller plus loin

  • # hu?

    Posté par (page perso) . Évalué à 5.

    Qui chiffre sans faire de vérification d'intégrité ?

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: hu?

      Posté par . Évalué à 7.

      Ça me parait bizarre également... mais comme la norme, à ma connaissance, ne force pas à combiner vérification d'intégrité et chiffrement (pour les machines de faibles puissance qui veulent économiser du temps CPU par exemple), l'ensemble des implémentations est potentiellement touché. Maintenant, la plupart des configurations desquelles j'ai entendu parler combinent les deux.

      DISCLAIMER : ces informations ne sont pas vérifiées. Quiconque de compétent est invité à les corriger si besoin. Toute personne se sentant énervée par ces paroles honteusement fausses est invitée à faire le poirier.
      • [^] # Re: hu?

        Posté par (page perso) . Évalué à 5.

        Si j'ai bien compris le premier lien, ça vient du problème de l'utilisation d'un protocole en clair utilisant des feedbacks d'erreurs via ICMP (donc en clair), erreurs générées par un man-in-the-middle effectuant des changements légers dans la charge chiffrée affectant seulement l'en-tête du paquet chiffré, modification rendue possible par le chiffrage CBC [1], assurant la confidentialité mais apparemment pas l'intégrité, aux dernières nouvelles...

        [1] : http://en.wikipedia.org/wiki/Cipher_Block_Chaining(...)
      • [^] # Re: hu?

        Posté par (page perso) . Évalué à 9.

        Apparement Openswan n'est pas vulnérable puisqu'il ne laisse pas l'utilisateur configurer une connexion chiffrée aussi mal. http://www.openswan.org/niscc/(...)

        La faille des P4 avec Hyperthreading est plus intéressante (oui je sais je ferais mieux de rédiger une dépèche plutôt que de râler). https://linuxfr.org/~patrick_g/18131.html(...)

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: hu?

      Posté par . Évalué à 4.

      Personne de sensé, mais effectivement, la norme ne l'empeche pas, puisque la seule chose "illégale" est null_enc+non_auth.

      A coté de ca, quelle implémentation sensée ne confronte pas un paquet déchiffré à sa policy IPSec ?

      Nan, je préfère ne pas avoir les réponses, ca pourrait me déprimer...


      A +

      VANHU.
  • # s/authentification/authentication/g

    Posté par . Évalué à 4.

    tout est dans le titre :)
    • [^] # Re: s/authentification/authentication/g

      Posté par (page perso) . Évalué à 5.

      Je crois qu'on peut/doit remplacer (dé)crypter par (dé)chiffrer un peu partout.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: s/authentification/authentication/g

        Posté par (page perso) . Évalué à 6.

        "Crypter" n'existe pas (à l'origine), bon maintenant c'est dans le dico, grâce à Canal+... le bon terme est chiffrer.

        Par contre, décrypter existe et consiste à réaliser justement de la cryptanalyse pour casser un message chiffré sans connaître le secret de chiffrement.

        Déchiffrer est l'opération inverse de chiffrer quand on dispose de la clef de (dé)chiffrement adéquate.
    • [^] # Re: s/authentification/authentication/g

      Posté par . Évalué à 6.

      Euh, le moinssage je m'en fous, mais vous savez que j'ai raison hein ? En Anglais, "Authentification" n'existe pas. Alors quand je vois un sigle mal retranscrit, désolé de vouloir rectifier...
      • [^] # Re: s/authentification/authentication/g

        Posté par . Évalué à 2.

        bah, c pour ca que t'es moinssé. On aime pas les gens qu'ont raison, ici. Si tu tiens à faire de vieux os dans l'patelin, t'as interret à te tenir à careaux, et a avoir tort comme tout le monde. Non mais.
      • [^] # Re: s/authentification/authentication/g

        Posté par . Évalué à 4.

        Je pertinente.

        J'ai souvenir d'avoir passé 10 heures stressantes à debugguer une configuration IPsec dont le seul problème était, finalement, un simple "Authentification" (au lieu d''Authentication") dans la description de la phase 1 d'isakmpd.conf.

        C'est pas toujours facile à repérer et ça peut faire du grabuge !
    • [^] # Re: s/authentification/authentication/g

      Posté par . Évalué à 3.

      Allez, on va aussi corriger le français :

      >> Des solutions sont d'ors et déjà disponibles

      => Des solutions sont d'ores et déjà disponibles
  • # Vive RNIS :p

    Posté par . Évalué à 1.

    Voilà pourquoi j'utilise toujours du numéris pour la liaison de sites distants !!!
    • [^] # Re: Vive RNIS :p

      Posté par . Évalué à 5.

      Oui c'est une réaction spontanée désolé, je comprend le moinsage....

      Ce que je veux dire, c'est que je fait bien plus confiance à un réseau téléphonique qui repose sur des commutateur...

      Je veux dire qu'en numeris c'est une liaison téléphonique qui est initialement établie.

      (Il y a ensuite une autentification chap (ppp puis tcp/ip).... Il est aussi possible s'utiliser IPSec....)

      La on a une liaison IP et certains routeur et protocoles de routages sont sensible à des attaques type Man in the Middle (ICMP redirect (echo "0" > /proc/sys/net/ipv4/conf/nom_interface/accept_redirects !!), attaques sur BGP, MBGP etc...). Meme si elle sont trés complexes à mettre en oeuvre (BGP), ces attaques restent possibles !

      Je crains qu'un jour il y ait une news sur linuxfr : "faiblesse dans l'implementation d'IPSec" ou "un chercheur australien met au point un algorithme qui permet de factoriser des entiers en un temps record".....

      Faire reposer la sécurité sur la cryptographie n'est pas LA solution à mon avis (mais un plus)...
      • [^] # Re: Vive RNIS :p

        Posté par (page perso) . Évalué à 1.

        Ca c'est sur, ca doit etre extrement compliquer de sniffer une liaison telephonique vu que les cables sont super securisés et totalement inaccessibles ....
        • [^] # Re: Vive RNIS :p

          Posté par . Évalué à 2.

          Je parle bien sur d'attaques distantes...
          C'est sur que sur ce principe, tu peut toujours rentrer dans l'établissement et piquer le disque dur du serveur....
          • [^] # Re: Vive RNIS :p

            Posté par . Évalué à 3.

            entre ouvrir une armoire telephonique sur une route publique vers 4h du mat; brancher un sniffeur et la refermer (bon faut s'y connaitre mais c'est faisable sans trop de problème) , et devoir montrer patte blanche allez jusqu'a la salle des serveur ; devoir a nouveau montrer patte blanche etc... on choisis quelle solution?
  • # Qui modère les news postées sur DLFP?

    Posté par (page perso) . Évalué à 10.

    Ce n'est pas du tout une nouvelle faille: le fait que si on désactive l'authentification avec IPSec, on peut casser complètement la sécurité avec une attaque active de type Man-In-The-Middle est connue depuis longtemps.

    Le problème c'est que quelqu'un pose un advisory pour se faire de la pub et c'est repris par tous les journalistes qui ne connaissent rien de yahoo news à news.com, et enfin ça finit sur DLFP.

    Steve M. Bellovin a écrit un article nommé "Problem areas for the IP Security Protocols" qui décrit ces problèmes SI ON DESACTIVE L'AUTHENTIFICATION DES PAQUETS et qui est paru déjà il y a quelques années .

    Le fait que ce soit possible de désactiver l'auth n'implique pas qu'IPSec soit cassé, cela peut être intéressant lorsque l'on essaye de debugger lors d'un premier déploiement d'IPSec qui ne passe pas (oui ce n'est pas toujours évident), comme c'est le cas par exemple pour l'utilité des clés manuelles.

    Ce sont des problèmes bien connus, pour plusieurs protocoles et si on ne les utilises pas dans les règles il faut s'attendre à de mauvaises surprises.

    Pour ceux qui ne seraient pas d'accord avec cet avis: j'annonce ici avoir cassé le protocole SSH: si vous vous connectez à un serveur SSH sans avoir au préalable installé sa clé publique ou avoir vérifié son empreinte, vous cassez complètement le protocole avec un Man-In-The-Middle. Soit dit-en passant, c'est l'utilisation faite par 90% des gens et c'est complètement vulnérable.

    Enfin, cela pour montrer qu'il n'y a pas à s'affoler, que cette news n'apporte rien de nouveau et que son seul mérite est de faire comprendre aux gens que désactiver l'auth c'est mal et que les développeurs de solutions IPSec devraient empêcher de désactiver l'auth comme cela est le cas par exemple pour OpenVPN.
    • [^] # Re: Qui modère les news postées sur DLFP?

      Posté par . Évalué à 5.

      Effectivement c'est une mauvaise utilisation d'IPSec qui rend cette attaque possible. Cependant, malgré le fait que les tunnels que j'ai mis en place vérifient l'intégrité et l'authenticité de ses paquets, je ne me rendais pas compte du danger de ne pas vérifier l'intégrité. Cette mise en évidence a un double intérêt : rappeler que désactiver les tests d'intégrité est un mauvaise idée, comme tu le dis, et aussi souligner la faiblesse de la surcouche des protocoles IPSec, qui doivent prendre en compte les caractéristiques de TCP/IP, en l'occurence l'envoi de message ICMP avec les données en clair en cas d'erreur.

      A mon humble avis, c'est dans le design même d'IPSec qu'il y a un problème, il ne devrait pas permettre ce mode de fonctionnement. Et ton exemple ne me contredit pas, il ajoute juste que ssh souffre lui aussi d'un problème de sécurité, seulement, lui, il indique par un message clair et bien voyant que c'est risqué :

      arachne@wyrm:~ $ ssh debian.org
      The authenticity of host 'debian.org (192.25.206.10)' can't be established.
      RSA key fingerprint is 9f:f8:46:ea:84:6e:f0:8f:04:e9:01:98:9e:e1:2e:23.
      Are you sure you want to continue connecting (yes/no)?
    • [^] # Re: Qui modère les news postées sur DLFP?

      Posté par (page perso) . Évalué à 3.

      à la dernière phrase il faut lire Openswan et non OpenVPN
    • [^] # Qui se relit / relit les news qu'il n'aime pas sur DLFP

      Posté par (page perso) . Évalué à 2.

      Hum a lire la news on parle la de cassage d'un IPsec avec authentification mais sans verification d'intégrité ce qui n'est pas toutafais la meme chose, non ?
      • [^] # Re: Qui se relit / relit les news qu'il n'aime pas sur DLFP

        Posté par . Évalué à 9.

        Hum a lire la news on parle la de cassage d'un IPsec avec authentification mais sans verification d'intégrité


        De ce que j'ai compris, la news est partiellement fausse, parce qu'elle reprend pas mal d'interprétations erronées de l'advisory.

        On peut lire dans la news :

        Cette faille concerne les tunnels IPSec ESP (Encapsulating Security Payload) et certaines configurations utilisant AH (Authentification Header)

        Si on utilise AH, on n'est pas vulnérable, et si on utilisant la partie intégrité/authentification de ESP non plus. C'est dans la partie "Solution" de l'avis.

        Tout se joue en fait sur le terme de "authentication".

        Dans IPSEC, tu as l'authentification en phase 1 pour la mise en place du tunnel, et qui est toujours présente. Ce n'est pas de cela qu'il est question. Il s'agit ici de l'ajout de données d'authentification _et_ de vérification d'intégrité sous forme de somme HMAC (hash avec secret partagé pour faire rapide). Ces données peuvent être incluses dans ESP pour vérifier le payload chiffré et/ou sous forme distincte pour vérifier le paquet IPSEC complet, et ça s'appelle AH.

        Ces deux mécanismes (très similaires mais à la portée différente) permettent justement d'éviter les modifications du payload ESP et donc de rendre cette attaque inopérante.

        permet à l'attaquant de récupérer en clair le contenu d'un paquet qui ne lui est pas destiné par un message d'erreur ICMP

        Ceci n'est pas tout à fait exact non plus. Le truc, c'est qu'on peut (s'il n'y a pas de vérification d'intégrité dans ESP ou avec AH), modifier le payload ESP par bit flipping, ce qui permet en particulier d'altérer l'entête du paquet chiffré (contenu dans le payload ESP) pour obtenir sa redirection directe (routage, attaque 1) ou indirecte (erreur ICMP, attaques 2 et 3). L'advisory cite en particulier 3 attaques :

        . modification de l'adresses destination qui entraîne la redirection du paquet après déchiffrement par simple routage. Cela dépend de la configuration du filtrage sur le concentrateur VPN, mais c'est très plausible. C'est d'ailleurs à mon sens la seule des trois qui se tient.

        . 2 attaques par modification de la source et injection d'une erreur dans l'entête IP pour entraîner l'émission d'un ICMP vers la source modifiée. On cite la modification des options IP pour obtenir un Parameter Problem et la modification du champ Protocol pour obtenir un Protocol Unreachable, mais finallement, la plupart des erreurs ICMP feront l'affaire (TTL exceeded par exemple). Là encore, ça dépend de la configuration du concentrateur, mais surtout, ça ne donne la plupart du temps pas le paquet IP ! En effet, une erreur ICMP ne contient que l'entête du paquet IP qui l'a généré, plus les 8 octets suivant (ce qui nous amène, dans le cas de TCP, aux ports source et destination et au numéro de séquence). C'est très clairement expliqué dans la RFC 792 (voir format des messages Parameter problem et Destination unreachable). Certaines implémentations incluent plus, mais elles sont rares...

        Bref, cet advisory fait l'objet de pas mal d'articles assez faux quant à son contenu et ses conséquences, que je trouve d'ailleurs un poil exagérées (les trucs ICMP en particulier). Il traite d'un sujet qu'on connaissait déjà (cf. post de Ouah), même si c'est de bon ton de rappeler ce genre de trucs de temps en temps, et ce n'est pas une surprise. Si certains s'interroger sur la nécessité d'activer le HMAC sans ESP, ben maintenant, ils savent.

        En ce moment, c'est la mode de la "redécouverte". On nous a servi le même truc avec les DoS TCP par injection de RST, déjà remonté l'an dernier (et déjà une redécouverte) et tout récemment avec les DoS par construction d'erreur ICMP. Les habitués des IRC Wars connaissent bien les "Click4.exe like" qui faisaient déjà ça en 1997 :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.