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
- NISCC Vulnerability Advisory IPSEC - 004033 (67 clics)
- La news chez Yahoo (31 clics)
# hu?
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: hu?
Posté par bmc . Évalué à 7.
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 François Becker (site web personnel) . Évalué à 5.
[1] : http://en.wikipedia.org/wiki/Cipher_Block_Chaining(...)
[^] # Re: hu?
Posté par Krunch (site web personnel) . Évalué à 9.
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 Vanhu . Évalué à 4.
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 lasher . Évalué à 4.
[^] # Re: s/authentification/authentication/g
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: s/authentification/authentication/g
Posté par Mathieu Millet (site web personnel) . Évalué à 6.
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 lasher . Évalué à 6.
[^] # Re: s/authentification/authentication/g
Posté par boris . Évalué à 2.
[^] # Re: s/authentification/authentication/g
Posté par herodiade . Évalué à 4.
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 frayd . Évalué à 3.
>> Des solutions sont d'ors et déjà disponibles
=> Des solutions sont d'ores et déjà disponibles
# Vive RNIS :p
Posté par smorico . Évalué à 1.
[^] # Re: Vive RNIS :p
Posté par smorico . Évalué à 5.
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 -=[ silmaril ]=- (site web personnel) . Évalué à 1.
[^] # Re: Vive RNIS :p
Posté par smorico . Évalué à 2.
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 briaeros007 . Évalué à 3.
# Qui modère les news postées sur DLFP?
Posté par ouah (site web personnel) . Évalué à 10.
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 Arachne . Évalué à 5.
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 ouah (site web personnel) . Évalué à 3.
[^] # Qui se relit / relit les news qu'il n'aime pas sur DLFP
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
[^] # Re: Qui se relit / relit les news qu'il n'aime pas sur DLFP
Posté par Cédric Blancher . Évalué à 9.
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 :)
[^] # Re: Qui se relit / relit les news qu'il n'aime pas sur DLFP
Posté par Cédric Blancher . Évalué à 2.
Des trucs comme celle sur l'Hyperthreading[1] (pas de dépèche pour celle là ?) ou le Firewire[2] me semblent nettement plus intéressantes, ne serait-ce que parce qu'elles sont détaillées.
[1] Colin Percival, cf. http://www.daemonology.net/hyperthreading-considered-harmful/(...)
[2] Maximillian Dornseif, cf. http://cansecwest.com/resources.html(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.