Selon des consultants en sécurité, Firewall-1 souffre de deux failles d’une simplicité incroyable : sur Internet, il facilite la vie aux pirates qui cherchent à deviner un nom d’utilisateur valable, et du côté de l’entreprise, il véhicule les login du VPN en clair. L’éditeur, lui, trouve tout cela plutôt exagéré.

Pour la société NTA, il s’agit de failles idiotes et dangereuses. Pour Checkpoint c’est beaucoup de bruit pour rien. Mais qu’il s’agisse de véritables failles ou simplement d’ »oublis » embarrassants, les problèmes découverts par NTA sont méconnus des administrateurs et peuvent parfaitement compromettre un firewall. La première faille permet d’essayer librement, depuis l’extérieur, une infinité de noms d’utilisateurs pour se connecter au pare-feu. Et cela sans avoir à fournir un quelconque mot de passe !Il a été possible à NTA de tester 10.050 noms d’utilisateurs en deux minutes trente, soit 67 essais à la seconde. A chaque fois, le firewall a répondu servilement si le login proposé correspondait à un utilisateur connu ou pas.Ce comportement aberrant survient lorsque l’authentification est assurée sur le firewall en mode IKE (Internet Key Exchange) dit « agressif ». Et c’est là que commence le dialogue de sourds : Checkpoint affirme que c’est un problème lié au protocole IKE, et non au produit. L’éditeur indique que ce mode n’est pas activé par défaut dans sa gamme NG (Next Generation), justement à cause de ses faiblesses. Il affirme conseiller depuis toujours d’utiliser un mode d’authentification hybride, plus sûr. Ce à quoi NTA répond que, de toute façon, la majorité des FW-1 déployés le sont en mode IKE Agressif (plus simple à mettre en oeuvre), et sont donc vulnérables.La seconde faille découverte par le consultant touche l’autre côté du pare-feu, sur le réseau local de l’entreprise ou sa DMZ.Elle concerne elle aussi le mode d’authentification IKE « Agressif » : VPN-1 laisse dans ces conditions passer les noms d’utilisateurs en clair. Il ne s’agit cette fois-ci plus de devinettes, mais de noms bien valides exploitables par quiconque dans l’entreprise veut bien les écouter grâce à un sniffer (un mouchard chargé de capturer le trafic sur une portion du réseau).Là encore, la réponse de Checkpoint est claire : il s’agit du comportement normal de ce protocole, et l’éditeur n’a fait que l’implémenter correctement. Les entreprises n’ont qu’à utiliser une méthode plus sûre.Et là encore, NTA rétorque qu’elles ne le font pas, parce que les autres méthodes sont moins accessibles et plus compliquées à mettre en place.Il semblerait finalement que tout le monde ait raison dans ce dialogue de sourds. Checkpoint n’est pas responsable de la méthode d’authentification choisie par ses clients. Après tout, dans le monde des systèmes d’exploitation, tout le monde convient que Telnet est à proscrire, mais l’outil est présent sur tous les systèmes sans que personne ne vienne crier à la faille de sécurité. Il suffit de ne pas l’utiliser. C’est une question de responsabilité de l’administrateur (certains diraient d’éveil…)En revanche, on peut se poser la question de savoir pourquoi l’éditeur continue à proposer une méthode d’authentification aussi peu sûre. IKE n’est pas un standard historique du calibre de Telnet ou SNMP, et on peut faire sans. Mais cela rendrait l’installation des produits plus délicate, ce qui n’est pas bon d’un point de vue commercial. Surtout si l’on peut rejeter la faute sur un protocole étranger.

Vous avez aimé cet article?

Cliquez sur le bouton J'AIME ou partagez le avec vos amis!

Participez!

 Laisser un commentaire