von Anish Bogati & Nilaa Maharjan, Security Research

Inhaltsverzeichnis

Am 13. Oktober 2022 veröffentlichte die Apache Software Foundation eine Sicherheitsempfehlung für eine kritische Zero-Day-Schwachstelle in Apache Commons Text von Version 1.5 bis 1.9. Text4shell mit der Bezeichnung CVE-2022-42899 hat – gemäß dem CVSSv3-Calculator – einen Schweregrad von 9,8 von 10, da die Schwachstelle bei Ausnutzung zu einer Remote-Code-Execution führt. Obwohl Tag für Tag mehrere Proof of Concepts (PoCs) für jeden veröffentlichten Fix aufkommen, gilt die Empfehlung, auf die aktuelle Version 1.10 zu aktualisieren.

Überrest von Log4Shell?

Wie bei allen *4Shell-Schwachstellen üblich, wird Text4Shell mit Log4Shell verglichen, einem schwerwiegenden Bug, der im vergangenen Jahr die Infosec-Community erschütterte. Das Sicherheitsteam von Apache hat in einem kürzlich veröffentlichten Blog-Beitrag zusätzliche Informationen zum Vergleich zwischen Log4Shell und Text4Shell bereitgestellt, die auszugsweise wie folgt lauten:

Dieses Problem unterscheidet sich von Log4Shell (CVE-2021-44228), da in Log4Shell die Interpolation (Ersetzung) von Zeichenfolgen aus dem Hauptteil der Protokollnachricht möglich war, der in der Regel nicht vertrauenswürdige Angaben enthält. Bei Apache Commons Text ist die betreffende Methode ausdrücklich dafür vorgesehen und klar dokumentiert, eine Zeichenfolge-Interpolation durchzuführen, sodass es sehr viel unwahrscheinlicher ist, dass Anwendungen versehentlich nicht vertrauenswürdige Eingaben ohne ordnungsgemäße Validierung weitergeben.

Text4Shell ist jedoch ein Problem für die Apache Commons Text-Bibliothek, einer allgemeinen Java-Bibliothek, die Utilities für die Arbeit mit Zeichenketten bereitstellt. Diese Bibliothek hat eine praktische Funktion: die Ersetzung von Zeichenfolgen (String-Substitution). Diese ermöglicht es dem Benutzer, bestimmte Textsegmente durch andere zu ersetzen. Unter Verwendung eines Interpolators und dynamisch erstellter Strings bietet Apache Commons Text standardmäßig eine Wertesuche an. Das Hauptproblem liegt in der StringSubstitutor API.

In der Apache-Dokumentation heißt es: „Die Klasse wird verwendet, um Variablen innerhalb einer Zeichenfolge durch Werte zu ersetzen. Die Klasse StringSubstitutor nimmt ein Stück Text und ersetzt alle darin enthaltenen Variablen.“ Das Standardformat für die Interpolation/Substitution ist „${Präfix: Name}“, wobei „Präfix“ der Schlüssel für die Suche ist, der in der Abbildung unten gezeigt wird, und „Name“ die Zeichenfolgen sind, deren Werte von den Suchmethoden verarbeitet werden.

Verfügbare String-Lookups

Hier kommt die Schwachstelle in den Versionen 1.5 bis 1.9 ins Spiel. Alvaro Munoz beschreibt in seiner Veröffentlichung zu dieser Bedrohung:

Wenn der StringSubstitutor mit den Standard-Interpolatoren (StringSubstitutor.createInterpolator()) verwendet wird, führt dieser Zeichenfolge-Suchen durch, die zur Ausführung von beliebigem Code führen können.

Insbesondere wenn nicht vertrauenswürdige Daten in die Methoden StringSubstitutor.replace() oder StringSubstitutor.replaceIn() einfließen, kann ein Angreifer ScriptStringLookup verwenden, um die Ausführung von beliebigem Code auszulösen.

Die betroffenen Interpolatoren sind:

  • script: zur Auswertung von Ausdrücken mit der JVM-Script-Execution-Engine (script)
  • dns: zur Auflösung von DNS-Einträgen
  • url: zur Anforderung von Informationen von einer URL

Ein Logikfehler in der Klasse StringSubstitutor stellt die zusätzlichen Suchschlüssel „script“, „dns“ und „url“ standardmäßig zur Verfügung, die laut Dokumentation nicht verfügbar sein sollten. Die zusätzlichen Interpolationsmethoden bieten Möglichkeiten für den Zugriff auf das Netzwerk, für die Kontaktaufnahme zu Remote-Servern und für die Code-Ausführung. Die genannten Möglichkeiten sind vorgesehene Funktionen, werden jedoch standardmäßig nicht bereitgestellt, solange die zusätzlichen Funktionen nicht konfiguriert sind. Die Benutzereingabe wird an StringSubsitutor weitergeleitet, ohne die Eingabe zu validieren. Infolgedessen können Angreifer String-Lookup-Methoden (Zeichenfolge-Suchen) wie „script“ aufrufen, um Betriebssystem-Befehle auszuführen.

PoC für CVE-2022-42889

Um den Angriff zu reproduzieren, muss eine anfällige Komponente mit Apache Commons Text ausgeführt werden. In unserem Fall verwenden wir eine Docker-Umgebung, die Sie hier finden können.

In der Demo-Umgebung befindet sich die Schwachstelle in der Such-API des Web-Servers, wo die Klasse StringSubstitutor von Commons Text implementiert ist. Wir verwenden dann die String-Lookup-Funktion „script“, die die Payload mithilfe der JVM-Script-Execution-Engine (javax.script) ausführen kann.

Die erforderlichen Bedingungen für Text4Shell sind:

  • Die Anwendung verwendet Apache Commons Text, Version 1.5 bis einschließlich 1.9.
  • Die Anwendung importiert apache.commons.text.StringSubstitutor und verwendet einen der folgenden Standard-Interpolatoren in der Standard-Konfiguration:
    • dns
    • script
    • url

 

Unter diesen Voraussetzungen kann die folgende Payload verwendet werden, um die Sicherheitslücke auszunutzen und einen Remote-Host über einen Ping zu adressieren:

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

Wir können die oben erwähnte manipulierte Payload senden, um unser Ziel zu erreichen.

Wir können sehen, dass wir unseren Host vom Computer des Opfers aus erfolgreich anpingen können. Dabei gilt es zu beachten, dass wir nicht nur auf einen Ping beschränkt sind. Jede Betriebssystem-Anfrage ist an diesem Punkt eine mögliche Payload. Jeder Angreifer kann eine Reverse Shell öffnen oder andere Befehle ausführen, die auf dem Host verfügbar sind.

Wie unten dargestellt, haben wir eine effektive Shell auf dem Host.

Die Erkennung von Text4Shell mit Logpoint

Erforderliche Logdaten-Quellen

  • Firewall
  • – Server mit Apache Commons Text-Bibliothek
    • Sysmon für Linux
    • Auditd
    • Zugriffsprotokolle des Apache-Servers
  • Apache läuft unter Windows
    • Native Event-Logdaten
    • Sysmon

Da die Ausnutzung der Schwachstelle die Verwendung einer der oben aufgeführten zusätzlichen Suchmethoden erfordert, können wir nach diesen Funktionen in den URLs suchen, um die Exploit-Versuche zu erkennen.

(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*"])

Die Erkennung von Aktivitäten nach der Kompromittierung

Neben der Erkennung der Exploit-Versuche ist es äußerst wichtig, Aktivitäten nach der Kompromittierung zu erkennen. Es kann passieren, dass wir die Angriffe aus verschiedenen Gründen nicht erkennen. Daher müssen wir nach Spuren verdächtiger Aktivitäten Ausschau halten, die auf eine Kompromittierung hindeuten können. Hierzu zählen beispielsweise das Spawning einer Shell oder verdächtige ausgehende Verbindungen zu Remote-Hosts. Wir begannen die Suche nach verdächtigen Aktivitäten auf Basis der Hypothese, erste Aktivitäten zur Auskundschaftung von Systeminformationen sowie verdächtige Versuche zur Prozesserstellung und zur Befehlsausführung erkennen zu können.

Nachdem Angreifer eine Reverse Shell oder den Zugang zum System erhalten haben, versuchen sie möglicherweise, Systeminformationen zu erkunden. Dies können wir mit der folgenden Abfrage feststellen:

Für Unix-Systeme, die auditd für das Logging nutzen:

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"])     

Für Windows:

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

Wir können auch nach verdächtigen Prozessen suchen, die in Windows-Systemen erstellt werden. Je nach Umgebung kann es zu False-Positives (Fehlalarmen) kommen, die der Analyst herausfiltern muss.

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 

Falls Sie Sysmon auf Linux-Systemen einsetzen, können Sie das Spawning verdächtiger Prozesse wie folgt überwachen:

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 

Sofortige Abhilfemaßnahmen

Wir empfehlen Administratoren, Apache Commons Text so schnell wie möglich zu überprüfen und auf die neueste Version zu aktualisieren. Analysten sollten auch nach Post-Exploit-Spuren sowie nach verdächtigen Aktivitäten suchen, die im Zusammenhang mit Taktiken stehen, die wir bisher nicht vollständig behandelt haben. Das Logpoint-Team hat bereits Warnungen zur Erkennung verdächtiger Aktivitäten erstellt. Wir raten Analysten, diese Alerts zu nutzen und kontinuierlich nach schadhaften Aktivitäten Ausschau zu halten. Die aktive Suche nach Indikatoren für eine Kompromittierung (IoCs) sowie die Überprüfung verschiedener Hypothesen kann dabei unterstützen, Zero-Day-Schwachstellen aufzudecken. Mit Logpoint SOAR können Analysten die Prozesse der Überwachung, der Erkennung und der Abwehr von Bedrohungen automatisieren.

Wir werden den Blog-Beitrag aktualisieren, sobald sich die aktuelle Situation weiterentwickelt.

Contact Logpoint

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

Contact Logpoint