Juniper se débarrassera du code développé par la NSA dans les six mois
Aucune accusation
Le 11 janvier 2016 à 16h16
6 min
Internet
Internet
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.
Juniper se débarrassera du code développé par la NSA dans les six mois
-
L'influence de la NSA
-
De troublants constats
-
Les deux générateurs seront supprimés de ScreenOS dans les six mois
-
Le doute autour de Juniper
Commentaires (32)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 11/01/2016 à 16h31
C’est bizarre, et cela me fait ben marrer , car à ces fameux experts sécurité qui trainent sur ce site, cela fait des mois (années ?) que je leur dit que leur “sécurité” ne tiens pas la route car le souci se trouve au niveau de la génération “aléatoire” des clefs de chiffrement (quand celles ci ne sont pas à dispos. des services ayant le droit d’en connaitre …)
JE vais plus loin que la news : le “génératoire” " /> des cpu est aussi exposé … allez on continue encore ?
Vous me faites bien marrer , allez sans rancune. A la prochaine.
Ah oui Filiol est un guignol hein ?
Le 12/01/2016 à 09h01
Le 12/01/2016 à 09h02
Le 12/01/2016 à 09h30
et allez, c’est reparti pour des débats passionnants (ou pas " />)
Je reconnais que le côté open source (n’évitant pas ces problèmes, il) permet de repérer et corriger de telles failles. Si un outil propriétaire (ou un OS) possède un code semblable, les chances de le repérer seraient bien moindre. (mais que ça soit propriétaire limiterait les risques extérieurs de bidouillage du code)
Le 12/01/2016 à 09h46
Le 12/01/2016 à 10h03
Le 12/01/2016 à 10h11
Le 12/01/2016 à 10h15
Titre putassier … et totalement faux !
Certes Dual_EC est très probablement backdooré par la NSA, mais le code dans juniper n’est très certainement pas développé par la NSA… C’est quand même extrêmement tiré par les cheveux !
“””
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
“””
Cette phrase est extrêmement mal formulée. Le principal changement est que 32 octets fuitent publiquement (dans le nonce IKE en effet), ce qui rend (pour la personne qui a les clés de la backdoor) possible la récupération de l’état du RNG et donc celle de la clé de chiffrement.
Le 12/01/2016 à 10h38
Je n’ai jamais dit que des composants n’existaient pas…. ce que je dis c’est que ces architectures devaient etre proposées de bout en bout de facon packagée en Europe.
quand à l’Allemagne, rien n’empêche d’avoir des composants communs et de s’espionner….. c’est juste une question d’echelle…
Merci pour tes insultes… la grande classe
Le 12/01/2016 à 10h39
rien n’empêche de s’espionner le s uns les autres et d’ailleurs j’imagine que la France fait de même…. notre cher gouvernement espionne même les anciens présidents Français….
Mais rien n’empêche de développer des architectures communes, et l’open source est un garant de notre sécurité….
Le 12/01/2016 à 11h03
Le 12/01/2016 à 12h55
Le 12/01/2016 à 13h54
OMG z/OS je vais peut-être devoir m’y mettre l’année prochaine…
Le 12/01/2016 à 14h09
T’inquiètes pas ça fait 30 ou 40 ans que c’est supposé disparaitre " />
Le 12/01/2016 à 15h13
J’ai toujours fait du Linux et un poil d’HP-UX jusqu’à présent. J’ai un peu peur de m’enfermer là-dedans. " />
Le 12/01/2016 à 16h00
“Insultes” le mot est un peu fort mais passons.
Je maintiens ce que je dis, ni l’open source ni le propriétaire ne sont sûrs alors partager du code entre pays de l’UE alors qu’il n’y a pas la moindre confiance entre eux ça ne me semble pas être la solution.
Le 11/01/2016 à 16h31
J’aurais au moins appris que le terme “nonce cryptographique” existait et sa définition. Merci NXI :)
Le 11/01/2016 à 16h32
Tous ces systèmes critiques doivent faire l’objet de développements spécifiques par l’Europe et être distribués en open source….
Il n’y a pas d’autres alternatives pour préserver nos intérêts
Le 11/01/2016 à 17h18
AlphaBeta quel est le rapport entre ce que tu dis et la news ? Juniper est une société privée qui propose une gamme très large de produits réseaux, queceque vient faire l’Europe la dedans ?
Le 11/01/2016 à 17h42
C’est moi qui aie mal compris, ou alors il vaut mieux pas être pressé ?
Le 11/01/2016 à 18h11
@pmiam999
Cisco > juniper > USA
les interets des USA ne sont pas les Notres
par contre .. mettre en opensource peut aider a lever le voile
seulement encore une fois il n’y a qu’en europe qu’un logiciel ne peut etre breveté
donc certains preferent garder tout ca en interne, pour garder un avantage concurrentiel
le temps de dev depenser par certains vs ceux qui arriveraient la bouche en coeur pour profiter du travail des autres > les boites ne se font pas de cadeaux (ex : apple samsung toussa)
et puis s’il mettaient en opensource rien n’empeche qui que ce soit de placer du code “malveillant”
ex * le code aleatoire ne l’etait pas forcement et les lignes de codes injectées permettaient une analyse predictive des clefs tout ca sous le nez des equipes de dev (j’ai oublié le nom du logiciel je me demande si ce n’est pas truecrypt >.<>
Le 11/01/2016 à 18h20
On pourrait déjà commencer par exploiter du alcatel ou nokia pour le réseau, et penser à Linux pour les OS…
Après le closed-source n’empêche pas les audits. Et puis Microsoft a bien montré le code de Windows à la demande du gouvernement chinois.
Le 11/01/2016 à 18h28
mettre le code en open-source permettrai au boites de faire leurs propres correctifs de bugs sans avoir a attendre que juniper se sorte les doigts, voire même proposer des pull-requests afin que juniper corrige ses problèmes plus rapidement.
La communauté pourrais même lancer des audits en parallèle, ce qui donnerai au final (si juniper joue le jeu et est réactif aux corrections) une meilleure image sur la sécurité et la fiabilité de leur logiciels.
Le 11/01/2016 à 18h31
A noter que ScreenOS est un “vieil” OS et qu’il est depuis longtemps mis sur le côté par Juniper au profit de JunOS, supposé unifier tous les équipements vendus par la firme sous le même OS de base.
Le 11/01/2016 à 18h45
Le 11/01/2016 à 22h02
“Dans 6 mois” = “Le temps que la NSA nous fournisse le nouveau code”. " />
Le 12/01/2016 à 00h46
Le 12/01/2016 à 07h13
Ils vont prendre le code de la CIA, il est mieux.
Le 12/01/2016 à 07h38
OpenSSL et HeartBleed ça te parle ? C’est la merde en Open Source et ailleurs.
Quant a ton argument sur l’Europe il ne vaut pas un kopeck, l’Allemagne a mis Fabius sur écoute et on fait surement pareil. C’est un hors sujet des plus majestueux.
Le 12/01/2016 à 07h48
C’est pas la couche TCP/IP qui possede une faille dementielle qui n’a jamais été corrigée ? (ca doit au moins daté de dix ans si ma memoire est bonne). Alors tout le reste…
Le 12/01/2016 à 08h25
Le 12/01/2016 à 09h00