Juniper supprime le backdoor Dual_EC, mais des questions demeurent

L’équipementier télécoms Juniper a annoncé vendredi dernier qu’il publierait d’ici la mi-2016 une mise à jour du système ScreenOS embarqué sur ses routeurs de la gamme NetScreen, pour mettre fin à une grave faille de sécurité dévoilée en décembre dernier. La mise à jour supprimera l’utilisation par Juniper de l’algorithme Dual_EC qui était toujours employé pour générer une clé de chiffrement, alors-même que l’algorithme était connu comme ayant une vulnérabilité conçue par la NSA pour déchiffrer les communications.

Mais l’annonce est loin d’écarter toutes les questions qui se posent sur le rôle joué par Juniper. Dans un premier temps, le concurrent de Cisco avait lui-même révélé avoir découvert du « code non autorisé » sur ses équipements NetScreen, qui permettait de modifier discrètement les paramètres d’un firewall ou de déchiffrer du contenu qui transitait par un VPN.

Juniper n’avait pas donné les détails de sa découverte et c’est finalement en analysant le premier patch fourni que des chercheurs en sécurité informatique ont découvert le pot aux roses.

Ils ont en effet découvert que pour générer des nombres aléatoires essentiels à une bonne cryptographie, Juniper utilisait toujours l’algorithme Dual_EC que l’on savait pourtant vulnérable depuis 2007. La formule mathématique poussée par la NSA permettait à celui qui disposait d’une constante secrète associée à une constante visible dans le code de deviner la suite « aléatoire » générée grâce à un simple extrait de 32 bits du message chiffré. Pour remédier au problème, Juniper avait soit-disant associé à Dual_EC un autre algorithme, ANSI X9.31 PRNG. Mais le code source aurait eu une « erreur » qui faisait que la fonction ANSI X9.31 PRNG présente dans le code n’était en fait jamais appelée, et que le nombre aléatoire dépendait donc toujours exclusivement de Dual_EC.

D’étranges coïncidences

Le fameux « code non autorisé » découvert par Juniper était une modification de la constante visible en clair dans le code, réalisée en 2012, sans doute par quelqu’un qui connaissait la constante secrète associée qui offre un backdoor pour déchiffrer les communications. Mais selon les chercheurs, lorsque Juniper a patché ScreenOS, l’équipementier aurait remis l’ancienne constante en place, mais n’aurait pas corrigé le bug qui faisait que ANSI X9.31 n’était jamais appelé. Il n’aurait donc pas supprimé le backdoor. Première curiosité.

Mais selon ThreadPost, les curiosités ne s’arrêtent pas là. Il a en effet été découvert que Dual_EC n’était pas utilisé par Juniper au moment où sa vulnérabilité a été révélée. Juniper utilisait exclusivement ANSI X9.31, jusqu’à ce que ScreenOS 6.2 soit lancé et qu’il « ajoute » Dual_EC. Sauf qu’il a été ajouté de telle manière qu’en réalité, en raison de l’étrange bug évoqué, il remplaçait de fait ANSI X9.31.

Par ailleurs, au moment de l’implémentation de Dual_EC, celle de ANSI X9.31 a été modifiée pour utiliser des paquets de 32 bits plutôt que 20 bits. Exactement la taille nécessaire pour prédire la clé utilisée.

Tout cela avait été réalisé exactement le même jour. Et Juniper ne s’en explique pas.