Les vulnérabilités open source ont piégé Equifax : comment vous en protéger ?

Equifax, géant de la surveillance du crédit, a révélé la semaine dernière avoir été victime d’une fuite de données, exposant des informations hautement personnelles concernant 143 millions de personnes, et a indiqué que la cause principale était une vulnérabilité dans Apache Struts, une bibliothèque Java très populaire. L’entreprise a mal géré sa réaction à l’attaque, et il lui incombe de protéger nos données. Toutefois, Equifax n’est certainement pas la seule entreprise exposée aux vulnérabilités de Struts ou d’autres bibliothèques open source.

Equifax a probablement été compromis par la vulnérabilité d’exécution de commandes à distance (RCE), facile à exploiter, divulguée en mars dernier, ou par la nouvelle vulnérabilité RCE de la semaine dernière, presque aussi grave. Malgré le bruit relativement important autour de ces problèmes, les utilisateurs de ces packages tardent énormément à y remédier.

Nous avons examiné près de 1 000 projets open source sur GitHub qui dépendent directement de Struts : 64 % sont encore vulnérables à la grave vulnérabilité de mars. Pratiquement tous sont vulnérables à la faille divulguée la semaine dernière. Par ailleurs, parmi les milliers de projets Java analysés par Snyk, 78 % étaient exposés à la vulnérabilité RCE de mars lors de leur première analyse, et 100 % étaient vulnérables au problème de la semaine dernière (nous avons ensuite alerté les utilisateurs et les avons aidés à corriger ces failles).

Le risque lié à ces vulnérabilités n’est pas théorique : elles représentent une menace réelle et immédiate. Après la divulgation de la vulnérabilité RCE de Struts en mars, nous avons constaté un nombre important et croissant d’attaques dans la nature, qui exploitent cette faille de sécurité connue et facile à exploiter. De même, la vulnérabilité divulguée la semaine dernière entraîne de grandes vagues d’attaques.

À qui la faute ?

Les fuites de données déclenchent souvent une série de renvois de responsabilité, chaque partie concernée essayant de rejeter la faute sur une autre. Malheureusement, la question de la responsabilité en matière de sécurité open source est complexe…

Dans ce cas, il est facile de rejeter la faute sur Apache Struts.

Au cours des dix dernières années, plus de 40 vulnérabilités d’Apache Struts ont été divulguées, y compris des vulnérabilités graves comme les failles RCE mentionnées plus haut. On pourrait en conclure que Struts est une bibliothèque peu sûre, mais c’est loin d’être le cas. Son équipe a en réalité réagi rapidement et de manière responsable aux problèmes détectés et, contrairement à de nombreux projets open source, a même pris la peine de rétroporter des correctifs importants vers des versions plus anciennes et moins maintenues du logiciel. Apache a publié une réponse bien rédigée sur l’incident Equifax.

Les développeurs d’Equifax, auteurs du portail compromis, sont les prochains à blâmer.

Ils ont choisi d’utiliser une bibliothèque open source tierce sans vérifier si elle comportait des vulnérabilités connues ni surveiller son état au fil du temps, ce qui a conduit au désastre. Ces développeurs sont effectivement responsables, car la création de logiciels sécurisés fait partie de leurs missions. Toutefois, il est important de se rappeler que les développeurs ne sont pas des experts en sécurité et que beaucoup ignorent les risques associés à l’utilisation d’une bibliothèque open source. De plus, dans les grandes organisations comme Equifax, les développeurs n’ont souvent pas les moyens de « sortir des sentiers battus » et d’assumer la responsabilité de tâches qui dépassent le cadre explicite de leur mandat.

Si l’on s’en tient aux responsabilités officielles, la faute incombe à l’équipe de sécurité d’Equifax.

C’est à elle qu’incombe officiellement la sécurité des systèmes, et elle a clairement échoué. Même s’il ne fait aucun doute qu’elle a failli à sa mission, si l’équipe de sécurité d’Equifax ressemble à toutes celles que j’ai pu voir, elle n’est probablement pas en mesure de sécuriser efficacement les applications de son entreprise. Les équipes de sécurité sont souvent en sous-effectif, avec un développeur pour 100, et ne peuvent tout simplement pas suivre le rythme du développement logiciel moderne, encore accéléré par ces bibliothèques open source. Si la sécurité repose uniquement sur l’équipe de sécurité, une faille majeure est quasiment inévitable.

Ce qui nous amène au dernier responsable de ce fiasco : l’équipe de direction d’Equifax.

Elle est moralement et légalement dépositaire de nos données personnelles, et décide des investissements consacrés à leur protection, même au détriment des bénéfices et de la croissance. Elle doit également veiller à ce que toute l’entreprise se sente concernée par la sécurité, au lieu d’en faire l’affaire d’une petite équipe. Enfin, elle doit comprendre que les pratiques de développement modernes, comme l’utilisation de bibliothèques open source, comportent de nouveaux risques qu’il faut bien gérer. Je n’ai aucune réserve quant à la responsabilité de la direction, si ce n’est qu’aucune organisation n’est à l’abri d’une faille et qu’un échec n’implique pas nécessairement une négligence ou une incompétence.

Comment éviter de devenir le prochain Equifax

Plutôt que de chercher un coupable, prenons un instant pour voir comment éviter à votre entreprise de figurer au palmarès des pires violations de sécurité. Voici quelques conseils pour vous protéger, dès maintenant et dans la durée.

1. Faites des tests. Analysez vos applications avec un outil de sécurité open source qui signale les bibliothèques open source vulnérables, notamment les failles RCE de Struts, et veillez à tester toutes vos applications.

2. Corrigez les problèmes détectés. Lever le voile sur les bibliothèques vulnérables est une première étape indispensable, mais si vous ne corrigez pas les problèmes détectés, vous restez tout aussi vulnérable. Ne vous contentez pas de consigner les vulnérabilités : faites-les corriger.

3. Surveillez les vulnérabilités des bibliothèques que vous utilisez. C’est une bonne chose de rechercher les bibliothèques vulnérables dès maintenant, mais de nouvelles vulnérabilités seront forcément découvertes demain, comme nous venons de le voir avec Struts. Configurez des alertes pour être informé des nouvelles vulnérabilités divulguées et pouvoir les corriger avant que les attaquants ne les exploitent.

4. Trouvez des outils de sécurité que les développeurs peuvent utiliser. Votre équipe de sécurité ne peut pas répondre à tous les besoins, et les développeurs n’attendent pas les mêmes choses de leurs outils que les spécialistes de la sécurité. Trouvez des outils de sécurité que les développeurs apprécieront et encouragez vos équipes de développement à les utiliser. Comme nous l’avons fait avec le DevOps, nous devons confier la sécurité à davantage de personnes (une approche souvent appelée DevSecOps).

Si vous ne savez pas par où commencer, lancez une analyse avec la CLI de Snyk ou son intégration GitHub. Je ne suis évidemment pas objectif en vous le conseillant, mais au minimum, l’offre gratuite de Snyk signalera les problèmes dans vos applications et vous aidera à commencer à les corriger. Si vous ne souhaitez pas utiliser Snyk, trouvez un autre outil, mais agissez avant que le problème ne vous explose au visage.

Le problème ne se limite pas à Struts

Enfin, soulignons que le problème ne concerne pas seulement Struts ni l’écosystème Java Maven. Le mois dernier, une vulnérabilité d’exécution de code arbitraire dans le package npm populaire de Node.js pg a été divulguée, ainsi qu’une vulnérabilité de cross-site scripting dans le framework Python django.

Le mois précédent, les vulnérabilités divulguées comprenaient une faille XSS dans Spark Core, une plateforme populaire de traitement des mégadonnées basée sur Java, et des dizaines de packages malveillants ont été découverts dans le registre npm. Des études réalisées plus tôt cette année montrent que 77 % des sites Web utilisent une bibliothèque JS vulnérable sur leur page d’accueil.

Les statistiques s’accumulent. En résumé, suivre et corriger les vulnérabilités de vos bibliothèques open source est indispensable pour toute organisation aujourd’hui ; la seule manière de vraiment résoudre le problème consiste à intégrer cette démarche à votre processus de développement. Si vous avez besoin de conseils pour vous lancer, écrivez-nous et nous vous aiderons à démarrer. Quoi que vous fassiez, tirez les leçons de l’erreur d’Equifax et ne baissez pas la garde.