Juniper se débarrassera du code développé par la NSA dans les six mois

Peu avant Noël, Juniper révélait que ses pare-feux NetScreen étaient touchées par une porte dérobée. L’origine exacte n’est pas connue, mais les soupçons s’orientaient vers la NSA. L’équipementier vient d’ailleurs d’annoncer qu’un composant lié à l’agence de renseignement allait être supprimé.

Fin décembre, on apprenait que tous les pare-feux NetScreen étaient touchés par une porte dérobée, dont l’origine demeure mystérieuse. Juniper avait publié un bulletin de sécurité expliquant le problème, donnant les versions concernées du système d’exploitation ScreenOS. D’après ces versions, on savait d’ailleurs que la porte dérobée avait théoriquement pu être exploitée pendant au moins deux ans.

Cette exploitation donnait à ceux qui connaissaient l’adresse de la porte un accès complet aux données et la possibilité de décrypter facilement ce qui transitait. Ce problème de sécurité a rapidement attiré les feux des projecteurs, tant Juniper fournit ses équipements à de grandes entreprises et administration. En outre, la possibilité que la brèche ait pu être exploitée si longtemps faisait craindre le pire sur les données qui avaient pu être récupérées, car il était impossible de savoir ce qui avait été fait durant ce temps.

L'influence de la NSA

Mais la question qui reste évidemment en suspens concerne les auteurs de cette attaque. Les regards se sont tournés rapidement vers la NSA, tant l’agence de renseignement est désormais connue pour son travail à deux visages sur la sécurité des réseaux. Car si d’un côté elle participe pleinement à l’élaboration de certains protocoles de sécurité (tous ceux dont les ingénieurs espèrent qu’ils pourraient être utilisés dans les administrations), elle collecte activement les failles de sécurité 0-day – donc sans correctif – en vue de les utiliser comme autant d’armes dans une cyberguerre de l’ombre. Un véritable arsenal numérique sur lequel l’agence avait d’ailleurs communiqué en décembre, indiquant que 91 % des failles faisaient l’objet d’une communication auprès des éditeurs concerné pour qu’elles soient corrigées.

Les soupçons pesaient sur la NSA car ScreenOS se sert, entre autres, d’un générateur de nombres aléatoires bien connu de certains chercheurs pour le chiffrement des données et développé par l'agence : Dual_EC. Juniper avait cependant indiqué peu après que le problème ne pouvait pas venir de ce composant car non seulement l’implémentation du générateur était faite de manière sécurisée, mais il n’était surtout pas le seul générateur à être utilisé. Et pourtant…

De troublants constats

Des résultats de recherches présentés la semaine dernière à l’occasion de la Real World Cryptography Conference 2016 ont montré que la situation n’était pas aussi simple que ça. Ils ont fait deux constats curieux. D’une part, s’il existe bien un autre générateur dans ScreenOS, les résultats partiellement prévisibles de Dual_EC sont bien utilisés, plutôt que ceux d’ANSI X.9.31. D’autre part, un changement dans le code en 2008 a modifié le nonce cryptographique (nombre utilisé pour signer un ensemble de données), passant sa taille de 20 à 32 octets or, d’après les chercheurs, le caractère prévisible des résultats donnés par Dual_EC se reflète bien plus dans une taille plus importante.

Ces deux constats, même si importants, ne sont pas les seuls. Les chercheurs ont ainsi documenté deux autres changements. Le premier date de 2012 et concerne une constante mathématique. Selon eux, l’auteur de cette modification savait ce qu’il faisait en mettant en place un contexte favorable à l’espionnage. La seconde concerne un point abordé en décembre : apparue en 2014, il s’agit de la porte dérobée qui pouvait conduire tout possesseur de la clé à décrypter les communications. Cette dernière a été mise en évidence par HD Moore, directeur de la recherche chez Rapid7.

Les deux générateurs seront supprimés de ScreenOS dans les six mois

Que ces éléments aient été intégrés ou pas dans la réflexion de Juniper sur ses produits, l’équipementier a décidé vendredi de se débarrasser complètement des générateurs Dual_EC et ANSI X.9.31. Il indique qu’une analyse complète du code de ses systèmes ScreenOS et Junos OS a mis en évidence d’autres éléments à changer. Cet audit fait dire à l’entreprise qu’il n’existe cependant aucun autre code non autorisé dans ScreenOS, et qu’aucun problème particulier n’a été trouvé dans Junos OS.

Décision a donc été prise de remplacer les deux anciens générateurs de nombres aléatoires durant le premier semestre de cette année. Il n’existe pour l’instant aucune date précise, mais Juniper indique quand même que les générateurs de Junos OS (on ne sait pas lesquels) seront utilisés en remplacement. Une importante nouvelle version de ScreenOS sera alors déployée pour renforcer la sécurité générale des pare-feux concernés. En attendant, Juniper estime que les modifications apportées dans le patch de décembre sont suffisantes pour garantir la sécurité des produits, la porte dérobée ayant évidemment été supprimée.

Le doute autour de Juniper

Pour autant, même si les informations affluent et que l’équipementier travaille à fortifier ses pare-feux, la question des auteurs reste en suspens. Quelles que soient les réponses qui pourraient être apportées sur ce point, elles seraient probablement embarrassantes pour Juniper. Les modifications se sont étalées sur des années et proviennent soit de l’intérieur, soit de l’extérieur. L’augmentation du nonce cryptographique de 20 à 32 octets semble être en tout cas une décision interne, jetant le doute évidemment sur les raisons d’un tel changement, comme expliqué par le chercheur Stephen Checkoway à Wired vendredi dernier.