Comment Atlassian a utilisé Snyk pour résoudre Log4Shell

Snyk a récemment lancé avec AWS une série de hackathons en direct sur plusieurs jours, au cours desquels des experts ont présenté des exploits en temps réel et expliqué comment se protéger contre ces vulnérabilités. Cette série a aidé les spectateurs à découvrir de nouvelles façons de renforcer la sécurité de l’ensemble de la pile applicative pour les workloads AWS.

Dans le cadre de cette série, Micah Silverman (directeur des relations avec les développeurs chez Snyk) et Chris Walz (ingénieur sécurité senior chez Atlassian) ont parlé de Log4Shell. Pour ceux qui ne connaissent pas cette vulnérabilité, Log4Shell était une faille zero-day très répandue dans la bibliothèque Java omniprésente Log4j. Nous proposons une vaste bibliothèque de ressources sur Log4j chez Snyk si vous souhaitez en savoir plus sur cette vulnérabilité.

Dans cet article, nous revenons sur l’expérience de Walz avec Snyk pour détecter et corriger Log4Shell chez Atlassian, ainsi que sur la présentation plus approfondie de Silverman consacrée à l’impact de Log4Shell.

Comment Atlassian utilise Snyk pour renforcer sa sécurité à grande échelle

Atlassian compte des milliers de dépôts et de services dans toute l’entreprise. Il n’est donc pas réaliste de les analyser un par un. C’est pourquoi l’équipe sécurité d’Atlassian a créé une automatisation qui lance des analyses Snyk Open Source à chaque modification du code dans un dépôt.

En outre, l’automatisation récupère les résultats des analyses de Snyk et crée des tickets Jira pour chaque problème de sécurité. Ces tickets sont attribués au développeur qui a soumis la modification de code et contiennent un lien vers le dépôt ainsi que des conseils pratiques pour résoudre le problème. Une fois le problème corrigé, le ticket est automatiquement clôturé.

« Nous avons un projet Jira utilisé dans toute l’entreprise pour toutes les vulnérabilités de sécurité. Cela améliore la visibilité, permet de mettre en place des automatisations autour de ce projet [et] garantit le respect des SLO. »

Résoudre Log4Shell chez Atlassian

En décembre 2021, la fondation Apache a annoncé la découverte d’une vulnérabilité critique dans la bibliothèque Log4j, qui sera ensuite baptisée Log4Shell. Atlassian a immédiatement lancé une enquête de sécurité pour déterminer si l’entreprise utilisait des versions vulnérables de Log4j, évaluer la gravité de l’impact sur les produits concernés et définir les mesures à prendre pour corriger Log4Shell.

« C’était à peu près le pire scénario possible en matière de problèmes liés aux dépendances de bibliothèques. Nous utilisons beaucoup Java chez Atlassian : le problème était donc très grave, et nous avons immédiatement lancé une enquête de sécurité. »

L’équipe de Walz savait que Snyk pouvait l’aider à identifier les projets qui utilisaient Log4j, mais son automatisation ne s’exécutait qu’en cas de modification du code. Il lui fallait donc des informations à jour. Comme la vulnérabilité Log4Shell venait tout juste d’être ajoutée à la base de données des vulnérabilités de Snyk, Atlassian a écrit un script pour relancer rapidement l’analyse de tous ses projets et détecter les instances vulnérables de Log4j.

Une fois que l’équipe sécurité a eu la certitude que toutes les données sur les vulnérabilités étaient à jour, elle a lancé manuellement la deuxième partie de son automatisation : la synchronisation avec Jira. Celle-ci a automatiquement envoyé 1 426 tickets Jira concernant des vulnérabilités Log4j aux développeurs concernés, afin qu’ils puissent les corriger rapidement.

« Ces tickets Jira ont été créés automatiquement, sans que l’équipe de sécurité ait eu à intervenir. Dans les 12 heures suivant l’annonce initiale, toutes les personnes qui utilisaient une version vulnérable de Log4j avaient reçu un ticket leur demandant de la mettre à jour. »

L’impact de Log4Shell

Log4Shell étant très répandu dans l’écosystème Java, pour y remédier, il fallait avant tout identifier les endroits où des versions vulnérables de Log4j étaient utilisées. Or, il ne suffit pas d’examiner les dépendances d’un projet. Snyk a constaté que la plupart des vulnérabilités proviennent de dépendances transitives.

Grâce à ses informations de sécurité précises et fournies en temps utile, Snyk a aidé de nombreuses entreprises à détecter Log4j dans leurs bases de code, même si plus de 60 % des instances provenaient de dépendances indirectes. Snyk a notamment rapidement publié une mise à jour de son interface de ligne de commande, spécialement conçue pour détecter Log4j dans les binaires Java ou les fichiers JAR.

« Nous avons dû tout remettre en question en raison de la nature de ce problème. C’est le revers de la médaille de l’open source. L’avantage, c’est que nous pouvons réagir très rapidement aux problèmes, mais il faut souvent quelques jours pour retrouver une situation stable. »

Après avoir analysé l’impact à l’échelle du secteur, Snyk a découvert que plus de 17 000 packages Java étaient concernés et que plus de 800 000 tentatives d’attaque avaient eu lieu au cours des seules 72 premières heures. Cependant, de nombreux attaquants ciblent des entreprises qui ne corrigent jamais les problèmes après cette première période. C’est pourquoi il est important de rechercher en continu les vulnérabilités telles que Log4Shell, même longtemps après la découverte d’un correctif.

« Il nous arrive de tomber dans le piège du cycle des vulnérabilités et de pousser un soupir de soulagement dès qu’un moyen de corriger la vulnérabilité est disponible. Mais ce n’est en réalité que le milieu du processus, car un certain pourcentage d’entreprises ne corrigera pas la vulnérabilité à temps, et c’est alors que les attaquants passent à l’action. »

Les autres sessions de la série comprenaient : 

• Exploiter vos lignes de code les plus vulnérables avec StackHawk

• Exploiter les vulnérabilités de vos workloads de conteneurs avec AWS

• Pirater vos clusters Kubernetes mal configurés avec HashiCorp

Regardez l’intégralité de la session de hacking en direct AWS avec Snyk et Atlassian ici.

Play Video: Exploiting Risks in Your Open Source Dependencies with Atlassian