J'ai bien fait d'attendre avant de relayer les backdoors découvertes dans certains pare-feux Juniper tellement c'est le merdier et tellement les articles de presse sont contradictoires et partiels. Il est intéressant de creuser la question car cette histoire va devenir un cas d'école pour expliquer pourquoi les backdoors sont une connerie monstrueuse qui sera présentée à tous les partisans d'un chiffrement déchiffrable par les autorités.
Pour une chronologie, voir
https://www.nextinpact.com/news/98011-juniper-se-debarrassera-code-developpe-par-nsa-dans-six-mois.htm
Dès 2007, la communauté se doute que l'algo de génération de nombres pseudoaléatoires Dual_EC_DRBG n'est pas top à cause d'une constante qui, si elle est connue, rend les nombres générés prévisibles et donc annule les garanties procurées par des opérations cryptographiques utilisant ces nombres.
En octobre 2008, Juniper introduit Dual_EC_DRBG dans ScreenOS 6.2.0r1 mais il choisit une constante différente de celle présentée dans les spécs du NIST. Juniper se croit protégé d'une backdoor extérieure, d'autant plus qu'il prétend chaîner un deuxième algorithme, ANSI X.9.31. Le problème, c'est que cette implémentation d'ANSI X.9.31 n'est jamais exécutée... (« Le meilleur backdoor est le backdoor qui a l’air d’être un bug » ;) , source :
http://www.numerama.com/tech/135974-la-faille-sur-les-routeurs-juniper-est-liee-a-la-nsa.html ).
C'est à la même époque que la nonce cryptographique passe de 20 octets à 32 octets... pile ce qu'il faut pour prédire le résultat de DUAL_EC...
Tout ça est utilisé pour le chiffrement des données dans les VPN IPSec. On note donc que la "backdoor" est bien présente, juste qu'elle est sous le contrôle de Juniper. Mais le trafic des VPN dont un équipement NetScreen de Juniper équipé de ScreenOS est l'une des extrémités, peut être déchiffré. Partenariat avec les services de renseignement ? Volontée de répondre aux réquisitions judiciaires/administratives ?
En septembre 2012, avec ScreenOS 6.2.0r15, la constante utilisée par Dual_EC_DRBG est modifiée par une entité inconnue (d'où Juniper parle de « code non autorisé »...). C'est à partir de ce moment-là qu'on peut dire que la backdoor a été récupérée... Elle sera découverte lors d'un audit interne en... décembre 2015 et corrigée dans ScreenOS 6.3.0r20. Quand je dis « corrigée », attention, la backdoor ne disparaît pas, la constante est juste remise à sa valeur de 2008. ;)
En 2013, Snowden nous démontre que la NSA a bien pourri l'algo Dual_EC_DRBG pour le proposer comme standard au NIST. Juniper affirme pourtant publiquement son choix de conserver Dual_EC_DRBG dans ScreenOS, persuadé que son chaînage d'algorithmes (Dual_EC_DRBG + ANSI X.9.31) est OK.
En avril 2014, avec ScreenOS 6.3.0r17, une backdoor est ajoutée dans SSH grâce à un mot de passe codé en dur dans le firmware et conçu pour resembler à des symboles de debug (« <<< %s(un='%s') = %u ») et donc échapper plus difficilement aux relectures de code. À ce moment-là, il est toujours possible de déchiffrer déloyalement le trafic d'un VPN, hein. On cumule donc la capacité de devenir root sur ces équipements Juniper + celle de déchiffrer le trafic VPN. Là aussi, Juniper parle de code non autorisé et le corrigera dans ScreenOS 6.3r20 en décembre 2015...
En décembre 2015, Juniper découvre le remplacement de la constante dans l'algo DUAL_EC et le mdp codé en dur pour SSH. La société commerciale vire le mdp SSH et remet la constante choisie en 2008... ... ... Avant de décider, début janvier 2016, de ne plus utiliser DUAL_EC et ANSI X.9.31 (voir
https://www.nextinpact.com/news/98011-juniper-se-debarrassera-code-developpe-par-nsa-dans-six-mois.htm ). La seule remarque que je retiendrai à ce sujet est celle de Laurent Chemla : « Le temps d'en écrire du plus discret » (source :
https://twitter.com/laurentchemla/status/686583880422395904 )
Et, en parallèle de tout ça, d'autres failles étaient connues de la NSA depuis 2011 et n'ont jamais été divulguées à Juniper pour correction mais elles ont été exploitées de manière certaine par le GCHQ (on ne peut rien affirmer pour la NSA) :
https://www.nextinpact.com/news/97838-juniper-nsa-connaissait-existence-13-failles-depuis-2011.htm .
Le mot de la fin (source :
http://www.silicon.fr/faille-juniper-une-backdoor-made-in-nsa-recuperee-par-une-organisation-inconnue-134484.html) :
« 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… »
Par ailleurs, une backdoor a été aussi découverte dans certains pare-feux fabriqués par Fortinet : là aussi, un mot de passe codé en dur donne un accès via SSH. Fortinet précise « As previously stated, this vulnerability is an unintentional consequence of a feature that was designed with the intent of providing seamless access from an authorized FortiManager to registered FortiGate devices. It is important to note, this is not a case of a malicious backdoor implemented to grant unauthorized user access. » Source :
http://arstechnica.com/security/2016/01/secret-ssh-backdoor-in-fortinet-hardware-found-in-more-products/ .
Ça me rappelle furieusement ce que disait Sid Blancher à propos les backdoors dans les routeurs D-Link vendus aux particuliers, sur le fait de ne jamais supposer de la malveillance là où on peut supposer de l'incompétence (volonté de simplifier la vie de l'utilisateur via un enregistrement automatique comme Fortinet, l'envie de simplifier la vie de sa hotline comme dans les routeurs domestiques, le besoin d'exécuter des tâches automatiques,...). Voir
http://sid.rstack.org/blog/index.php/595-backdoor-or-not-backdoor .
Enfin, j'ai entendu dire plusieurs fois que les pare-feux filtrants Netasq auraient eux aussi une backdoor et que ça justifierait leur certification ANSSI et leur usage fortement recommandé par des circulaires internes dans les laboratoires de recherche publics. Bruit de couloir à prendre avec des pincettes, bien entendu.