Connexion
Abonnez-vous

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

Aucune accusation

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

Le 11 janvier 2016 à 16h16

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.

juniper

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.

Commentaires (32)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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” <img data-src=" /> 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 ?

votre avatar







Ksyl a écrit :



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.





Justement, la faille a été découverte par une tierce société, et corrigé dans la foulée. Avec un code proprio, peut-être qu’on ne l’aurait toujours pas trouvée.


votre avatar







Huron a écrit :



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…





Si tu avais une source ca serait pas mal, non pas que je n’y crois pas, mais là çà fait sérieusement FUD quand même…


votre avatar

et allez, c’est reparti pour des débats passionnants (ou pas <img data-src=" />)



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)

votre avatar







lysbleu a écrit :



Justement, la faille a été découverte par une tierce société, et corrigé dans la foulée. Avec un code proprio, peut-être qu’on ne l’aurait toujours pas trouvée.





Découvert par Google si ma mémoire est bonne et exploitée durant des années avant d’être révélée. De plus l’origine de la faille était volontaire également. Et c’est cette envergure qui a fait que cette faille a obtenu un nom, un logo aussi, tellement c’était grave.

&nbsp;





CryoGen a écrit :



Il y a une différence entre faille involontaire et porte dérobée aussi…

Et puis en cas de développement Européen, on peut espérer avoir un peu plus de maitrise que sur tu matos américain ou chinois… Ca n’empêchera pas forcément les mises sur écoutes, mais si déjà ca peut réduire la surface d’attaque, c’est déjà çà de pris. Et puis faire fonctionner l’IT en Europe à plein régime pourrait créer des emplois aussi.





Involontaire c’est faux. N’essayez pas de me faire croire qu’avec tous les utilisateurs et contributeurs il n’y en a pas un qui&nbsp; ai signalé la faille. Comme par hasard, c’était le seul morceau de code que personne n’a passé en revue.

Ok pour l’IT en Europe par contre.


votre avatar







Ksyl a écrit :



Découvert par Google si ma mémoire est bonne et exploitée durant des années avant d’être révélée. De plus l’origine de la faille était volontaire également. Et c’est cette envergure qui a fait que cette faille a obtenu un nom, un logo aussi, tellement c’était grave.





Non la faille n’était pas volontaire, elle a été introduite par le thésard qui a codé l’implémentation du protocole heartbeat, l’erreur de programmation a toujours été là et la review du code ne l’a pas détectée parce que c’est difficile de tout détecter. Elle aurait été exploitée par la NSA, mais cette supposition est faite pour toutes les failles (et peut-être vraie pour une grande partie d’entre elles), et quelques mois avant sa révélation certaines attaques l’utilisait. Mais des failles sont présentes dans tout code informatique, propriétaire ou open source.


votre avatar







Ksyl a écrit :



Découvert par Google si ma mémoire est bonne et exploitée durant des années avant d’être révélée. De plus l’origine de la faille était volontaire également. Et c’est cette envergure qui a fait que cette faille a obtenu un nom, un logo aussi, tellement c’était grave.

 



Involontaire c’est faux. N’essayez pas de me faire croire qu’avec tous les utilisateurs et contributeurs il n’y en a pas un qui  ai signalé la faille. Comme par hasard, c’était le seul morceau de code que personne n’a passé en revue.

Ok pour l’IT en Europe par contre.







Exploitée durant des années ? Je ne crois pas. Ce qui n’enlève rien à sa présence et dangerosité. Tout le monde sait qu’il y a un problème avec le code de openssl, et non personne n’avait vu le problème sinon il aurait été remonté ! Il y a les bug tracker tout de même. Et puis si tu trouves une faille dans openssl, je veux bien croire que tu ne veuilles pas trop ébruiter le problème pendant un temps et communiquer avec les dev “en privé” histoire de limiter les risques d’exploitation… mais si au bout de quelques mois rien est fait tu peux être sur que tu vas commencer à publier des informations (sans pour autant donner la procédure exacte <img data-src=" />) . Ne serait ce que pour ta publicité…


votre avatar

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&nbsp;(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.



&nbsp;

votre avatar

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

votre avatar

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….

&nbsp;

Mais rien n’empêche de développer des architectures communes, et l’open source est un garant de notre sécurité….

votre avatar







MuadJC a écrit :



et allez, c’est reparti pour des débats passionnants (ou pas <img data-src=" />)



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)







Passionant ou pas <img data-src=" />



Ce qui serait assez sain aussi c’est de regarder aussi dans le passé car parfois cela nous apprend des trucs



IBM qui fournissait les sources de son OS propriétaire (à l’époque MVT puis MVS ) se retrouvait avec des modifs faites par les clients ( les banques, les assurances les hopitaux les ministères etc …)

Si cela amenait la possibilité de réparer certains bugs assez rapidement, cela permettait aussi d’ajouter des fonctionalités que certains pensaient utiles .

C’est alors qu’IBM amena le principe OCO ( Object Code Only) c’est à dire en clair ils ne fournissaient plus les sources.

Hurlements dans tous les sites ! Sauf que les clients ne voyaient que leur côté et pas ce qui était arrivé:



Les changements de versions devenaient presque un cauchemar car ils ne reconduisaient pas les dizaines de patch temporaires ou modifs ou fonctions, et surtout la maintenance devenait un cauchemar (les centres de support trouvaient du code étranger dans les dumps et à part être devin c’était presque impossible à debugger)



Ce fut la seule raison de la suppression de la fourniture des sources.



Aujourd’hui l’OS descendant de MVS ( z/OS) présent partout est compatible depuis 40 ans ( c’est à dire du code écrit au CNRS ou chez Tartempion à Pétaouchnok, continue de tourner sur un OS 64 bits d’aujourd’hui et la maintenance et les migrations sont tout à fait standards.



Avoir les sources c’est bien mais ce n’est pas nécessairement LA solution .



votre avatar







Ksyl a écrit :



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.





C’est tout à fait dans le sujet au contraire, la NSA faisant de l’espionnage industriel.

Même si les pays d’Europe ne sont pas à proprement parler en guerre avec d’autres grandes puissances, ils sont en guerre économique avec les Américains, les Russes et les Chinois.

Airbus/Boeing en est un exemple.


votre avatar

OMG z/OS je vais peut-être devoir m’y mettre l’année prochaine…

votre avatar

T’inquiètes pas ça fait 30 ou 40 ans que c’est supposé disparaitre <img data-src=" />

votre avatar

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. <img data-src=" />

votre avatar

“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.

votre avatar

J’aurais au moins appris que le terme “nonce cryptographique” existait et sa définition. Merci NXI :)

votre avatar

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

votre avatar

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 ?

votre avatar

C’est moi qui aie mal compris, ou alors il vaut mieux pas être pressé ?

votre avatar

@pmiam999

Cisco &gt; juniper &gt; 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 &gt; 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 &gt;.&lt;&gt;

votre avatar

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.

votre avatar

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.

votre avatar

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.

votre avatar







AlphaBeta a écrit :



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

&nbsp;





Pas de l’Europe, mais par chaque pays de l’Europe, l’exemple récent de l’espionnage allemand montre qu’il faut se méfier de tout et de tous.

Quant à Juniper on peut très sérieusement douter de leur bonne foi.


votre avatar

“Dans 6 mois” = “Le temps que la NSA nous fournisse le nouveau code”. <img data-src=" />

votre avatar







servalx a écrit :



Pas de l’Europe, mais par chaque pays de l’Europe, l’exemple récent de l’espionnage allemand montre qu’il faut se méfier de tout et de tous.

Quant à Juniper on peut très sérieusement douter de leur bonne foi.





À partir du moment où c’est opensource, chaque pays peut effectuer son propre audit du code. Ça revient moins cher que de développer chacun ses propres logiciels.


votre avatar

Ils vont prendre le code de la CIA, il est mieux.

votre avatar

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.

votre avatar

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…&nbsp;

votre avatar







Abused a écrit :



@pmiam999

Cisco &gt; juniper &gt; 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é









Tu peux m’expliquer ce que le brevet logiciel a avoir la dedans je suis vachement curieux du genre de reflexion qui t’anime XD

Genre le brevet logiciel aurait empecher ce genre de mésaventure <img data-src=" />


votre avatar







Ksyl a écrit :



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.







Il y a une différence entre faille involontaire et porte dérobée aussi…

Et puis en cas de développement Européen, on peut espérer avoir un peu plus de maitrise que sur tu matos américain ou chinois… Ca n’empêchera pas forcément les mises sur écoutes, mais si déjà ca peut réduire la surface d’attaque, c’est déjà çà de pris. Et puis faire fonctionner l’IT en Europe à plein régime pourrait créer des emplois aussi.


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

Fermer