Wie bekannt ist, ist der im Enklaven ausgeführte Code stark in seiner Funktionalität eingeschränkt. Er kann keine Systemaufrufe durchführen. Er kann keine Ein- und Ausgabeoperationen ausführen. Er kennt die Basisadresse des Codesegments der Host-Anwendung nicht. Er kann den Code der Host-Anwendung nicht jmp'en oder call'en. Er hat keine Vorstellung von der Struktur des Adressraums, die die Host-Anwendung befolgt (z. B. welche Seiten gemappt sind oder welche Daten auf diesen Seiten gespeichert sind). Er kann das Betriebssystem nicht um das Mappen eines Speicherbereichs der Host-Anwendung bitten (z. B. über /proc/pid/maps). Naive Versuche, willkürlich einen Bereich des Speichers der Host-Anwendung blind zu lesen – geschweige denn Schreibversuche – führen früher oder später (eher zuerst) zum erzwungenen Beenden des Enklavprogramms. Das geschieht jedes Mal, wenn der angeforderte Bereich des virtuellen Adressraums im Enklaven für die Host-Anwendung nicht verfügbar ist.
Kann ein Virus-Autor unter solchen harten Bedingungen SGX-Enklaven für seine böswilligen Ziele nutzen?
Basierend auf all dem vorher Genannten wird angenommen, dass Enklaven nur in der Lage sind, die Host-Anwendung zu bedienen, und dass Enklaven keine eigene Initiative zeigen können, auch nicht böswillig. Daher stellen Enklaven für Malware-Autoren keinen praktischen Wert dar. Diese voreilige Annahme ist einer der Gründe, warum der SGX-Schutz asymmetrisch ist: Der Code der Host-Anwendung kann nicht auf den Enklaven-Speicher zugreifen, während der Enklaven-Code jeden Speicherort der Host-Anwendung lesen und schreiben kann.
Sollte es einem böswilligen Code gelingen, willkürliche Systemaufrufe im Namen der Hostanwendung durchzuführen, beliebigen Code auszuführen, den Speicher der Hostanwendung zu scannen und dabei ausbeutbare ROP-Ketten zu identifizieren, könnte er die volle Kontrolle über die Hostanwendung im Stealth-Modus übernehmen. Er könnte nicht nur Benutzerdateien stehlen und verschlüsseln, sondern auch im Namen des Benutzers handeln. Beispielsweise könnte er Phishing-E-Mails senden oder DoS-Angriffe durchführen, ohne sich vor den modernsten Schutzmechanismen wie Stack Canary und Address Space Layout Randomization (ASLR) fürchten zu müssen.
Wir zeigen Ihnen einige Tricks, mit denen Angreifer die oben beschriebenen Einschränkungen umgehen, um sich die Vorteile von SGX für ihre böswilligen Zwecke zunutze zu machen: zum Beispiel bei ROP-Angriffen. Entweder um beliebigen Code zu executen, der als Host-Anwendungsprozess maskiert ist (ähnlich wie bei Process Hollowing, das häufig von Malware verwendet wird), oder um bereits vorhandene Malware zu tarnen, damit sie sich vor Antivirusprogrammen und anderen Schutzmechanismen verstecken kann.
Trick zum Scannen von Adressen auf die Möglichkeit ihrer Lesbarkeit
Da der Enklave nicht bekannt ist, welche Bereiche des virtuellen Adressraums für die Hostanwendung verfügbar sind, und da bei dem Versuch, auf eine nicht verfügbare Adresse zuzugreifen, die Enklave zwangsweise beendet wird, stellt sich das Problem, eine Methode für ein ausfallsicheres Scannen des Adressraums zu finden. Eine Möglichkeit zur Erstellung einer Karte verfügbarer virtueller Adressen. Der Angreifer löst diese Aufgabe durch die nicht zielgerichtete Nutzung der Intel-Technologie TSX. Er nutzt einen der Nebeneffekte von TSX: Wenn die Speicherzugriffsbedingungen in eine TSX-Transaktion eingegeben werden, werden die Ausnahmen, die durch den Zugriff auf ungültige Adressen entstehen, von TSX unterdrückt, ohne das Betriebssystem zu erreichen. Bei dem Versuch, auf eine ungültige Speicheradresse zuzugreifen, wird nur die aktuelle Transaktion unterbrochen und nicht das gesamte Enklavenprogramm. Somit ermöglicht TSX der Enklave den sicheren Zugriff auf jede Adresse innerhalb der Transaktion, ohne das Risiko eines Absturzes.
Wenn Die angegebene Adresse ist verfügbar Im Host-Anwendungsfall endet eine TSX-Transaktion in der Regel erfolgreich. In seltenen Fällen kann sie aufgrund externer Einflüsse wie Unterbrechungen (z. B. Scheduler-Unterbrechungen), Cache-Dumping oder gleichzeitigen Änderungen einer Speicherzelle durch mehrere Prozesse fehlschlagen. In diesen seltenen Fällen gibt TSX einen Fehlercode zurück, der darauf hinweist, dass der aufgetretene Fehler vorübergehend ist. In diesen Fällen muss die Transaktion einfach erneut gestartet werden.
Wenn Die angegebene Adresse ist nicht verfügbar. Im Host-Anwendungsfall unterdrückt TSX die aufgetretene Ausnahme (das Betriebssystem wird nicht benachrichtigt) und bricht die Transaktion ab. Der Enklavencode erhält einen Fehlercode, um auf die Abbruchmeldung der Transaktion reagieren zu können. Diese Fehlercodes geben an, dass die angegebene Adresse für die Host-Anwendung nicht zugänglich ist.
Bei dieser Manipulation des TSX innerhalb des Enklaves gibt es eine angenehme Besonderheit für den Angreifer: Da zum Zeitpunkt der Ausführung des Enklavencodes die meisten Hardware-Leistungszähler nicht aktualisiert werden, können TSX-Transaktionen, die innerhalb des Enklaves durchgeführt werden, nicht verfolgt werden. Auf diese Weise bleiben böswillige Machenschaften mit TSX vollständig unsichtbar für das Betriebssystem.
Darüber hinaus ist der oben beschriebene Hack nicht auf systemeigene Aufrufe angewiesen, was bedeutet, dass er weder entdeckt noch verhindert werden kann, indem einfach systemeigene Aufrufe blockiert werden; dies führt normalerweise zu positiven Ergebnissen bei der Bekämpfung der 'Eierjagd'.
Der Angreifer nutzt den oben beschriebenen Hack, um im Code der Gastgeberanwendung Gadgets zu finden, die zur Bildung einer ROP-Kette geeignet sind. Dafür muss er nicht jede Adresse abfragen. Es reicht aus, eine Adresse von jeder Seite des virtuellen Adressraums zu sondieren. Das Abfragen aller 16 Gigabyte Speicher dauert etwa 45 Minuten (auf einem Intel i7-6700K). Am Ende erhält der Angreifer eine Liste von ausführbaren Seiten, die für den Aufbau einer ROP-Kette geeignet sind.
Hack zur Adressensondierung auf Schreibmöglichkeiten
Für die Durchführung einer Enklaven-ROP-Attacke benötigt der Angreifer die Fähigkeit, unverwendete, für das Schreiben zugängliche Speicherbereiche der Host-Anwendung zu finden. Der Angreifer nutzt diese Speicherbereiche, um einen gefälschten Stack-Frame zu injizieren und um Payload (Shellcode) einzubetten. Das Problem ist, dass die bösartige Enklave nicht in der Lage ist, von der Host-Anwendung Speicher anzufordern, sondern stattdessen bereits zugewiesene Speicherbereiche der Host-Anwendung missbrauchen kann. Vorausgesetzt, er kann solche Bereiche finden, ohne die Enklave zum Absturz zu bringen.
Der Angreifer führt diese Suche aus, indem er einen weiteren Nebeneffekt von TSX ausnutzt. Zunächst sondiert er, wie im vorherigen Fall, die Adresse auf ihre Existenz und überprüft dann, ob die entsprechende Seite für das Schreiben verfügbar ist. Dazu verwendet der Angreifer folgenden Hack: Er platziert die Schreibfunktion in eine TSX-Transaktion und bricht die Transaktion nach ihrer Ausführung, aber bevor sie abgeschlossen ist, absichtlich ab (explicit abort).
Wenn man den Rückgabecode einer TSX-Transaktion betrachtet, erkennt der Angreifer, ob sie schreibbar ist. Bei einem 'explicit abort' versteht der Angreifer, dass die Aufnahme erfolgreich gewesen wäre, hätte er sie bis zum Ende geführt. Ist die Seite jedoch nur schreibgeschützt, endet die Transaktion mit einem Fehler, der sich von einem 'explicit abort' unterscheidet.
Eine weitere interessante Eigenschaft solcher Manipulationen mit TSX für den Angreifer (neben der Unmöglichkeit, die Leistung über Hardwarezähler zu verfolgen) ist, dass alle Schreiboperationen im Speicher nur festgehalten werden, wenn die Transaktion erfolgreich ist. Ein erzwungener Abschluss der Transaktion garantiert also, dass die überprüfte Speicherzelle unverändert bleibt.
Trick zur Umleitung des Kontrollflusses
Bei der Durchführung eines ROP-Angriffs aus einem Enclave kann der Angreifer – im Gegensatz zu traditionellen ROP-Angriffen – die Kontrolle über das RIP-Register erlangen, ohne Schwachstellen im angegriffenen Programm auszunutzen (wie ein Buffer Overflow oder ähnliches). Der Angreifer kann direkt den Wert des RIP-Registers überschreiben, der auf dem Stack gespeichert ist. Insbesondere kann er den Wert dieses Registers durch seine ROP-Kette ersetzen.
Wenn jedoch die ROP-Kette lang ist, kann das Überschreiben eines großen Teils des Stacks der Host-Anwendung zu Datenbeschädigungen und unerwartetem Verhalten des Programms führen. Dies ist für einen Angreifer, der seine Attacke heimlich durchführen möchte, nicht akzeptabel. Daher erstellt er sich einen gefälschten temporären Stack-Frame und speichert seine ROP-Kette darin. Der gefälschte Stack-Frame wird an einem beliebigen, beschreibbaren Speicherort platziert, wodurch der echte Stack unberührt bleibt.
Was die drei oben genannten Hacks dem Angreifer bieten
(1) Zunächst sucht der böswillige Enklave durch einen Adress-Sondierungshack nach der Möglichkeit, sie auszulesen, um in der Host-Anwendung ROP-Gadgets zu finden, die ausgenutzt werden können.
(2) Danach identifiziert der böswillige Enklave mithilfe von einem Adress-Sondierungshack die Bereiche im Speicher der Host-Anwendung, die für das Injizieren von Payloads geeignet sind.(3) Schließlich erstellt der Enklave eine ROP-Kette aus den in Schritt (1) gefundenen Gadgets und injiziert diese Kette in den Stack der Host-Anwendung.
(3) Dann erstellt das Enklave eine ROP-Kette aus den Gadgets, die in Schritt (1) entdeckt wurden, und injiziert diese Kette in den Stack der Host-Anwendung.
(4) Sobald die Hosting-Anwendung auf die im vorherigen Schritt erstellte ROP-Kette stößt, beginnt die Ausführung der schädlichen Nutzlast – mit den Rechten der Hosting-Anwendung und der Möglichkeit, auf Systemaufrufe zuzugreifen.
Wie der Angreifer diese Hacks einsetzt, um Ransomware zu erstellen
Nachdem die Hosting-Anwendung die Kontrolle über den Enklave über einen der ECALLs übergibt (ohne zu bemerken, dass dieser Enklave bösartig ist), sucht der bösartige Enklave im Speicher der Hosting-Anwendung nach freiem Platz zum Injizieren von Code (freier Platz wird dabei als die Null gefüllten Speicherplätze betrachtet). Dann durch einen Adress-Sondierungshack nach der Möglichkeit, sie auszulesen, – findet der Enklave in der Hosting-Anwendung ausführbare Seiten und generiert eine ROP-Kette, die eine neue Datei mit dem Namen "RANSOM" im aktuellen Verzeichnis erstellt (bei einem echten Angriff verschlüsselt der Enklave vorhandene Benutzerdateien) und zeigt eine Nachricht mit der Aufforderung zur Zahlung eines Lösegelds an. Dabei geht die Hosting-Anwendung naiv davon aus, dass der Enklave einfach zwei Zahlen addiert. Wie sieht das im Code aus?
Zur besseren Verständlichkeit führen wir über Defines eine Mnemonik ein:
Wir speichern die ursprünglichen Werte der Register RSP und RBP, um nach der Ausführung der Payload die normale Funktion der Host-Anwendung wiederherzustellen:
Wir suchen nach einem geeigneten Stack-Rahmen (siehe den Code im Abschnitt „Trick zur Umleitung des Kontrollflusses“).
Wir finden passende ROP-Gadgets:
Wir suchen nach einem Ort für das Injizieren der Payload:
Wir bauen die ROP-Kette:
So wird die Intel-Technologie SGX, die gegen Schadsoftware geschützt werden soll, von Angreifern ausgenutzt, um gegenteilige Ziele zu erreichen.
Quelle: habr.com
