Bug-Report – Ausgabe Juni 2022

Warum treten kritische Schwachstellen immer während der Urlaubszeit auf? CVE-2022-26134 tauchte zum Beispiel genau um den amerikanischen Memorial Day auf, als die meisten Amerikaner ein langes Wochenende genossen und nicht an Technologie denken wollten. Tja, Bugs wie diese sorgen immer wieder dafür, dass der Urlaub abrupt endet.

Aber genug gejammert, schauen wir uns an, wer im Juni das Rennen anführte. Die Bugs des Monats Juni sind:

• CVE-2022-26134 – OGNL injection vulnerability in Atlassian Confluence
• CVE-2022-30190 – Zero Click Microsoft Support Diagnostic Tool Vulnerability: „Follina“
• CVE-2022-22980 – SpEL injection via parameter placeholder expressions

CVE-2022-26134: ${ return this.JavaVuln++; }

Worum handelt es sich?

Im Kern steckt hinter CVE-2022-26134 eine nicht authentifizierte Befehlsinjektion direkt in einem Java-Interpreter. Konkret wird eine Sicherheitslücke in der Java-Ausdruckssprache Object-Graph Navigation Language (OGNL) ausgenutzt. Während bei den meisten Bugs langwierige Erklärungen und technische Details notwendig sind, lässt sich dieser Exploit am besten verstehen, wenn man sich einfach mal die Exploit-Payload ansieht.

Abb. 1: CVE-2022-26134-Demo mittels cURL (codiert)

Für alle, die ASCII-Hex-Code nicht nativ sprechen:

Abb. 2: CVE-2022-26134-Demo mittels cURL (ASCII)

Und? Die Exploit-Anfrage ist jedenfalls deutlich leichter zu verstehen als OGNL. 

Aber lassen Sie Nerds wie mir die Freude, zu erklären, wie dieser Bug funktioniert und warum er so bestechend simpel ist. In kurz: Der vom Nutzer bereitgestellte URI kommt bei dem Auswerter für OGNL-Ausdrücke an, der dann die Auflösung etwaiger im URI enthaltenen Variablen durchführt. Diese können wiederum zur Ausführung von Java-Code verwendet werden.

Wichtig ist dabei, dass diese Schwachstelle einen nicht authentifizierten Zugriff zulässt und mit den Berechtigungen des Confluence-Servers ausgeführt wird – hoffentlich nicht mit Root-Rechten … 

Wer ist betroffen?

Da das Ausnutzen der Sicherheitslücke so einfach ist, sind im Web schon jetzt zahllose POCs zu finden. Sowie auch in diesem Bug Report einer enthalten ist. Eine aktive Ausnutzung der Schwachstelle wurde bereits beobachtet und wird auch weiter zu beobachten sein. Umso mehr, da Confluence leider immer noch auf manuelle Updates setzt. Und weil da draußen noch immer so viele ungepatchte Systeme existieren, dürften uns Angriffsversuche mittels CVE-2022-26134 noch ziemlich lange beschäftigen.

Eine kurze Shodan-Suche zeigt, dass es rund 13.000 öffentlich zugängliche Confluence-Server gibt. Da Confluence oft in Unternehmen genutzt wird, empfiehlt es sich, diese Sicherheitslücke nicht auf die leichte Schulter zu nehmen.

Abb. 3: Resultate einer Suche nach Confluence-Servern auf Shodan.io

Was kann ich tun?

Patching ist das Mittel der Wahl. Wenn ein vollständiges Update des Confluence-Servers nicht machbar ist, können Sie die angreifbaren .jar-Dateien manuell patchen, indem Sie sie hier herunterladen und im Confluence-Installationsverzeichnis überschreiben. Vorher sollten die aktuellen Dateien natürlich gesichert werden! Wenn Sie nicht genau wissen, wo Ihr Confluence-Server steht, kann auch ein Markieren/Blockieren eines URI mit der Zeichenfolge „${“ von Nutzen sein.

CVE-2022-30190: Trouble mit dem MS Troubleshooter

Worum handelt es sich?

CVE-2022-30190, Spitzname „Follina“, wurde erstmals in einem Upload auf VirusTotal nachgewiesen. Durch diesen Upload und den nachstehenden Twitter-Post wurde die Welt auf die Zero-Day-Schwachstelle aufmerksam.

Abb. 4: MSDT troubleshooter argument command injection

Über die Remote-Template-Funktion von Microsoft Word kann ein manipuliertes Dokument genutzt werden, um den „ms-mdt:/“-Abschnitt des Remote-URL über den Protokoll-Handler von Windows aufzulösen. Danach wird der URL direkt an das Microsoft Support Diagnostic Tool (msdt.exe) weitergeleitet. Die eigentliche Schwachstelle liegt im „IT-BrowseForFile“-Argument des MSDT-Tools, wenn es von PowerShell geparst wird. Als Resultat kann alles, was normalerweise mit PowerShell machbar ist, über den „IT-BrowseForFile“-Parameter auch von Follina veranlasst werden.

Wer ist betroffen?

Diese Schwachstelle betrifft alle Versionen von Office 365 sowie die nicht Cloud-basierten Office-Versionen ab 2013 bis 2021 – und zwar auch dann, wenn Makros deaktiviert wurden. Die geschützte Ansicht in MS Office bietet anscheinend Schutz vor Follina, allerdings nur, wenn das Dokument nicht im RTF-Format gespeichert wird. Öfnnen Sie also keine unbekannten Dateien, bis Ihre Umgebung vollständig gepatcht ist.

Diese CVE ist ein echter Zero-Day-Exploit, der in freier Wildbahn bereits aktiv ausgenutzt wird. Zahlreiche Ransomware-Kriminelle versuchen, mit Follina schnelles Geld zu machen. Wir werden diese Schwachstelle natürlich weiter beobachten.

Was kann ich tun?

Die beste Verteidigungsstrategie besteht in der Installation des offiziellen Patches, den Microsoft hier veröffentlicht hat. Ein Patchen ist nicht möglich? Wenn es nicht anders geht, hilft dieser offizielle Workaround gegen Follina:

1. Führen Sie die Eingabeaufforderung als Administrator aus.
2. Zur Sicherung des Registry-Schlüssels führen Sie den Befehl „reg export HKEY_CLASSES_ROOT\ms-msdt filename“ aus.
3. Führen Sie dann den Befehl „reg delete HKEY_CLASSES_ROOT\ms-msdt /f“ aus.

Der obige Workaround verhindert die Auflösung von „ms-msdt:/“- URLs.

CVE-2022-22980: Nicht schon wieder Spring4shell!

Worum handelt es sich?

CVE-2022-22980 ist die jüngste Sicherheitslücke im Spring-Framework und weist verblüffende Ähnlichkeit mit den Spring4Shell-Schwachstellen auf, die in der ersten Jahreshälfte öffentlich gemacht wurden. Wie bei Spring4Shell erfolgt der Angriff auch hier über eine SpEL-Injektion (Spring Expression Language), mit der Code auf dem Remote-Host ausgeführt wird. Eine Schlüsselrolle spielen dabei die Abfragemethoden „@Query“ und „@Aggregation-annotated“. Sie sind nur dann angreifbar, wenn die vom Nutzer bereitgestellten Daten nicht überprüft werden, bevor sie über Platzhalter in Abfrageparametern gebunden werden. Für den SpEL-Laien (wie ich einer bin) präsentieren sich die Abfrageparameter-Platzhalter als „o.owner.id = ?#{ some-expression }“ anstelle der Verwendung eines statischen Parameters, auf den mit „o.owener.id = [1]“ zugegriffen wird. Weitere Einzelheiten zu Parameter-Platzhalterausdrücken können Sie hier nachlesen. Wie also funktioniert der Exploit? Wenn ein Platzhalter eine Nutzereingabe direkt und ohne Prüfung verarbeitet, führt die Verwundbarkeitzu einer Ausführung von Java-Code, wie der untenstehende POC zeigt.

Abb. 5: Proof of concept exploit opening calculator for CVE-2022-22980

Wer ist betroffen?

Wenn Sie von den Spring4Shell-Schwachstellen der vergangenen Monate betroffen waren, sollten Sie auch diesen CVE auf dem Schirm haben. So langsam wird es zu einer liebgewordenen Gewohnheit, alle Java-Systeme einmal pro Monat zu patchen …

Wenn Sie also eine Anwendung ausführen, die Spring Data MongoDB V3.4.0 oder V3.3.0-V3.3.4 verwendet, sind Sie vermutlich gefährdet.

Was kann ich tun?

Auf die Gefahr hin, dass es langweilig wird: Der erste Schritt sollte darin bestehen, Spring Data MongoDB mit einem Patch auf 3.4.1+ oder 3.3.5+ zu aktualisieren. Wenn ein Patching in Ihrer Umgebung nicht möglich ist, können Sie selbst aktiv werden, indem sie als statische Parameterverweise „[1]“ anstelle von „?l“ verwenden und Nutzereingaben vor der Abfragemethode auf Unschädlichkeit überprüfen. Als letzte Verteidigungslinie gibt VMWare den kryptischen Hinweis: „Reconfigure the repository factory bean through a BeanPostProcessor with a limited QueryMethodEvaluationContextProvider“. Sie finden ihn auf der VMWare-Seite zu sicherheitsrelevanten Ereignissen. Vermutlich gibt es jemanden, der weiß, was ein „factory bean“ ist – ich weiß es jedenfalls nicht. Klingt aber gut.

www.trellix.com/de