Porte dérobée dans les pare-feu NetScreen : Juniper publie un correctif, Cisco lance un audit

L’ensemble des équipements réseau de Juniper dédiés aux pare-feu est affecté par l’ajout d’un code dont l’origine semble inconnue. La société a publié un correctif pour retirer cette extension potentiellement très dangereuse : elle permettait un accès complet dès lors que l’on possédait le bon mot de passe. Les soupçons s’orientent vers la NSA.

L’histoire pourrait à la fois illustrer les pires craintes nées dans le sillage des révélations d’Edward Snowden et les problèmes potentiels exprimés par tous ceux qui luttent contre l’idée des portes dérobées dans les logiciels. Juniper, équipementier réseau bien connu, a en effet découvert qu’un code avait été ajouté à son insu dans ses produits destinés à la protection des réseaux, plus particulièrement dans ses pare-feu. Ce code permet, dès lors que l’on peut s’y connecter avec le bon mot de passe, d’examiner avec soin tout ce qui transite par ces équipements, le tout à distance.

De nombreuses versions de ScreenOS concernées

La société a avoué jeudi dernier dans un communiqué qu’à l’occasion d’une révision interne du code, des lignes supplémentaires avaient été trouvées. La société n’a aucune idée de l’identité de l’auteur, mais elle indique que le code permet un accès à l’ensemble des produits NetScreen avec des droits administrateurs et un déchiffrement de l’ensemble des connexions VPN. Dans la foulée, l’entreprise a publié un correctif pour toutes les versions concernées de son système ScreenOS. Dans une mise à jour du communiqué datant de dimanche, elle précise d’ailleurs qu’en fonction du type de danger, les versions concernées ne sont pas les mêmes :

• Accès administrateur : versions 6.3.0r17 à 6.3.0r20 de ScreenOS
• Déchiffrement des connexions VPN : versions 6.2.0r15 à 6.2.0r18 et 6.3.0r12 à 6.3.0r20 de ScreenOS

On remarque donc que les connexions VPN sont en danger sur un nombre bien plus important de versions. Dans tous les cas, les administrateurs sont invités à mettre les équipements à jour aussi rapidement que possible. La situation est particulièrement dangereuse pour les entreprises concernées, ce qui explique la publication hors-cycle du correctif. Par ailleurs, les brèches constatées ne concernent que les produits utilisant ScreenOS, ceux basés sur SRX par exemple étant hors de danger. Juniper ne donne par contre aucune explication sur la manière dont une telle injection a pu se produire.

Une véritable porte dérobée

Pour autant, il est difficile de parler de brèche de sécurité au sens propre, dans la mesure où le code introduit résulte d’une volonté clairement affichée de mettre en place une porte dérobée. Un constat très important pour l’analyse de la situation car il pose évidemment la question de l’auteur de cet ajout, mais également des conséquences de telles ouvertures volontaires. Alors que le sujet revient sans cesse sur le tapis au vu d’une augmentation des pratiques de chiffrement, les dangers inhérents à ce type de pratique apparaissent d’autant plus clairement.

Le code ajouté dans les produits Juniper permettait en effet d’analyser tout le trafic réseau si l’on savait où chercher la porte d’entrée, mais également si on possédait le bon mot de passe. Or, des chercheurs ont pu le trouver en seulement trois jours, en analysant les différences entre la version mise à jour de ScreenOS et la précédente. Cet important travail montre encore une fois qu’une porte dérobée peut être non seulement trouvée, mais qu’un peu de travail suffit pour en trouver la clé. On rejoint ici les propos de Tim Cook, PDG d’Apple, sur les portes dérobées : « Si vous mettez en place une telle porte, alors elle est pour tout le monde, pour les gentils comme pour les méchants ».

D’autre part, Juniper avait indiqué qu’il était extrêmement difficile de savoir qui avait accédé aux équipements durant la période de validité de cette porte dérobée. Et cette période est d’au moins deux ans puisque les premières versions touchées datent de 2013. Conséquence, les auteurs de la brèche peuvent avoir accédé aux données durant un temps prolongé, pour une somme de dégâts pratiquement impossible à évaluer. Ce qui n’empêche pas les chercheurs d’avoir proposé un ensemble de règles à mettre en place pour détecter toutes les connexions réalisées au moyen de SSH et les inscrire dans un journal. Évidemment, cela ne sera d’aucun secours pour les connexions réalisées dans le passé.

Les regards se tournent vers la NSA

Quant à l’auteur de cette attaque, les signes pointent vers une responsabilité partielle et indirecte de la NSA. C’est l’avis du chercheur Ralf-Philipp Weinmann, PDG de la société allemande Comsecuris : toute l’opération serait basée sur une porte dérobée placée par la NSA et dont les caractéristiques - tout comme les objectifs - auraient été modifiées par les pirates, quels qu’ils soient. La porte dérobée initiale figure en fait dans le générateur de nombres aléatoires Dual_EC, approuvé par la NSA, et utilisé par Juniper dans ses pare-feu pour chiffrer les données.

Toutefois, toujours selon Weinmann, l’ensemble n’aurait peut-être pas été possible sans une erreur réalisée par Juniper, sans préciser laquelle. Il est également d’avis que le problème aurait probablement pu être détecté plus tôt puisque la méthode utilisée pour mettre en évidence le souci dans Dual_EC était déjà connue par la communauté de la sécurité en 2007. Il estime en outre que le correctif publié par Juniper ne corrige pas complètement le problème. Notez cependant que dans une note séparée, Juniper indique que l’origine de la faille ne peut pas être dans Dual_EC car il n’est « pas utilisé en tant que générateur principal de nombres aléatoires ». En outre, l’entreprise assure que l’implémentation de Dual_EC est faite de manière sécurisée et qu’une telle faille n’aurait pas pu être exploitée.

Par ailleurs, la situation a suffisamment eu d'échos pour provoquer une réaction chez Cisco. Dans un billet de blog publié lundi, le constructeur y annonçait le lancement d'un audit de sécurité pour vérifier à nouveau l'intégralité du code dans certains de ses produits. Il indique également avoir agi de sa propre initiative et ne pas avoir été (encore ?) contacté par les forces de l'ordre pour le cas Juniper.

Un cas d'école

En résumé, plusieurs éléments restent actuellement auréolés de mystère, notamment l’origine exacte de cette attaque visiblement très bien orchestrée. Les soupçons s’orientent volontiers vers un partenaire proche des États-Unis, comme le Royaume-Uni ou Israël, mais cette explication ne convainc pas tout le monde. Sur CNN par exemple, plusieurs membres officiels du gouvernement américain ont indiqué, sous couvert d’anonymat, que non seulement le renseignement n’était probablement pas à l’origine de l’attaque, mais que le FBI avait démarré une enquête à ce sujet.

Dans tous les cas, et outre l’aspect critique de ce trou béant laissé par l’attaque contre les pare-feu de Juniper, la situation illustre les dangers inhérents à l’utilisation des portes dérobées. On imagine que ce cas d’école sera utilisé par tous les défenseurs du chiffrement comme une démonstration parfaite des risques encourus : quel que soit le degré de complexité de la porte mise en place, elle pourra être utilisée par tout le monde une fois découverte.