AppSec et la communauté des logiciels répondent à Log4j

La sécurité des applications et les communautés de logiciels open source ont relevé le défi de la vulnérabilité Java Log4j, en corrigeant le logiciel, en partageant des informations et en fournissant des atténuations et des outils. Nous ne sommes pas encore sortis du bois, mais leurs actions jusqu’à présent ont été inspirantes.

Qu’est-il arrivé?

La nouvelle vulnérabilité Log4j, baptisée Log4Shell, a mis le monde en alerte rouge. La vulnérabilité a été signalée pour la première fois à Apache Software Foundation le 24 novembre 2021 par un employé de l’équipe de sécurité d’Alibaba Cloud et un exploit a été publié anonymement sur Twitter le 9 décembre 2021.

Peu de temps après la publication de l’exploit, les attaques actives ont considérablement augmenté. Des preuves ont rapidement suivi que les exploits utilisant cette vulnérabilité avaient été actifs dans la nature pendant jusqu’à deux semaines avant qu’elle ne devienne largement connue. Compte tenu d’un exploit public pour cette vulnérabilité, la situation est devenue une course aux armements au cours du week-end du 10 décembre 2021 au 12 décembre 2021 avec de nombreux membres de la communauté de la sécurité, y compris nos équipes, passant leurs week-ends et les nuits tardives suivantes à se précipiter pour obtenir un meilleur comprendre le fonctionnement de la vulnérabilité et la meilleure façon de la détecter et de s’en protéger.

À quel point est-ce grave ?

Cette vulnérabilité Log4j est aussi grave que possible. Dans un briefing, la plus haute responsable américaine de la défense en matière de cybersécurité, Jen Easterly, a déclaré que la faille est « »l’un des plus sérieux que j’ai vu dans toute ma carrière, si ce n’est la plus sérieuse.

En raison de la facilité d’exploitation de cette vulnérabilité, de l’impact possible d’un exploit réussi et de l’utilisation généralisée de Log4j (la bibliothèque Java vulnérable), la vulnérabilité a reçu une note de criticité maximale de 10 dans le système de notation de vulnérabilité commun (CVSS).

Il est probable que cette vulnérabilité affectera des centaines de milliers d’organisations et des centaines de millions d’appareils dans le monde. À l’instar d’autres vulnérabilités à fort impact telles que Heartbleed et Shellshock, le nombre de produits vulnérables connus continuera d’augmenter dans les semaines et les mois à venir, et l’impact de cette vulnérabilité durera des années.

Résumé de la vulnérabilité

Cette vulnérabilité est désignée CVE-2021-44228 par MITRE et a été surnommé « Log4Shell » par la communauté de sécurité des applications.

À un niveau élevé, la vulnérabilité combine :

  • La fonctionnalité « recherche » du package Apache Log4j 2.x
  • L’API Java Naming and Directory Interface (JNDI) pour exécuter un objet Java
  • LDAP et RMI, utilisés pour récupérer des objets Java distants
  • Requête DNS + résolution variable pour extraire les données sensibles.

Ceux-ci sont combinés dans une chaîne malveillante qui, lorsqu’elle est analysée par une bibliothèque Log4j vulnérable – dans le cas le plus simple – peut être utilisée pour lire les variables d’environnement du système attaqué pour récupérer des informations sensibles et, dans le pire des cas, peut être utilisée pour du code à distance l’exécution (RCE) conduisant à une prise en charge complète du système.

Il y a déjà plein de bons articles comme celui-ci discuter des détails techniques de ce que l’on sait actuellement sur cette vulnérabilité, nous n’y reviendrons donc pas ici.

Qu’est-ce qui est à risque ?

Cette vulnérabilité peut assez facilement donner à un attaquant la possibilité d’exécuter code arbitraire sur le système compromis (appelé exécution de code à distance, ou RCE). La capacité d’effectuer un RCE sur un système cible est l’objectif d’un attaquant. Même si la commande à distance s’exécutera avec les privilèges restreints avec lesquels Log4j s’exécute, une fois qu’un attaquant a pris pied dans un système, il est beaucoup plus susceptible de pouvoir élever ses privilèges et de faire plus de dégâts.

Mais ce ne sont pas seulement les systèmes directement attaqués qui sont menacés.

Pas seulement les systèmes Edge

La vulnérabilité peut également donner à l’attaquant un accès à l’un des systèmes de la chaîne d’appel sur le chemin du système Log4j cible (à condition qu’il se connecte également à l’aide de la bibliothèque de journalisation Log4j vulnérable). Et ce système peut être un système backend derrière un pare-feu, un service tiers intermédiaire, une application cliente, un appareil IoT, une application mobile, etc. Fondamentalement, partout où la bibliothèque Log4j est utilisée pour capturer des journaux.

Et c’est en partie ce qui rend cette vulnérabilité si dangereuse. Un attaquant n’a pas besoin d’être précis dans son ciblage. Ils peuvent envoyer leur charge utile d’exploit au hasard et attendre qu’un système affecté, même derrière des protections périmétriques telles que les WAF, les passerelles API et les pare-feu, revienne sur leur serveur malveillant pour exécuter le code malveillant. Ensuite, ils sauront qu’ils ont une victime réussie qu’ils peuvent contrôler à distance.

Les données sont également en danger

Donc, certainement, si votre logiciel exécute une bibliothèque Log4j vulnérable, vous courez un risque, mais que se passe-t-il si ce n’est pas le cas ? Êtes-vous à l’abri d’être exploité?

Malheureusement, la réponse est non, vous n’êtes toujours pas en sécurité. Vos communications et vos données sont toujours en danger. Par exemple, disons que vous avez un service Go qui partage des données avec un service Python qui partage des données avec un service Java qui utilise Log4j. Un attaquant envoie une chaîne d’attaque à votre service Go qui la transmet au service Python qui la transmet au service Java.

Bien que vos services Go et Python ne soient pas vulnérables, le service Java qui utilise Log4j le pourrait. Maintenant, si ce service Java gérait l’une de vos données sensibles, ces données sensibles pourraient maintenant être compromises.

Atténuations

Il existe généralement trois mesures d’atténuation que tout le monde devrait envisager de mettre en œuvre dès que possible pour protéger ses applications de cette vulnérabilité Log4j. Celles-ci ne s’excluent pas mutuellement et nous recommandons de pratiquer la défense en profondeur en mettant en œuvre plusieurs d’entre elles.

Bouclier

La première mesure d’atténuation consiste à protéger toutes vos applications afin de gagner du temps pour mettre en place les autres mesures d’atténuation. Les autres mesures d’atténuation nécessitent de savoir où vous êtes vulnérable, puis de mettre en œuvre les modifications. Pour faire de la place à cette découverte, mettez en place un bouclier capable de détecter et de bloquer les attaques en identifiant leur signature au moment de l’exécution et en arrêtant le trafic.

Bien qu’il s’agisse de l’atténuation la plus simple, la plus rapide et la moins intrusive (pas de modification du code ou de la configuration de l’application), l’inconvénient est qu’elle peut ne pas détecter tous les exploits associés ou produire un nombre élevé de faux positifs. Cela dépend bien sûr de la qualité de votre solution de défense d’exécution.

Pièce

La solution la meilleure et la plus efficace, que tout le monde devrait implémenter dès que possible, consiste à patcher leurs bibliothèques Log4j vers la dernière version non vulnérable (Log4j 2.17.0 au moment de la rédaction de cet article). C’est la seule vraie résolution de cette vulnérabilité qui persistera.

Cependant, il s’agit de l’atténuation la plus difficile à réaliser de manière approfondie, car la bibliothèque Log4j vulnérable peut être cachée profondément dans votre application de différentes manières et la trouver peut être très difficile. Un bon outil d’analyse de composition logicielle (SCA), tel que Snyk, peut aider à accélérer et à simplifier ce processus dans la phase de développement.

Cependant, même une fois que les bibliothèques vulnérables sont trouvées, cela peut prendre du temps pour tester les modifications partout avant qu’elles ne soient mises en production. C’est pourquoi l’étape « bouclier » est importante.

Désactiver

La dernière atténuation, mais non la moindre, consiste à mettre en œuvre un ensemble de contre-mesures temporaires qui désactivent essentiellement les capacités vulnérables soit en désactivant les recherches (en définissant une configuration dans les variables d’environnement ou dans les propriétés d’invocation Java) soit en supprimant les bibliothèques JNDI de Log4j paquet au total. Dans tous les cas, ces modifications peuvent être interrompues pour certaines applications et peuvent être annulées accidentellement et sans le savoir, car il ne s’agit pas des configurations par défaut.

Les communautés interfonctionnelles se rassemblent

Les communautés de sécurité des logiciels et des applications combinées ont répondu collectivement à l’appel pour remédier à cette vulnérabilité et continuent de le faire. Je suis extrêmement fier de la rapidité avec laquelle ces deux communautés se sont réunies et ont sacrifié du temps et du sommeil pour rechercher, informer, créer et partager des outils, mettre à jour des packages et aider à protéger les applications dans les jours suivant la publication du premier exploit. Leurs efforts, leur collaboration et le partage de l’information sont inspirants.

Et nous ne pouvons pas lâcher prise. Nous devons continuer à pousser pour patcher chaque paquet Log4j partout. Aujourd’hui plus que jamais, nous devons continuer à travailler ensemble pour des logiciels sécurisés.

Dans un monde de plus en plus interconnecté, nous devons travailler comme une seule communauté (développement, sécurité et opérations) pour nous protéger non seulement nous-mêmes, mais aussi nos voisins et leurs voisins qui constituent tous notre plus grand écosystème logiciel.

Prochaines étapes

Alors que nous sortons de cette crise—et nous sera sortir de cette crise—nous aurons l’occasion d’appliquer les leçons apprises et de réduire notre exposition aux vulnérabilités futures. Je pense qu’il y a cinq choses que nous devons faire en tant que leaders de l’industrie, et par « nous », j’entends les entreprises, le gouvernement, les chercheurs et les fournisseurs de la même manière :

  • Tout d’abord, nous devons réaliser qu’il s’agit vraiment d’une forme d’attaque au niveau de l’API, et nous devons collaborer et partager les enseignements tirés de cette crise.
  • Deuxièmement, nous devons créer collectivement un cadre de ressources pédagogiques pour aider à éduquer l’industrie sur la façon d’atténuer et de bloquer les vulnérabilités des API comme celle-ci.
  • Troisièmement, nous devons éduquer les ingénieurs sur la conception de la sécurité des API et les modèles de codage pour déplacer efficacement la sécurité des API vers la gauche.
  • Quatrièmement, nous devrions augmenter notre investissement et notre engagement envers les programmes de primes de bogue pour découvrir d’autres vulnérabilités cachées tôt afin que nous puissions corriger et atténuer de manière proactive.
  • Cinquièmement, les fournisseurs doivent développer des outils qui unifient le développement, la sécurité et les opérations en une seule équipe pour mesurer, gérer et améliorer leur exposition à la sécurité des API.

Je discute plus de détails de ce que nous faisons pour aider à résoudre notre crise actuelle dans un blog séparé.

Articles récents par auteur

Previous

Biden et Poutine tiennent un appel alors que la tension entre l’Ukraine et la Russie couve

Chanteur local faisant partie d’un album international

Next

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.