Détection de l’exploitation de la vulnérabilité CVE-2021-44228 (Log4j2) avec Elastic Security

Par

Jake King,

Samir Bousseaden

blog-security-detection-720x420.png

AVERTISSEMENT :

  • Pour comprendre comment Elastic évalue actuellement le risque interne de cette vulnérabilité dans nos produits, veuillez consulter l’avis ici.
  • Ce blog a été mis à jour (14 décembre 2021) avec de nouvelles améliorations concernant la détection et la recherche de menace depuis sa publication initiale.

Aperçu

Le présent article de blog fournit un résumé de la vulnérabilité CVE-2021-44228 et fournit aux utilisateurs d’Elastic Security des outils permettant de détecter une exploitation active de celle-ci dans leur environnement.

Cet article sera complété au fur et à mesure que nous en apprendrons davantage. Cette version est exacte en date du mardi 14 décembre 2021. Les mises à jour d’Apache peuvent être consultées directement sur la page sécurité de Log4j2.

Résumé relatif à la vulnérabilité CVE-2021-44228 (Log4Shell)

Log4j2 est un framework open source de logging intégré à de nombreuses applications Java sur les systèmes des utilisateurs finaux et les serveurs. À la fin novembre 2021, Chen Zhaojun d’Alibaba a identifié une vulnérabilité d’exécution de code à distance, finalement signalée sous l’ID CVE : CVE-2021-44228, rendue public le 10 décembre 2021. La vulnérabilité est exploitée via une désérialisation incorrecte des entrées utilisateur transmises au framework. Elle autorise l’exécution de code à distance et peut permettre à un pirate de divulguer des données sensibles, telles que des variables d’environnement, ou d’exécuter des logiciels malveillants sur le système cible.

La vulnérabilité identifiée affecte toutes les versions de Log4j2 de la version 2.0-beta9 à la version 2.14.1. Les premières méthodes destinées à corriger le problème ont abouti à un certain nombre de versions candidates, pour finir par des recommandations de mise à niveau du framework vers la version Log4j2 2.15.0-rc2 au moment de la rédaction de cet article.

Compte tenu de la complexité et de la nature de l’exploitation généralisée observée, l’atténuation doit être considérée comme critique dans tout environnement ayant identifié des logiciels exploitant des versions vulnérables de Log4j2.

Détection de l’exploitation de Log4Shell avec Elastic Security

Les utilisateurs d’Elastic Security peuvent utiliser la règle de détection de corrélation d’évènements suivante afin d’identifier l’exploitation active de la vulnérabilité Log4j2. Selon le format des données des évènements sur l’hôte, il vous faudra peut-être modifier cette détection afin qu’elle corresponde à vos champs de données.

Règle de détection lors de l’utilisation de données Endpoint

sequence by host.id with maxspan=1m
 [network where event.action == "connection_attempted" and 
  process.name : "java" and
  /* 
     outbound connection attempt to 
     LDAP, RMI or DNS standard ports 
     by JAVA process 
   */ 
  destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
 [process where event.type == "start" and 

  /* Suspicious JAVA child process */
  process.parent.name : "java" and
   process.name : ("sh", 
                   "bash", 
                   "dash", 
                   "ksh", 
                   "tcsh", 
                   "zsh", 
                   "curl",
                   "perl*",
                   "python*",
                   "ruby*",
                   "php*", 
                   "wget")] by process.parent.pid

Règle de détection lors de l’utilisation des données Auditbeat

sequence by agent.id with maxspan=1m
 [network where event.action == "connected-to" and 
  process.name : "java" and
  /* 
     outbound connection attempt to 
     LDAP, RMI or DNS standard ports 
     by JAVA process 
   */ 
  destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
 [process where event.type == "start" and 

  /* Suspicious JAVA child process */
  process.parent.name : "java" and
   process.name : ("sh", 
                   "bash", 
                   "dash", 
                   "ksh", 
                   "tcsh", 
                   "zsh", 
                   "curl",
                   "perl*",
                   "python*",
                   "ruby*",
                   "php*", 
                   "wget")] by process.parent.pid

Règle de détection lors de l’utilisation d’évènements en streaming Endgame

sequence by agent.id with maxspan=1m
 [network where event.category == "network" and 
  process.name : "java" and
  /* 
     outbound connection attempt to 
     LDAP, RMI or DNS standard ports 
     by JAVA process 
   */ 
  destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
 [process where event.type == "start" and 

  /* Suspicious JAVA child process */
  process.parent.name : "java" and
   process.name : ("sh", 
                   "bash", 
                   "dash", 
                   "ksh", 
                   "tcsh", 
                   "zsh", 
                   "curl",
                   "perl*",
                   "python*",
                   "ruby*",
                   "php*", 
                   "wget")] by process.parent.pid

Cette règle de détection recherche une séquence d’une tentative de connexion sortante vers des ports standard pour LDAP, RMI et DNS (souvent exploitée via des attaques par injection JAVA/JNDI observées récemment), suivie d’un processus enfant de la même instance de processus Java.

À présent, montrons comment cette règle détecte l’exploitation de la vulnérabilité log42j :

La capture d’écran ci-dessus montre un pirate exploitant la vulnérabilité avec une charge utile codée en base-64

La capture d’écran ci-dessus montre un pirate exploitant la vulnérabilité avec une charge utile codée en base 64 ciblant un exemple d’application vulnérable créé par Christophe Tafani-Dereeper.

Cette capture d’écran montre la détection de l’exploitation active de CVE-2021-44228 dans Elastic Security, détaillant à la fois l’alerte et la chronologie de l’exploitation de la faille.

Cette capture d’écran montre la détection de l’exploitation active de CVE-2021-44228 dans Elastic Security, détaillant à la fois l’alerte et la chronologie de l’exploitation de la faille.

La capture d’écran ci-dessus montre, dans l’enquête de l’alerte de détection, que Java a exécuté un script shell pour télécharger et exécuter un script Bash.

La capture d’écran ci-dessus montre, dans l’enquête de l’alerte de détection, que Java a exécuté un script shell pour télécharger et exécuter un script Bash.

Mise à jour : Améliorations relatives à la détection et à la recherche de menaces


Exécution de commandes Shell suspectes via Java

En vous basant sur les classes Java malveillantes connues et diffusées par le biais de la faille log4j, vous pouvez rechercher des scripts Shell suspects et des commandes de transfert d'outils :

process where event.type == "start" and
  process.parent.name : "java*" and

  /* Ingress tools transfer via common shell command interpreters */

  /* linux or macos */
  (
   (process.name : ("sh", "bash", "python*") and 
    process.command_line : ("*curl*|*sh*", "*wget*|*bash", "*curl*|*bash*", "*curl*|*bash*", "*http*|*sh*", "*python*http*")) or

  /* windows */
  (process.name : ("powershell.exe", "pwsh.exe", "cmd.exe") and
   process.command_line : ("*.downloadstring*", "*.downloadfile*", "*.downloaddata*", "*BitsTransfer*", "* -enc*", "* IEX*", "*wp-content*", "*wp-admin*", "*wp-includes*", "*$*$*$*$*$*", "*^*^*^*^*^*^*^*^*^*", "*.replace*", "*start-process*", "*http*", "*cmd*powershell*")))

Exécution de fichier non fiable via JAVA

Détecte quand un interpréteur JAVA crée un fichier exécutable (PE/ELF) et que le fichier est ensuite exécuté.

Règle de détection lors de l’utilisation de données Endpoint

sequence by host.id with maxspan=5m
 [ file where event.type != "deletion" and 
  process.name : ("java", "java.exe", "javaw.exe") and 

  (file.extension : ("exe", "com", "pif", "scr") or
      /* Match Windows PE files by header data (MZ) */
  file.Ext.header_bytes : ("4d5a*", "7f454c46*")) and 

  not file.path :  ("?:\\Program Files\\*", 
                    "?:\\Program Files (x86)\\*") ] by file.path
 [ process where event.type == "start" and 
  not process.code_signature.trusted == true ] by process.executable
Règle de détection lors de l’utilisation d’évènements en streaming Endgame
sequence by agent.id with maxspan=5m
  [ file where event.type != "deletion"
    process.name : ("java", "java.exe", "javaw.exe")] by file_path
  [ process where event.type == "start" and 
  not process.code_signature.trusted == true] by process_path

Activité potentielle de CoinMiner

Processus avec ligne de commande commune au mineur de cryptomonnaie (la plupart des campagnes observées exploitant la faille log4j sont des mineurs de cryptomonnaie) :

process where event.type == "start" and 
 process.command_line : 
       ("* pool.*", "*-u*--coin*", "*.xmr.*", "*.xmr1.*", 
        "*stratum*", "*elitter.net*", "*cryptonight*", 
        "*-a scrypt*", "*stratum1*", "*-userpass*", "*-max-cpu-usage*", 
	  "*qhor.net*", "*-wallet*pool*", "*--donate-level*", "*supportxmr.com*")

Autres détections post exploitation associées :

Tentative de désactivation des tables IPTables ou du pare-feu

Altération de l'historique de la ligne de commande Bash

Suppression du fichier journal du système

Possibilité d’inversion de l’activité Shell via le terminal

Processus enfant JAVA suspect

Tentative de désactivation du service Syslog

Détections de la communauté

Un certain nombre de membres de la communauté discutant de l’exploitation généralisée de la vulnérabilité ont fourni des informations sur un certain nombre de méthodes de détection précoce que les analystes peuvent utiliser pour identifier si les systèmes qu’ils utilisent ont été exploités ou sont en cours d’exploitation :

  • Une série de charges utiles a été partagée par l’équipe GreyNoise, notamment des charges utiles contenant à la fois des variantes codées et décodées pour les analystes cherchant à explorer les journaux stockés dans leurs systèmes. Ceci a été complété par une liste des premières adresses IP signalées tentant d’exploiter la vulnérabilité.

  • Florian Roth de Nextron Systems a fourni une liste de vérifications pour une exploitation locale à l’aide de grep / zgrep, ainsi que de quelques signatures YARA initiales dans un Gist répertorié sur son compte Github. Florian a également partagé une méthode de génération de CanaryTokens Thinkst pour tester l’exploitabilité des systèmes que vous pourriez avoir à gérer.

  • Rob Fuller (Mubix) a partagé une liste de hachages de fichiers connus en lien avec les versions vulnérables du framework, ici.

Autres stratégies d’atténuation

En dehors des recommandations de l’équipe Apache concernant le déploiement des dernières versions corrigées du framework Log4j2 à mettre à jour, un certain nombre d’atténuations ont été largement suggérées pour empêcher l’exploitation :

  • Fastly a suggéré de vérifier si votre version de Log4j prend en charge l’exécution de la JVM avec JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true afin de désactiver la fonctionnalité de recherche sur le serveur distant. Cette vérification devrait concerner les versions 2.10.0 à 2.15.0.

  • Pour empêcher le mouvement latéral d’un hôte vulnérable, ou l’exploitation sur le réseau, il est recommandé de limiter la connectivité des systèmes potentiellement vulnérables aux ressources externes vers des applications et/ou des services de confiance.

Un grand merci de la part d’Elastic Security.

Nous tenons à remercier toutes les équipes de sécurité à travers le monde pour leur travail acharné aujourd’hui et tout au long du week-end, surtout celles et ceux d’entre vous mentionnés dans ce post. L’ouverture et la collaboration au sein de la communauté de la sécurité dans le but de protéger tous les utilisateurs est primordiale face à une vulnérabilité aussi grave et généralisée. Nous souhaitons que vous sachiez que nous vous soutenons tout au long de votre parcours.

La version actuelle d’Elastic Security peut accéder à ces fonctionnalités au sein du produit. Si vous débutez avec Elastic Security, consultez nos guides de démarrage rapide (qui sont de petites vidéos de formation pour que vous soyez rapidement opérationnel) ou nos formations gratuites sur les notions de base. Comme toujours, vous pouvez aussi vous lancer avec un essai gratuit d’Elastic Cloud pendant 14 jours. Et si vous préférez une expérience autogérée, vous pouvez choisir de télécharger gratuitement la Suite Elastic.

Références

https://www.lunasec.io/docs/blog/log4j-zero-day/

https://www.tenable.com/blog/cve-2021-44228-proof-of-concept-for-critical-apache-log4j-remote-code-execution-vulnerability

https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/

https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/

https://www.greynoise.io/viz/query/?gnql=CVE-2021-44228

https://logging.apache.org/log4j/2.x/security.html#

https://github.com/christophetd/log4shell-vulnerable-app

Inscrivez-vous à un essai gratuit d'Elastic Cloud

Optez pour un déploiement ultra-complet sur la plateforme cloud de votre choix. En tant que créateurs d'Elasticsearch, nous mettons nos fonctionnalités et notre support technique au service de vos clusters Elastic dans le cloud.

Démarrer un essai gratuit