Anish Bogati & Nilaa Maharjan; Security Research

Index

Le 13 octobre 2022, l’Apache Software Foundation a publié un avis de sécurité concernant une vulnérabilité critique zero-day dans Apache Commons Text, de la version 1.5 à 1.9. Dénommée CVE-2022-42899, Text4shell a une gravité de 9,8 sur 10 en utilisant le calculateur CVSSv3 car elle conduit à l’exécution de code à distance lorsqu’elle est exploitée. Etant donné que plusieurs preuves de concept (PoC) apparaissent chaque jour, après la publication de chaque patch, le correctif recommandé consiste à effectuer une mise à niveau vers la dernière version 1.10.

Rémanence de Log4Shell ?

Comme c’est la tendance avec toutes les vulnérabilités nommées *4Shell, Text4Shell est comparé à Log4Shell, un bug majeur qui a secoué la communauté infosec l’année dernière. L’équipe de sécurité d’Apache a apporté des informations supplémentaires concernant la comparaison entre Log4Shell et Text4Shell dans un récent article de blog, qui peut être résumé ainsi:

Ce problème est différent de Log4Shell (CVE-2021-44228) car dans Log4Shell, l’interpolation de chaîne était possible à partir du corps du message de log, qui contient généralement des entrées non fiables. Dans le problème concernant Apache Commons Text, la méthode concernée est explicitement développée et clairement documentée pour effectuer une interpolation de chaîne, il est donc beaucoup moins probable que les applications transmettent par inadvertance une entrée non fiable sans validation appropriée.

Cependant, Text4Shell concerne un problème dans la bibliothèque Apache Commons Text, une bibliothèque Java courante qui fournit des utilitaires pour travailler avec des chaînes. Cette bibliothèque a une fonctionnalité pratique, la substitution de chaînes, qui permet à l’utilisateur de remplacer certains morceaux de texte par un autre. À l’aide d’un interpolateur et de chaînes créées dynamiquement, Apache Commons Text fournit une recherche de valeur par défaut. Le principal problème réside dans l’API StringSubstitutor.

Selon la documentation d’Apache, « La classe est utilisée pour substituer des variables dans une chaîne par des valeurs. La classe StringSubstitutor prend un morceau de texte et remplace toutes les variables qu’il contient ». Le format standard pour l’interpolation/substitution est « ${prefix: name} », où « prefix » est la clé de recherche qui est présentée dans l’image ci-dessous et « name » représente les chaînes dont les valeurs sont traitées par les méthodes de recherche.

Recherches de chaîne disponible

C’est là que la vulnérabilité entre en jeu dans les versions 1.5 à 1.9. Selon Alvaro Munoz, suite à la divulgation de cette menace :

Le StringSubstitutor lorsqu’il est utilisé avec les interpolateurs par défaut (StringSubstitutor.createInterpolator()) effectuera des recherches de chaîne qui pourraient conduire à l’exécution de code arbitraire.

En particulier, si des données non fiables circulent dans les méthodes StringSubstitutor.replace() ou StringSubstitutor.replaceIn(), un attaquant pourrait utiliser ScriptStringLookup pour déclencher l’exécution de code arbitraire.

Les interpolateurs concernés sont:

  • script: utilisé pour évaluer les expressions à l’aide du moteur d’exécution de script JVM (script).
  • dns: utilisé pour résoudre les enregistrements DNS.
  • url: utilisé pour demander des informations à partir d’une URL.

Une faille logique dans la classe StringSubstitutor rend les clés de recherche supplémentaires : « script », « dns » et « url » disponibles par défaut, ce qui ne devrait pas être le cas selon la documentation. Les méthodes d’interpolation supplémentaires fournissent des moyens d’accéder au réseau, de contacter des serveurs distants et d’exécuter du code. Les fonctionnalités mentionnées sont prévues mais ne sont pas fournies par défaut tant que les fonctionnalités supplémentaires ne sont pas configurées. L’entrée utilisateur est transmise à StringSubsitutor sans valider l’entrée. En conséquence, les adversaires peuvent appeler des méthodes de recherche de chaîne telles que « script » pour exécuter des commandes au niveau du système d’exploitation.

PoC de CVE-2022-42889

Afin de reproduire l’attaque, un composant vulnérable utilisant Apache Commons Text doit être exécuté. Dans notre cas, nous utilisons un environnement Docker qui peut être trouvé ici.

Dans l’environnement de démonstration, la vulnérabilité peut être trouvée sur l’API de recherche du serveur Web où la classe StringSubstitutor de Commons Text est implémentée. Nous utilisons ensuite la fonction de recherche de chaîne « script » qui peut exécuter la charge virale en utilisant le moteur d’exécution de script JVM (javax.script).

Les conditions requises pour Text4Shell sont que :

  • L’application utilise Apache Commons Text, version 1.5 à 1.9 incluse.
  • L’application importe apache.commons.text.StringSubstitutor et utilise l’un des interpolateurs par défaut suivants avec la configuration par défaut :
    • dns
    • script
    • url

Une fois ces vérifications en place, la charge virale suivante peut être utilisée pour exploiter la vulnérabilité et envoyer un ping à un hôte distant :

$%7Bscript:javascript:java.lang.Runtime.getRuntime().exec(%27ping%20-c%205%20172.17.0.1%27)%7D 

Nous pouvons ensuite envoyer la charge virale spécialement conçue, mentionnée ci-dessus, pour atteindre notre objectif.

Nous pouvons voir que nous parvenons à envoyer un ping à notre hôte à partir de la machine cible. Le point important à noter ici est que nous ne sommes pas obligés de nous limiter au ping. En effet, toute requête du système d’exploitation à ce stade est une charge virale valide. Tout attaquant mal intentionné peut ouvrir un reverse shell ou exécuter toute autre commande disponible sur l’hôte.

Comme démontré ci-dessous, nous avons un shell efficace sur l’hôte.

Détection de Text4shell à l’aide de Logpoint

Sources de log nécessaires

  • Pare-feu
  • Serveur exécutant la bibliothèque Apache Commons Text
    • Sysmon pour Linux
    • Auditd
    • Logs d’accès au serveur Apache
  • Apache s’exécutant sous Windows
    • Logs d’événement natif
    • Sysmon

Comme l’exploitation nécessite l’utilisation de l’une de ces méthodes de recherche supplémentaires mentionnées ci-dessus, nous pouvons rechercher ces fonctions dans les URL pour détecter toute tentative d’exploitation.

(url=* OR resource=*) 
| process eval("decoded_resource=urldecode(resource)") 
| process eval("decoded_url=urldecode(url)") 
| rename decoded_resource as resource, decoded_url as url 
| search ( resource IN ["*${script:*","*${url:*","*${dns:*","*script*java.lang.Runtime.getRuntime*"] 
OR url IN ["*${script:*","*${url:*","*${dns:*","*script:*:java.lang.Runtime.getRuntime*"])

Détection de l’activité post-compromission

En plus de la détection des tentatives d’exploitation, il est également très important de détecter l’activité post-compromission. Nous pouvons passer à côté de la détection de tentatives d’exploitation pour diverses raisons, nous devons donc rechercher des traces d’activités suspectes telles que la création d’un shell, une connexion sortante suspecte à un hôte distant ainsi que d’autres activités suspectes pouvant indiquer une compromission. Nous avons commencé notre chasse aux activités suspectes en se focalisant sur la détection d’activités de découverte initiale d’informations système ainsi que sur les tentatives suspectes de création de processus et d’exécution de commandes.

Après avoir obtenu un shell inversé ou un accès au système, les adversaires peuvent essayer de mener une activité de découverte d’informations système que nous pouvons détecter en utilisant la requête suivante :

Pour les systèmes Unix qui utilisent auditd pour la journalisation (logging) :

norm_id=Unix "process"=audit (event_type="EXECVE" argument_0 IN ["uname", "uptime"]) 
OR (event_type="PATH" path IN ["/sys/class/dmi/id/bios_version", "/sys/class/dmi/id/product_name", "/sys/class/dmi/id/chassis_vendor", "/proc/scsi/scsi", "/proc/ide/hd0/model", "/proc/version", "/etc/*version", "/etc/*release", "/etc/issue"])     

Pour Windows:

label="Process" label=Create ("process"="*\systeminfo.exe" OR command="*net config*") -user IN EXCLUDED_USERS   

Nous pouvons également rechercher une création de processus suspect dans les systèmes Windows. Il peut y avoir des faux positifs que l’analyste doit filtrer en fonction de son environnement.

label="Process" label=Create 
"process" IN ["*\whoami.exe", "*\systeminfo.exe", "*\ipconfig.exe", "*\cmd.exe", "*\powershell.exe", "*\wget.exe", "*\curl.exe", "*\nslookup.exe"] 
-command="cmd.exe /c set" 
| chart count() by host, parent_process, "process", command 

Pour les systèmes Linux exécutant sysmon, surveillez l’apparition de processus suspects:

norm_id=UnixSysmon label="Process" label=Create 
(user="confluence" OR path="*/Atlassian/Confluence/bin") 
image IN ["/usr/bin/uname", "/usr/bin/whoami", "/usr/bin/hostname", "/usr/bin/ip", "/usr/bin/id", "/usr/bin/wget", "/usr/bin/curl", "/usr/bin/ss", "/usr/sbin/iptables", "/usr/bin/bash", "/usr/bin/sh"] 
| chart count() by host, image, command 

Appliquez les mesures d’atténuation dès que possible

Nous conseillons aux administrateurs d’évaluer et de mettre à jour leur bibliothèque Apache Commons Text avec la dernière version dès que possible. Les analystes doivent surveiller les traces de post-exploitation et rechercher toute activité suspecte liée à une potentielle tactique que nous n’avons pas forcément couverte ci-dessus. Des alertes pour détecter les activités suspectes sont déjà créées par l’équipe Logpoint, nous conseillons donc aux analystes de les utiliser et de rechercher en permanence les activités malveillantes. La recherche active d’indicateurs de compromission et le test de diverses hypothèses peuvent aider à découvrir les vulnérabilités zero-day. Enfin, en utilisant Logpoint SOAR, un analyste pourra automatiser le processus de suivi, de détection et d’atténuation de la menace en question.

Nous mettrons à jour cet article de blog en fonction de l’évolution de la situation.

Contact Logpoint

Contact us and learn why
industry-leading companies
choose Logpoint:

Contact Logpoint