Über Speicherkorruptionsschwachstellen hinaus – Sicherheitsprobleme und die Ausnutzungstechniken der Zukunft

Von Chintan Shah · 24. Januar 2022

Durch moderne Ausnutzungstechniken hat sich die Art und Weise verändert, wie Bedrohungsakteure ihre Angriffsstrategien umsetzen und Sicherheitsverantwortliche den Weg von der Schwachstelle bis Ausnutzung analysieren. In den letzten 10 Jahren wurde ein starker Fokus auf die Verbesserung der Sicherheit auf der allgemeinen Betriebssystem- und Anwendungsebene gelegt, was zu beträchtlichen Fortschritten bei der Implementierung von Schutzmechanismen für verschiedene Exploits geführt hat. Durch diesen Fortschritt sind in manchen Fällen ganze Klassen von Speicherkorruptionsschwachstellen eliminiert worden. Use-After-Free (UAF) ist beispielsweise eine in großen, komplexen Code-Basen wie Web-Browsern sehr geläufige Schwachstellenkategorie. Da sie sich einfach ausnutzen lässt, hat Microsoft einen isolierten Heap eingeführt und die Freigabe von Objekten in seiner Browser-Engine (mshtml.dll) verzögert. Die UAF-Ausnutzungskette wurde gebrochen und Bedrohungsakteure werden zur Umgestaltung der Exploits gezwungen, wenn sie diese Hürden überwinden möchten. Abbildung 1 unten enthält den Teil des Codes, wo die Änderung zur Vermeidung von UAF-Schwachstellen eingeführt wurde.

Der Unterschied zwischen dem Code mit und ohne Schutz ist klar zu sehen. Das war zwar nur die Spitze des Eisbergs, doch Angreifern wurde das Ausnutzen von UAF-Schwachstellen deutlich erschwert, da sie auch bestimmte Timing-Beschränkungen und Speicherschwellenwerte bewältigen müssen. Abbildung 2 unten enthält eine einfache visuelle Darstellung der Maßnahmen zum Schutz vor Speicher-Exploits, die in den letzten 10 Jahren für das Windows-Betriebssystem eingeführt wurden.

Diese Exploit-Schutzmaßnahmen konnten jedoch kurz nach ihrer Einführung immer wieder umgangen werden, was primär darauf zurückzuführen ist, dass der gesamte Code (einschließlich des abhängigen und Drittanbieter-Codes) entweder nicht mit den im Compiler aktivierten Schutzmaßnahmen kompatibel war oder nicht mit ihnen kompiliert wurde. Das bedeutet im Grunde, dass die Exploit-Schutzmaßnahmen nicht in allen Code-Teilen erzwungen oder die Schutzmaßnahmen selbst nicht vollständig implementiert wurden – und das hat zu Lücken geführt, die wiederum ausgenutzt werden konnten. Der Darstellung oben ist beispielsweise zu entnehmen, dass ASLR nicht von Beginn an komplett implementiert wurde, sondern in Phasen. Dadurch war ein Großteil des Codes nach wie vor für Umgehungen anfällig.

Speicherkorruptionsschwachstellen: Gehören sie bald der Vergangenheit an?

Speicherkorruptionsschwachstellen sind zwar nach wie vor die am häufigsten gemeldete Fehlerklasse, in den letzten Jahren ist es aufgrund der auf Betriebssystem- und Client-seitiger Anwendungsebene eingeführten Exploit-Schutzvorkehrungen (z. B. Skript-Modulen) aber zu einer Herausforderung geworden, diese Schwachstellen für vollwertige Exploit-Angriffe zu nutzen. Zum Ausnutzen von Speicherkorruptionsschwachstellen für voll ausgearbeitete Exploits, die die Ausführung von beliebigem Code erlauben, müssen mehrere Schutzmaßnahmen umgangen werden, ohne die Schutz- oder Erkennungsmechanismen von Endpunktsicherheitslösungen zu triggern. Das bedeutet, dass es für Bedrohungsakteure jetzt anstrengender, zeitaufwendiger und kostenintensiver ist, Möglichkeiten zur Umgehung von Exploit-Sicherheitsmaßnahmen zu finden. Gelegentlich müssen Bedrohungsakteure unter Umständen mehrere Schwachstellen kombinieren, um ein tatsächliches Exploit auf einem Zielsystem ausführen zu können. Dadurch steigen die Entwicklungskosten deutlich und die Ausnutzung wird wiederum erschwert.

Wir glauben, dass die Weiterentwicklung von Exploit-Schutzmaßnahmen von entscheidender Bedeutung sein wird, wenn es darum geht, welche Arten von Schwachstellen für Bedrohungsakteure in Zukunft interessant sein werden. Die Frage, ob es überhaupt noch Speicherkorruptionsschwachstellen geben wird, ist strittig und erfordert eine gewisse Reflexion.

Die Ausnutzungsstrategien der Zukunft: Was erwartet uns?

Speicherkorruptionsschwachstellen werden so lange in Anwendungen bestehen, wie es Code in den Anwendungen gibt, der zu einer nicht ordnungsgemäßen Speicherverarbeitung führt. Das Ausmaß und die Häufigkeit der Ausnutzung von Schwachstellen dieser Art werden jedoch abklingen. Wir haben in der Vergangenheit mehrere Ausnutzungstechniken gesehen, bei denen Angreifer beliebige Lese-/Schreibvorgänge im Speicher ausführen konnten, indem sie eine Speicherkorruptionsschwachstelle ausnutzten und dies dann dazu verwendeten, bestimmte Flags oder Daten im Anwendungsspeicher zu ändern, um anschließend Code auszuführen. Diese Reihe von Methoden, die als "Data-Only-Angriffe" bezeichnet werden, waren relativ einfache Strategien, die bei vielen Exploits zum Einsatz kamen. Die Randomisierung bestimmter kritischer Datenstruktur-Speicherorte im Speicher hat diese Art von Angriffen im Laufe der Zeit schließlich reduziert.

Bei funktionsreichen Anwendungen werden Angreifer immer auf der Suche nach den einfacheren Strategien für die Code-Ausführung auf dem Zielsystem sein. Es gibt immer ältere Systeme mit Anbindung an das Internet, die für Angreifer den Weg des geringsten Widerstands darstellen, da die eingeführten Schutzmaßnahmen für sie nicht implementiert sind. Eine der Zukunftsmethoden in diesem Bereich besteht jedoch im Missbrauch von Funktions- oder Designschwachstellen in der Anwendung oder im Netzwerkprotokoll. Wenn Bedrohungsakteure Möglichkeiten zum Missbrauchen des inhärenten Designs oder der Funktionen einer Zielanwendung finden und so beispielsweise dafür sorgen, dass die Anwendung oder ein Service sich ohne explizite Speicherkoordinierung mit einer vom Angreifer kontrollierten Maschine verbindet, gestaltet sich die Remote-Code-Ausführung relativ einfach und es kann ziemlich leicht Schaden auf der Zielmaschine angerichtet werden – denn es ist ganz dem Angreifer überlassen, welche Funktion der beliebige Code hat, der durch den ausgenutzten Prozess ausgeführt wird. Abbildung 3 unten enthält eine vereinfachte Darstellung der Entwicklung von Ausnutzungsstrategien in den letzten Jahren.

Wir konnten in den letzten Jahren mehrfach sowohl Data-Only-Angriffe als auch den Missbrauch von Funktions- bzw. Designschwachstellen beobachten. Diese Vorgehensweisen bieten verschiedene Vorteile im Vergleich zu den klassischen Speicherkorruptions-Exploits. Hier einige der Gründe, aus denen wir glauben, dass das die Ausnutzungsstrategie der Zukunft sein wird:

• Möglichkeiten zur Umgehung bestehender Exploit-Schutzmaßnahmen, weshalb Bedrohungsakteure Exploits nicht speziell so konzipieren müssen, dass diese Hürden überwunden werden
• Ausführung von beliebigem Code mit den Berechtigungen des ausgenutzten Prozesses, was für die Erhöhung der Berechtigungen hilfreich ist
• Keine Berücksichtigung der expliziten Speichermanipulations- und Platzbeschränkungen vor Ausnutzung der Schwachstelle erforderlich, wenn Exploits auf anwendungsinterne Funktions- oder Designschwachstellen abzielen, und demnach Eliminierung der Shellcode-Injektion im Speicher und der älteren Stack-Pivoting-Techniken
• Relativ einfache Ausnutzung mit niedrigeren Entwicklungs-/Wartungskosten und weniger Zeitaufwand bis zum Angriff

Der Rückblick auf kritische Schwachstellen in den letzten Quartalen kann einen eindeutigen Hinweis darauf liefern, wie die Angriffe der Zukunft aussehen werden. In den folgenden Abschnitten werfen wir einen Blick auf einige der jüngsten Schwachstellen mit hohem Schadenspotenzial. Wir sehen uns an, wie die Funktions- oder Designschwachstellen im Service oder in der Anwendung missbraucht wurden, um ohne großen Widerstand Code auszuführen oder sensible Daten offenzulegen.

CVE-2021-44228: Schwachstelle in der Apache Log4j2-Protokollierungsbibliothek mit Remote-Code-Ausführung als Folge

Die Remote-Code-Ausführungsschwachstelle in der Log4j-Protokollierungsbibliothek von Apache ist einer der kritischsten Mängel, die in den letzten Jahren gemeldet wurden. Angreifer sind dadurch in der Lage, beliebigen Code auf dem anfälligen Server auszuführen, der die Log4j-Protokollierungsbibliothek zum Protokollieren von Textnachrichten nutzt. In einem früheren Blog-Beitrag sind wir detailliert darauf eingegangen, wie Open-Source-Software als Baustein der modernen Software-Entwicklung fungiert und wie wichtig es ist, diese zu prüfen, da bestehende Schwachstellen beträchtliche Auswirkungen auf die Produkte haben können, die die Software nutzen.

Die Schwachstelle liegt in der "Lookup"-Methode der "jndimanager"-Klasse. When the JNDI URL is included in the request message parameter to be logged by log4j, the apache\logging\log4j\core\lookup\JndiLookup.lookup () method is called with the JNDI URL which in turn calls the net\JndiManager.lookup () method as shown in figure 3 below, leading to the initiation of the remote JNDI lookup to the attacker controlled server. Das ermöglicht es dem vom Angreifer gesteuerten Server, eine böswillige JNDI-Referenz in der Antwort zu senden, was die Ausführung beliebigen Codes auf dem anfälligen Server zur Folge hat.

Ermöglicht wurde diese Remote-Code-Ausführung, weil Java mehrere JNDI-Service-Anbieter (Java Naming Directory Interface) wie LDAP, DNS, RMI und CORBA implementiert. Je nach festgelegten Standard-Systemeigenschaften war auch das Laden von Remote-Klassen möglich.

CVE-2021-44228 ist ein klassisches Beispiel für eine Funktionsausnutzung. Die hier missbrauchte Funktion war die Lookup-Ersetzung, die Lookups unterstützt. Lookups sind eine Möglichkeit zum Hinzufügen von Werten zu Protokollnachrichten. Dabei handelt es sich in der Regel um Variablennamen, die durch eine definierte Zuordnung oder zur Laufzeit mit implementierten Schnittstellen aufgelöst werden, wie StrSubstitutor- und StrLookup-Klassen.

Log4j unterstützt die Eigenschaftssyntax "${prefix:name}", wo das Präfix Log4j mitteilt, dass der Variablenname im spezifischen Kontext evaluiert werden sollte. Der JNDI-Kontext ist wie unten gezeigt in Log4j integriert.

Da JNDI-Lookups in der Log4j-Version 2.14.1 und früheren Versionen (siehe Abbildung 6) standardmäßig aktiviert waren, konnte die Bibliothek die JNDI-Referenzen erkennen, die als Parameterwert in den auf dem Server protokollierten HTTP-Anfrage-Headern übergeben wurden. Demnach konnten Angreifer böswillige JNDI-Referenzen in die HTTP-Anfrageparameter injizieren und damit eine Remote-Java-Code-Ausführung verursachen.

CVE-2021-34527: Schwachstelle im Druckerspooler von Windows mit Remote-Code-Ausführung als Folge

Die privilegierte Remote-Code-Ausführungsschwachstelle in spoolsv.exe namens PrintNightmare war eine weitere kritische Schwachstelle, die letztes Jahr gemeldet wurde. Sie ist ein gutes Beispiel dafür, wie ein Designfehler im Protokoll ausgenutzt werden kann, um beliebigen Code auf der Zielmaschine auszuführen, ohne etwas am Speicher zu tun.

Die Schwachstelle wurde über das Print System Remote Protocol (MS-RPRN) und das Print System Asynchronous Remote Protcol (MS-PAR) mithilfe von RPC-Aufrufen über SMB ausgenutzt. Das Exploit macht sich eine klassische Designschwachstelle in der Implementierung der Druckserverkomponente im Spooler-Service zunutze, wenn RPC-Anfragen an die MS-PRN- und MS-PAR-Schnittstellen ausgegeben werden, um die Druckertreiber auf dem Zielsystem zu installieren. Beim RPC-Aufruf an RpcAddPrinterDriverEx (MS-RPRN Opnum 89) oder RpcAsyncAddPrinterDriver (MS-PAR Opnum 39) muss die DRIVER_CONTAINER-Struktur als Argument übergeben werden.

Wie in den Strukturdetails oben angegeben enthält DRIVER_CONTAINER pDriverPath und pConfigFile, wobei es sich um den vollständigen Pfad des Dateinamens handelt, der den Druckertreiber bzw. das Konfigurationsmodul enthält. Sowohl pDriverPath als auch pConfigFile werden auf den UNC-Pfad überprüft, um das Laden von beliebigem Code zu verhindern.

Die Design- oder Logikschwachstelle ist hier, dass die gleiche UNC-Pfadprüfung nicht auf pDataFile angewendet wird, wobei es sich um den vollständigen Pfad der Datei mit den Druckerdaten handelt. Ein Bedrohungsakteur konnte mehrere Aufrufe an RpcAddPrinterDriverEx mit Folgendem ausgeben:

1. pDataFile als UNC-Pfad der böswilligen DLL, die für die Zielmaschine zugänglich ist und bei Erfolg lokal auf die Zielmaschine kopiert wird
2. Zuweisung der gleichen API mit dem Namen der kopierten Datei zu pConfigFile (dieses Mal ist die böswillige DLL der lokale Pfad), was zum Laden von böswilligem Code durch den Druckerspooler-Service führt

CVE-2021-36942: LSA-Spoofing-Schwachstelle in Windows mit Offenlegung von Anmeldedaten als Folge

RPC über SMB war immer Spitzenreiter bei vielen Ausnutzungsmethoden. Diese Schwachstelle konnte wieder durch Missbrauch des MS-EFSRPC-Protokolls ausgenutzt werden, das in Windows zum Verwalten der Dateien auf dem Remote-System und mit Verschlüsselung durch Encrypting File System (EFS) verwendet wird.

Durch spezifische RPC-Aufrufe wie EfsRpcOpenFileRaw über die LSARPC-Schnittstelle kann der Angreifer dafür sorgen, dass ein Windows-Host sich bei einem anderen Server authentifiziert. Das bedeutet im Grunde, dass dafür gesorgt werden kann, dass ein Ziel-Server sich mittels NTLM-Authentifizierung bei einem durch den Angreifer kontrollierten Server authentifiziert. Vor allem kann LSARPC ohne vorangehende Authentifizierung mit RPC-Aufrufen ausgegeben werden und wenn der Ziel-Server Active Directory (AD) ist, dann kann der Angreifer bewirken, dass AD sich unter Verwendung des Maschinenkontos für die NTLM-Authentifizierung mit dem beliebigen Server verbindet. Dieses EFSRPC-Protokoll kann zum Verketten mehrerer Schwachstellen im Unternehmensnetzwerk mit dem Ziel der Weitergabe von NTLM-Anmeldedaten an einen vom Angreifer kontrollierten Server missbraucht werden. Durch laterale Bewegung mithilfe dieser Anmeldedaten könnte dann die gesamte Domäne kompromittiert werden.

Wenn der Bedrohungsakteur einen IIS-Web-Server kontrolliert, auf dem die Active Directory-Zertifikatdienste (Active Directory Certificate Services, AD CS) installiert sind und der so konfiguriert ist, dass NTLM-Authentifizierung über HTTP verwendet wird, kann die Active Directory-Authentifizierung bei IIS zur Offenlegung der NTLM-Anmeldedaten gegenüber dem Angreifer führen, was eine vollständige Domänenkompromittierung zur Folge hat. Angriffe durch NTLM-Weitergabe sind nichts Neues und es wird empfohlen, sicherere Authentifizierungsmechanismen wie Kerberos zu verwenden, um einen derartigen Protokollmissbrauch zu vermeiden.

Zusammenfassend kann gesagt werden, dass der Missbrauch eines Protokolls oder einer Funktion mit dem Ziel, eine Verbindung einer wichtigen Ressource mit einem externen, vom Bedrohungsakteur kontrollierten Server herzustellen, gefährliche Folgen nach sich zieht, wie es die Log4j-Schwachstelle CVE-2021-44228 gezeigt hat.

CVE-2021-40444: Windows MSHTML-Schwachstelle mit Remote-Code-Ausführung als Folge

Das war eine weitere kritische Schwachstelle, die im letzten Jahr ausgenutzt wurde. Sie ist ein gutes Beispiel dafür, wie ein einfacher Funktionsmissbrauch mit einem Logikfehler kombiniert werden kann, um beliebigen Code ausführen zu können. Zuerst wurde Object Linking and Embedding (OLE) verwendet, um das Dokument mit dem externen OLE-Objekt zu verbinden. OLE spielt schon seit Langem eine bedeutende Rolle bei der Erstellung von Office-Exploits für Angriffe und das wird auch weiterhin der Fall sein, da es sich hier um eine der Kernfunktionen des Microsoft Office-Dateiformats speziell zum Gewährleisten der Interoperabilität handelt.

Microsoft Office Open XML-Spezifikationen erlauben einem Dokument die Einbettung oder Verknüpfung mit internen oder externen Objekten und insbesondere die Verknüpfung mit dem externen OLE-Objekt ist über Beziehungen angegeben. Das wird im erstellten Exploit-Dokument unten veranschaulicht, wo für die Datei document.xml.rels als Type-Attribut "oleObject", als Target-Attribut die OLE-Objektverknüpfung und der TargetMode als extern definiert ist. So kann sich das erstellte Dokument mit dem extern gehosteten böswilligen Objekt verknüpfen und das entsprechende Protokoll bzw. die entsprechenden Ressourcen-Handler zum Rendern des Objekts aufrufen, um einen potenziellen Logik- bzw. Designfehler im Handler auszunutzen. Dies ist eine typische OOXML-Vorlageninjektionstechnik, die früher bei vielen OOXML-Exploits zum Einsatz kam. In einem früheren Blog-Beitrag haben wir uns detailliert mit OLE-Exploits befasst.

Die HTML-Code-Verarbeitung erfolgt in mshtml.dll, während HTTP-Protokoll und MSHTML-Downloads in urlmon.dll auf Vertrauenswürdigkeit überprüft und auch darin verwaltet werden. Die Designschwachstelle im urlmon.dll-Code stand in Verbindung mit der Extrahierung und Vertrauenswürdigkeitsprüfung der heruntergeladenen CAB-Datei. Die CAB-Datei wurde über JavaScript-Code heruntergeladen, der in die Seite side.html eingebettet war, wie in Abbildung 11 oben gezeigt. Aufgrund der fehlenden Pfad-Escape-Prüfungen während der Extrahierung der CAB-Datei konnte das Exploit die Datei innerhalb der CAB mit dem relativen Pfad extrahieren, wie in Abbildung 12 unten gezeigt. Das führte dazu, dass die böswilligen Schaddaten außerhalb des erstellten TEMP-Verzeichnisses abgelegt wurden und schlussendlich ausgeführt werden konnten.

Fazit

In den letzten Jahren hat es bei Schwachstellen wie den oben beschriebenen CVE-2021-44228, CVE-2021-34527, CVE-2021-36942 und CVE-2021-40444 einen Trend gegeben, dass sie sich inhärente Verarbeitungsfehler zunutze machen und in erster Linie Funktionen missbrauchen. Speicherkorruptionsschwachstellen wird es zwar so lange geben, wie es unsicheren Code in nicht speichersicheren Sprachen gibt, die sich von Rust unterscheiden, wir erwarten aber, dass der Ausnutzungstrend sich eher in Richtung Ausnutzung von Design- oder Logikfehlern und Protokollmissbrauch verlagern wird. Verbraucher und Entwickler von Open-Source-Software müssen achtsamer sein, da diese Mängel es Angreifern ermöglichen werden, ihr ursprüngliches Ziel auf Systemebene zu erreichen – nämlich sich innerhalb des Netzwerks zu bewegen, ohne sich um die gestaffelten Sicherheitsmaßnahmen jüngst ausgereifter Vorkehrungen zum Schutz vor Speicher-Exploits kümmern zu müssen.