Juniper : une backdoor made in NSA. récupérée par un tiers

Depuis que Juniper a révélé la présence d'une backdoor dans l'OS de ses firewall et solutions VPN NetScreen, les chercheurs tentent d'en décrypter l'origine. Et, selon eux, le morceau de « code non autorisé » que l'équipementier a confessé avoir trouvé dans ScreenOS, le système d'exploitation des pare-feu concernés, pourrait résulter à la fois de pratiques défaillantes de Juniper en matière de chiffrement et de modifications opérées par des tiers à l'identité mystérieuse.

Rappelons que le fournisseur a expliqué que ce code d'origine inconnu, découvert lors d'un audit, se traduisait par une possibilité de déchiffrement du trafic VPN et également par un accès pirate aux appareils concernés via un mot de passe maître codé en dur. Rien que ça. Juniper a proposé des correctifs pour les firmwares touchés par cette faille. Mais n'a pas publié de détails sur le code pirate mis au jour.

D'où la curiosité des experts. Après plusieurs jours de recherches (par ingénierie inverse sur les firmwares et les correctifs), ces derniers ont multiplié les découvertes. Mettant d'abord au jour le mot de passe codé en dur, qui, in fine, concerne un nombre plus limité de versions de ScreenOS qu'initialement annoncé, comme le montrent les recherches de Rapid7.

Un algorithme made in NSA

Mais la partie la plus intéressante des découvertes des chercheurs réside dans le volet chiffrement. Et Juniper n'en sort pas grandi. Selon Ralf-Philipp Weinmann, le fondateur de la firme de conseil allemande Comsecuris, l'équipementier américain utilisait un générateur de nombres aléatoires (Dual_EC_DRBG), dont les imperfections étaient connues, comme base des opérations de chiffrement sur ScreenOS. Standardisé par l'Institut américain des standards et technologies (le NIST) en 2007, Dual_EC doit beaucoup à son parrain, qui n'est autre que la NSA américaine. Une agence de renseignement qui a oeuvré à sa normalisation.

Dès 2007, deux chercheurs de Microsoft alertent la communauté sur la « présence possible d'une backdoor » au sein de Dual_EC. Ces deux experts, Dan Shumow et Neils Ferguson, montrent que le générateur de nombres aléatoires peut être détourné par un assaillant, pour créer des nombres qui ne sont plus de tout aléatoires, permettant dès lors audit assaillant de déchiffrer aisément les communications. Il suffit pour cela que l'attaquant en question parvienne à maîtriser une des constantes (Q) utilisée en entrée par l'algorithme. « La spécification NIST de Dual_EC intégrait une valeur par défaut de Q qui avait été générée par la NSA », écrit le cryptographe de l'université John Hopkins Matthew Green, dans un passionnant billet de blog. Bref, l'agence de Fort Meade a probablement volontairement pollué le standard qu'elle a ensuite poussé auprès du NIST. Une information qui ne surprendra pas les utilisateurs de BSafe de RSA, alertés en septembre 2013 des failles de l'outil en raison de la présence de Dual_EC en son sein.

Une backdoor récupérée sans vergogne

Donc Juniper (ou NetScreen, une société qu'il a racheté en 2004) a intégré à ScreenOS un composant affaibli, même si le constructeur a modifié la valeur Q par défaut (celle de la NSA) et a pris des mesures complémentaires (l'utilisation de deux générateurs de nombres aléatoires l'un derrière l'autre) qu'il pensait suffisantes pour en masquer les imperfections. Argument brandi en 2013 par le constructeur pour maintenir Dual_EC dans ScreenOS, suite aux alertes du NIST sur la sécurité de l'algorithme mise à mal par les révélations d'Edward Snowden. Sauf qu'un bug permettait en réalité de continuer à exploiter les failles de Dual_EC pour déchiffrer le trafic malgré la présence d'un second générateur de nombres aléatoires, comme le révèle le chercheur en sécurité Willem Pinckaers.

Mais l'histoire ne s'arrête pas et va « au-delà de l'imagination », selon les mots de Matthew Green. Car la valeur Q dans ScreenOS a été modifiée à posteriori, en 2012, par une organisation non identifiée, « probablement à une valeur que les hackers ont générée eux-mêmes », écrit Green. Ce qui leur a permis, ensuite, de déchiffrer facilement l'ensemble du trafic des VPN NetScreen. Le correctif de Juniper fait d'ailleurs figure d'aveu de la réalité de cette manipulation sans précédent, puisqu'il replace Q à la valeur choisie initialement par le constructeur !

Le résumé que fait le chercheur de cet épisode est sans concession pour le constructeur : « un hacker ou un groupe de hackers a remarqué la présence d'une backdoor dans le logiciel Juniper, qui a été placée là de façon intentionnelle ou pas - je vous en laisse juge. Ensuite, ces hackers ont tiré parti de cet existant pour bâtir leur propre backdoor, quelque chose qu'ils ont pu accomplir parce que le travail le plus ardu avait déjà été réalisé. Le résultat final, c'est une période de temps au cours de laquelle quelqu'un - probablement un gouvernement étranger - a été en mesure de déchiffrer le trafic Juniper aux Etats-Unis et dans le monde entier. »

Démonstration par l'absurde

En plein débat sur le chiffrement, la mésaventure de l'équipementier américain ressemble à une démonstration par l'absurde des dangers de l'introduction de backdoors dans les systèmes de chiffrement. Dans le contexte actuel de renforcement des mesures de sécurité - après les attentats de Paris et San Bernardino -, une telle solution est réclamée par la plupart des démocraties occidentales. La France y songe, la Grande-Bretagne discute d'un projet de loi qui le prévoit. Et les candidats à la présidence des Etats-Unis, tant Républicains que Démocrates, semblent s'accorder sur la nécessité d'introduire des portes dérobées dans les systèmes de chiffrement de bout en bout pour lutter contre le terrorisme. Sans parler de la Chine, qui doit aussi voter une loi allant dans ce sens.

Tombant à point nommé, l'exemple de Juniper montre les conséquences possibles de ce type de démarches. Comme le résume Matthew Green : « si l'altération du code n'a pas été autorisée par Juniper, il faut noter que l'assaillant n'a effectué aucun changement majeur du code des mécanismes de chiffrement. Il s'est contenté de changer des paramètres. » Et de récupérer une backdoor qui n'était pas créée à son intention mais qui lui a demandé bien peu d'efforts.

A lire aussi :

Apple prend la tête du combat contre les backdoors dans le chiffrement

Backdoor ou erreur de code dans les firewall de Juniper

Crédit photo : Carsten Reisinger / Shutterstock