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 :)
[^] # Re: Qui se relit / relit les news qu'il n'aime pas sur DLFP
Posté par Cédric Blancher . En réponse à la dépêche Faille de sécurité dans les protocoles IPSec. É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 :)