jeudi 24 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Faille de sécurité dans les protocoles IPSec

Posté par Arachne (page perso, ). Modéré le 13 mai 2005.
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.

> Lire la dépêche (23 commentaires, moyenne: 4,6).  

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

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

hu?

Posté par Krunch (Jabber id, page perso, ) le 13/05/2005 à 21:50. (lien). Évalué à 5.

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

--
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.

s/authentification/authentication/g

Posté par lasher () le 13/05/2005 à 22:27. (lien). Évalué à 4.

tout est dans le titre :)

Vive RNIS :p

Posté par smorico (page perso, ) le 14/05/2005 à 00:55. (lien). Évalué à 1.

Voilà pourquoi j'utilise toujours du numéris pour la liaison de sites distants !!!

Qui modère les news postées sur DLFP?

Posté par ouah (page perso, ) le 14/05/2005 à 01:35. (lien). É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.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.1173s (dont 0.0217 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.