Webinaire Log4Shell : ce qu’il faut savoir

Quel que soit votre rôle dans le secteur technologique, vous avez probablement déjà entendu parler de la très répandue vulnérabilité Log4Shell, ou y avez été confronté. Elle touche un grand nombre d’applications Java. Pour diffuser les dernières informations sur cette vulnérabilité critique de type zero-day, nous avons récemment organisé un webinaire afin de faire le point.

Lors de notre webinaire Log4Shell : ce qu’il faut savoir, Steve Kinman (CISO terrain), Simon Maple (CTO terrain) et Kirill Efimov (responsable de l’équipe de recherche en sécurité) de Snyk ont parlé de la vulnérabilité Log4Shell et des moyens de l’atténuer. Voici un bref récapitulatif des points abordés.

Qu’est-ce que Log4j ?

Log4j est une bibliothèque Java open source très populaire, largement utilisée par les applications Java pour la journalisation. Ce framework de journalisation utilise le service JNDI fourni par le kit de développement Java (JDK) afin de récupérer des informations supplémentaires depuis l’application. Ces informations enrichissent les données consignées avec des métadonnées et rendent les journaux plus utiles aux développeurs. De nombreux frameworks d’applications Java populaires utilisent Log4j par défaut, notamment Apache Struts 2, Apache Solr et Apache Druid.

La journalisation est essentielle. Les applications Java consignent constamment des événements, en particulier les exceptions et les erreurs, afin que les développeurs puissent comprendre ce qui se passe.

La vulnérabilité Log4Shell

Log4Shell est le nom donné à une vulnérabilité critique et facilement exploitable de la bibliothèque Log4j2. Cette vulnérabilité (CVE-2021-44228) a obtenu un score CVSS de 10, le score maximal.

Une vulnérabilité zero-day critique, très répandue et facilement exploitable a été révélée dans Log4j. Ce vecteur d’attaque existe depuis cinq ou six ans. Comme il est très facile à exploiter, les attaques sont extrêmement nombreuses et la situation évolue constamment.

Fonctionnement de l’exploit Log4Shell

JNDI (Java Naming and Directory Interface) est un service d’annuaire semblable à LDAP, qui permet d’utiliser un identifiant unique pour récupérer du code ou des objets Java. Les applications Java interrogent couramment les services JNDI pour obtenir des sources de données ou d’autres informations.

Le framework de journalisation Log4j utilise JNDI pour récupérer des variables et d’autres informations afin d’enrichir les données qu’il consigne. Le problème, c’est que Log4j peut tenter de résoudre à l’exécution des chaînes dangereuses lors de la journalisation, notamment des URL pointant vers un service JNDI non autorisé.

La vulnérabilité Log4Shell peut donc permettre à un acteur malveillant d’envoyer une requête depuis une application Java vers son propre service JNDI, en exploitant le service de journalisation. Ce service peut alors renvoyer un objet ou du code malveillant. Cette attaque par exécution de code à distance (RCE) peut avoir des conséquences considérables.

Les principaux risques liés à Log4Shell

Avec Log4Shell, le risque direct est une attaque par exécution de code à distance. En injectant du code malveillant, un acteur malveillant peut déployer un logiciel malveillant ou un rançongiciel, prendre le contrôle d’un serveur ou d’une application, exfiltrer des données, compromettre leur intégrité ou la disponibilité de l’application, ou désactiver d’autres services de sécurité.

Outre le risque immédiat d’exploitation, les applications Java vulnérables soulèvent d’autres préoccupations. La vulnérabilité Log4Shell peut également entraîner des manquements à la conformité réglementaire, des défaillances des contrôles de sécurité du cloud, des failles de sécurité dans les applications SaaS tierces et des violations des politiques de conformité.

Le plus grand risque, c’est que votre conseil de surveillance ou votre PDG vous demande : « Sommes-nous concernés ? » Si vous n’avez pas de réponse claire, c’est un risque.

Détecter la vulnérabilité Log4Shell

Pour les équipes de développement Java, atténuer Log4Shell implique de repérer où Log4j est utilisé dans le graphe des dépendances. Cela peut s’avérer difficile : nous avons constaté que 60,8 % des clients de Snyk utilisent Log4j comme dépendance transitive. Autrement dit, le framework de journalisation se trouve dans une autre bibliothèque open source qu’ils utilisent.

L’un des aspects les plus inquiétants de cette vulnérabilité pour les équipes de sécurité est de ne pas savoir si Log4j est utilisé. Si vous ne savez pas sur quoi repose réellement votre logiciel, vous ne pouvez pas savoir avec certitude si vous êtes concerné.

Vous pouvez utiliser Snyk pour analyser vos applications à la recherche de vulnérabilités comme Log4Shell, y compris lorsque ces problèmes de sécurité se trouvent dans des dépendances transitives. Vous pouvez ainsi protéger votre chaîne d’approvisionnement logicielle contre l’introduction de risques de sécurité comme Log4Shell. Snyk a également créé une commande snyk log4shell pour détecter la vulnérabilité dans vos fichiers JAR non gérés et ombrés.

Atténuer l’exploit Log4Shell

Une fois que vous avez identifié la version de Log4j que vous utilisez, vérifiez qu’il s’agit au minimum de la version 2.17.1. Peu après la découverte de la vulnérabilité zero-day, la recommandation initiale était de passer à la version 2.15.0 pour corriger Log4Shell. Or, cette version présente également d’autres problèmes.

Note de la rédaction : au moment de l’enregistrement du webinaire, la mise à niveau recommandée était la version 2.16. Depuis, elle a été mise à jour vers la version 2.17.1. De nouvelles informations sur cette vulnérabilité sont découvertes chaque jour. Nous vous recommandons donc de consulter régulièrement notre page de ressources sur la vulnérabilité Log4Shell pour connaître les dernières informations.

Si vous ne pouvez pas mettre immédiatement la bibliothèque à niveau, vous devrez réduire les possibilités d’exploitation de Log4Shell. Pour obtenir un guide complet de correction, consultez notre antisèche de correction de Log4Shell, que nous mettons à jour en continu à mesure que la situation évolue.

Cette vulnérabilité persistera pendant des années, et le fait qu’elle soit de type zero-day est préoccupant pour le secteur. Elle continuera de refaire surface, parce que des personnes la réintroduiront ou qu’elle se trouvera dans une dépendance dont vous ignorez la présence.