Problème dans l'implémentation IKE par le client de Checkpoint "SecuRemote"
Date : 28 Juin 2005
Introduction :
Checkpoint Firewall-1 est la solution pare-feu de Checkpoint.
Checkpoint SecuRemote est la partie cliente de la solution VPN (Virtual Private Network) de Checkpoint. La sécurité sur cette partie cliente peut aussi être améliorée en utilisant SecureClient qui inclut un pare-feu personnel.
Le protocole IKE (Internet Key Exchange), anciennement connu sous le nom ISAKMP/Oakley, permet de gérer dynamiquement les paramètres nécessaires au fonctionnement des équipements IPsec. Il est utilisé en particulier pour l'échange de clés authentifié et la gestion des associations de sécurité.
Ce protocole est plutôt complexe et possède beaucoup d'options et de modes de fonctionnement qui permettent de répondre à différents types de besoins. Parmi ces différents modes, le mode aggressif ("Aggressive Mode") est le mode le plus "simple" (par opposition au "Main Mode"), pour gérer l'échange de clés.
Présentation du problème :
Deux vulnérabilités ont été découvertes dans les clients VPN-1 SecuRemote de Checkpoint, lorsqu'ils sont utilisés avec le protocole IKE en mode aggressif.
· 1ère vulnérabilité :
Lorsque le pare-feu reçoit un nom utilisateur, dans un paquet IKE en mode agressif, il va répondre de manière différente selon que ce nom utilisateur est valide ou non, et ceci sans que le mot de passe ait été fourni. Ceci permet à un attaquant distant de deviner les noms utilisateur valides en effectuant des essais systématiques (ou via un dictionnaire d'attaque).
Ce type de comportement (donner des informations sur la validité d'une authentification avant que toutes les données clientes aient été soumises) est contraire aux standards de sécurité. Le pare-feu devrait attendre d'avoir reçu le nom utilisateur ET le mot de passe (même si ce nom d'utilisateur est invalide), pour éventuellement refuser les données d'authentification en bloc.
· 2ème vulnérabilité :
La deuxième vulnérabilité vient du fait que les noms utilisateur sont passés en clair entre le pare-feu et les clients VPN (toujours lorsque IKE est utilisé en mode aggressif). Cette vulnérabilité permet à un attaquant capable d'écouter le trafic réseau entre ces deux équipements (un utilisateur du réseau local de l'entreprise), de récupérer les noms utilisateur en clair.
Solution :
Selon Checkpoint, ces vulnérabilités sont liées au protocole IKE lui-même, et non à l'implémentation de Checkpoint. Dans la mesure où la faiblesse est intrinsèque à la norme, nous avons décidé de ne pas émettre d'avis Cert-IST sur les produits Checkpoint, et de publier plutôt cette information au niveau du bulletin.
Dans la cas de Checkpoint, l'éditeur propose, à partir de sa gamme NG ("Next Generation"), un protocole hybride, permettant de résoudre ces problèmes.
Il est donc recommandé de privilégier ce mode hybride, au détriment du mode agressif d'IKE plus facile d'utilisation.
Pour plus d'information :
- Article de NTA : http://www.nta-monitor.com/news/checkpoint.htm
- Article des Nouvelles.net : http://www.lesnouvelles.net/afficher.php?id=306
- Archives de Bugtraq :
