Backdoor et NSA : de lourds soupçons pèsent sur Juniper
Juniper va (enfin) retirer l’algorithme à l’origine de la backdoor dont souffre l’OS de ses équipements Netscreen. Mais une nouvelle étude soulève des questions sur le jeu trouble joué par l’équipementier avec ce générateur de nombres aléatoires promu par la NSA.
Juniper Networks, qui a piteusement du avouer l’existence d’un code non autorisé dans ScreenOS (l’OS des firewalls et solutions VPN de marque NetScreen), a annoncé son intention de retirer, au cours du premier semestre 2016, le générateur de nombres aléatoires Dual_EC_DRBG de ses produits. C’est en effet ce générateur qui est à l’origine de la grave faille de sécurité – la possibilité de déchiffrer à la volée du trafic VPN – qui a touché les produits animés par ScreenOS.
Pour bien comprendre cette affaire, un rappel historique s’impose. Standardisé par l’Institut américain des standards et technologies (le NIST) en 2007, Dual_EC_DRBG doit beaucoup à son parrain, la NSA américaine. Dès la fin 2007, deux chercheurs de Microsoft alertent la communauté sur la « présence possible d’une backdoor » au sein du générateur. Ces deux experts, Dan Shumow et Neils Ferguson, montrent que l’algorithme peut être détourné par un assaillant, pour créer des nombres qui ne sont plus de tout aléatoires. Il suffit pour cela que l’attaquant en question parvienne à maîtriser une des constantes (Q) utilisée en entrée par l’algorithme. En 2013, les documents exfiltrés par le lanceur d’alerte Edward Snowden relancent l’affaire, en établissant que la NSA a volontairement affaibli le standard, y introduisant une backdoor. Tout simplement une valeur par défaut de Q choisie par l’agence lui ouvrant les portes d’un déchiffrement à la volée des communications ‘sécurisées’ par le générateur Dual_EC_DRBG.
Deux algorithmes ? Juniper avait tout faux
La confirmation des faiblesses intrinsèques de l’algorithme pousse alors un éditeur comme RSA à avertir ses utilisateurs des failles de Dual_EC_DRBG, leur recommandant d’exploiter un autre générateur de nombres aléatoires. Juniper, lui, reste de marbre. Officiellement, la société américaine explique alors qu’elle utilise deux générateurs de nombres aléatoires, l’un derrière l’autre (Dual_EC_DRBG puis ANSI X.9.31), dans ScreenOS. Donc que les failles du premier sont sans danger, puisque le second suffit à les gommer.
L’édifice s’effondre fin décembre dernier. Un chercheur en sécurité, Willem Pinckaers, révèle qu’un bug dans l’implémentation de cette chaîne permet en réalité de continuer à exploiter les failles du générateur de nombres made in NSA. Et, en réalité, ce bug n’était pas isolé. Un nouveau travail de recherche présenté à la conférence Real World Cryptography (du 6 au 8 janvier, à Stanford) montre que ScreenOS utilisait des nombres aléatoires issus de Dual_EC_DRBG trop longs pour bénéficier de la sécurité offerte théoriquement par ANSI X.9.31. Autrement dit, en dehors même de tout bug d’implémentation, la structure imaginée par Juniper était intrinsèquement bancale. Selon les chercheurs, l’incapacité de ANSI X.9.31 à gommer les failles de Dual_EC_DRBG résulte d’un changement de code opéré en 2008 (modifiant la taille du nonce cryptographique). Rappelons que Juniper a racheté Netscreen quatre ans plus tôt.
Une backdoor intentionnelle ?
Une première modification qui pose question car la taille du nonce choisie par Juniper (32 bits) n’est pas habituelle avec Dual_EC_DRBG, qui génère seulement 30 bits de données (et non 32). La société a donc du mettre en œuvre une implémentation très spécifique pour porter le nonce à 32 bits (contre 20 auparavant). Plus troublant encore, selon Stephen Checkoway, professeur d’informatique à l’Université de l’Illinois à Chicago qui a participé à cette nouvelle étude, Juniper a ajouté le générateur contrôlé par la NSA après avoir implémenté ANSI ! Et non l’inverse, ce qui aurait pu montrer la volonté de l’équipementier de sécuriser Dual_EC_DRBG, qu’il savait imparfait, avec un second générateur.
Selon Stephen Checkoway, qui a analysé 48 versions du firmware Netscreen, l’apparition de Dual_EC_DRBG remonte à la version 6.2.0. Tandis que l’algorithme ANSI X9.31 était présent avant. Wired note que la date de sortie de cette version 6.2 n’est pas très claire (octobre 2008 pour la date du fichier, mars 2009 pour la note annonçant la disponibilité de la mise à jour), mais qu’elle est de toute façon postérieure aux premières alertes concernant la sécurité de Dual_EC_DRBG, datant d’une conférence qui s’est tenue en août 2007. D’où la question que lance Stephen Checkoway : pourquoi Juniper a-t-il ajouté à ScreenOS un générateur de nombres aléatoires qu’il savait être imparfait, alors que son firmware utilisait déjà un autre générateur, réputé plus sûr ? D’autant que Dual_EC_DRBG présente une autre lacune : il est plus lent que d’autres générateurs comme ANSI X9.31. Donc il a du pénaliser les performances de ScreenOS. Conclusion pour le chercheur : ce sont les modifications opérées sur cette version 6.2.0 qui ont ouvert la porte au déchiffrement à la volée du trafic VPN. « Si cette backdoor n’était pas intentionnelle, il s’agit d’un concours de circonstances formidable », ajoute le chercheur, qui ne se fait visiblement aucune illusion.
Qui a volé ma backdoor ?
Les chercheurs à l’origine de l’étude détaillent par ailleurs deux autres modifications du code, ayant affaibli la sécurité des firewall Netscreen. La première remonte à 2012 et aboutit à changer la constante Q fixée dans la spécification NIST de Dual_EC_DRBG. La seconde date de 2014 et permet à quiconque est en possession d’un mot de passe codé en dur (une des autres faiblesses de ScreenOS confessée par Juniper mi-décembre) de déchiffrer les communications.
Rappelons que, fin décembre, les travaux cumulés de plusieurs chercheurs – notamment H.D. Moore de Rapid7, Ralf Philipp Weinmann et Willem Pinckaers – ont déjà permis de montrer qu’une des failles que renfermait ScreenOS avait été réexploitée, à partir de 2012, par une organisation non identifiée. Un scénario rocambolesque : cette organisation a utilisé la backdoor présente dans le firmware des équipements Netscreen pour modifier la valeur de Q, ce qui lui a permis de récupérer la faille à son profit. Le tout sans effort démesuré, comme l’avait souligné fin décembre Matthew Green, un cryptographe de l’université John Hopkins.
Le premier patch proposé par Juniper le mois dernier se contentait de replacer la valeur Q à sa valeur d’avant la modification opérée en 2012, repérée tant par les chercheurs en décembre et confirmée pdébut janvier ar l’étude de l’Université de Chicago. Face au tollé, l’équipementier a donc décidé d’aller plus loin : le nouveau correctif qu’il apportera dans ScreenOS 6.3 remplacera les générateurs de nombres aléatoires de l’OS (Dual_EC_DRBG et ANSI X.9.31) par ceux utilisés dans l’autre OS de la firme, JuneOS. La société assure par ailleurs avoir mandaté une société spécialisée (et non identifiée) pour auditer le code des deux OS. « Il n’y a aucune preuve d’un autre code non autorisé dans ScreenOS, écrit le responsable de la sécurité de l’équipementier dans un billet de blog. Pas plus qu’il n’existe de preuve d’un quelconque code non autorisé dans JuneOS. L’enquête a aussi confirmé qu’il serait bien plus difficile d’insérer le même type de code non autorisé dans JuneOS. » Juniper ajoute poursuivre ses investigations pour identifier l’organisation qui a, en 2012, détourné la backdoor présente dans ScreenOS à son profit. Pas sûr que cet effort, qui a peu de chances d’aboutir à une conclusion claire, suffise à restaurer son crédit dans les milieux de la cybersécurité.
A lire aussi :
Juniper : une backdoor made in NSA… récupérée par une organisation inconnue
Apple prend la tête du combat contre les backdoors dans le chiffrement
