Log4j depuis l'œil de la tempête

Log4j depuis l'œil de la tempête
Photo by Raychel Sanner / Unsplash

À moins de vivre dans une grotte, vous n’avez pas pu passer ces derniers jours à côté des failles découvertes sur la librairie Java log4j.

Je ne vais pas vous faire un énième post pour parler de cette faille, mais plutôt parler de mon expérience sur le terrain sur l’impact de cette dernière au niveau opérationnel.

L’importance d’avoir un inventaire à jour

J’en ai parlé sur Twitter, mais pour moi, cette faille met en exergue le fait que beaucoup d’entreprises manquent d’un inventaire à jour de leurs ressources.

Lorsqu’une faille comme celle-ci se déclare, il est important d’être en mesure d’identifier rapidement quelles sont les ressources en risques. Mais avoir un inventaire à jour ne se limite pas aux machines, mais aussi à leur contenu.

C’est d’autant plus important lorsqu’on exploite la puissance du cloud, avoir des machines volatiles rend d’autant plus complexe leur gestion.

Pour ça il existe plusieurs solutions.

Faire uniquement de l’infra as code

Ce point va sembler trivial à beaucoup d’entre vous, mais faire uniquement de l’infra as code simplifie énormément les choses pour visualiser rapidement ce qu’on déploie, sur quel projet, quelle machine, quel compte, etc.

Dans un pipeline CI/CD c’est le rôle d’un SAST (Static application security testing) de repérer les failles courantes au moment de la compilation des nouveaux projets, toutefois, il faut de l’outillage pour les projets déjà compilés, par exemple, sur GitHub, Dependabot m’a indiqué assez rapidement les projets dans lesquels il avait identifié l’utilisation de la librairie.

Toutefois, ce point n’est clairement pas suffisant. Ce n’est pas parce que je ne définis pas explicitement une librairie qu’elle n’est pas utilisée.

Scanner les artefacts déjà créés

Si vos applications sont déjà compilées, il existe souvent sur vos gestionnaires de librairies des solutions pour scanner ces derniers.

Par exemple, Docker Hub vous permet de scanner vos images à la recherche de la librairie.

Toutefois, ce n’est toujours pas suffisant. Sur vos serveurs, vous n’utilisez pas forcément que des packages que vous maitrisez et référencez vous-même.

Par exemple, vous pouvez exploiter une image AWS d’un éditeur sur le marketplace, ou avoir des applications tierces déployées dans votre infrastructure.

Scanner en continu vos serveurs

C’est là qu’entre en jeu le troisième niveau de scan : vous pouvez scanner en continu vos machines pour identifier rapidement les serveurs en danger.

Il existe pour cela des outils comme Nessus Tenable ou encore Rapid7 InsightVM. Le rôle de ces outils va être de scanner vos serveurs et vous remonter les machines en risque.

Une simple recherche avec l’identifiant d’une CVE vous permet d’identifier rapidement les serveurs impactés.

Comment j’ai vécu cette étape

Comme beaucoup dans l’infosec ces derniers jours, cette première étape a été compliquée. Même avec de l’outillage, on prend toujours le risque de passer à côté de certaines ressources.

Je travaille dans une petite équipe et nous avons réagi au mieux, mais vu le risque encouru avec cette vulnérabilité, nous refaisons plusieurs contrôles. Ce point est épuisant, car nous devons faire nombre d’actions manuelles, tout n’est pas forcément simplement automatisable.

C’est une étape laborieuse, épuisante (mentalement), mais indispensable et critique.

Une fois les serveurs identifiés je fais quoi ?

Maintenant que je sais quelles sont mes ressources touchées par la vulnérabilité log4j, je fais quoi ?

Première chose qu’on oublie souvent : on ne panique pas !

C’est un comportement que je vois souvent lors d’incidents de sécurité, pourtant il est d’autant plus important de garder la tête froide qu’une erreur peut couter cher !

Patcher, patcher, patcher…

La solution sera souvent la même ici : patcher ou mettre à jour l’applicatif. Néanmoins, à ce jeu, tous les éditeurs ne sont pas aussi sérieux.

Sur ce point, j’ai vu plusieurs comportements :

  • Les éditeurs très réactifs et transparents sur les risques
  • Les éditeurs qui indiquent qu’ils ne savent pas (ce qui n’est pas forcément pour me rassurer soit dit en passant).
  • Les éditeurs qui disent être impactés, mais mettent plusieurs jours à sortir une version avec le fix nécessaire
  • Ceux qui disent qu’ils ne sont pas impactés pour finalement indiquer le contraire
  • Ceux qui préfèrent indiquer qu’ils ne sont pas impactés alors qu’ils sont loin de java (par exemple HashiCorp et ses outils écrits en GoLang)

Dépendre d’autres équipes

À mon poste, je ne suis pas celui qui patche, mais dans l’équipe qui va identifier les risques, les mesurer et demander les actions nécessaires aux autres équipes (Dev, Ops, DataOps, etc.)

C’est une posture qui peut être frustrante, car on dépend de gens sur lesquels on n’a aucun pouvoir de priorisation et tout le monde ne perçoit pas forcément les risques de ces failles.

C’est pourquoi il est important d’avoir (une fois de plus) une posture pédagogue, et de bien expliquer les risques et pourquoi il est important de réagir vite.

Et c’est aussi à cette étape qu’il est important de bien tracer toutes les demandes et faire le suivi associé.

L’une des solutions temporaires peut parfois être de mitiguer le risque pour réduire autant que possible l’impact de la lenteur de tiers, cela peut passer : par des règles sur un WAF, des modifications de packages directement sur les machines (même si je ne suis pas fan de cette solution), changer l’exposition de certaines machines (passer des machines derrière un VPN par exemple) ou encore interrompre certains services temporairement.

La solution temporaire dépendant bien entendu de l’évaluation du risque associé.

Comment j’ai vécu cette étape

Comme je l’ai évoqué, j’ai eu un peu de frustration devant la non-réponse de certaines équipes, ou l’impression qu’on s’en f... . Pour certaines équipes, je suis un incident parmi d’autres déjà en cours, et je ne fais que rajouter une pièce dans la machine.

Cette étape n’est pas forcément simple, mais je trouve que cela reste plus simple qu’avoir l’inventaire.

L’après log4j

Pour l’instant la tempête log4j n’est pas encore finie, avec une faille découverte avant-hier à l’heure où j’écris ces lignes.

Investir dans la sécurité

Cette tempête comme d’autres avant elles (Spectre, Meltdown, Heartbleed, etc.) est l’occasion pour les équipes sécurité de rappeler l’importance de certains investissements :

  • Avoir une équipe sécurité qui se tient à jour
  • Avoir de l’outillage pour identifier rapidement les failles
  • Avoir un inventaire à jour
  • Sensibiliser les équipes à l’importance des bonnes pratiques de sécurité

J’ai même rappelé ce point (sur Twitter une fois de plus) dernièrement :

Combattre le comportement prédateur des big Tech

Cette faille rappelle la dure réalité des projets open source : beaucoup de projets sont clairement exploités par de nombreuses énormes sociétés qui reposent dessus sans jamais contribuer que ce soit au code ou au moins financièrement.

Log4j est une librairie exploitée par des millions d’applications dans le monde, pourtant elle est maintenue par peu de personnes.

De nombreux Tech gravitant dans l’univers open source ont fait le même constat :

Cela n’est pas sans rappeler des batailles récentes :

  • Elastic.co VS AWS
  • MongoDB VS AWS

Faute de trouver une solution viable, la solution est souvent de passer par la case légale en mettant des clauses empêchant l’utilisation par ces entreprises, car elles exploitent la richesse de ces projets sans jamais rien donner en contrepartie.