Wie Sie wissen, ist der in der Enklave ausgeführte Code in seiner Funktionalität stark eingeschränkt. Es können keine Systemaufrufe durchgeführt werden. Es können keine E/A-Vorgänge ausgeführt werden. Die Basisadresse des Codesegments der Hostanwendung ist ihm nicht bekannt. Es kann keinen Host-Anwendungscode jmpen oder aufrufen. Es hat keine Ahnung von der Adressraumstruktur, die die Hostanwendung steuert (z. B. welche Seiten zugeordnet sind oder welche Art von Daten sich auf diesen Seiten befinden). Es kann das Betriebssystem nicht auffordern, ihm einen Teil des Speichers der Hostanwendung zuzuordnen (z. B. über /proc/pid/maps). Naive Versuche, einen beliebigen Speicherbereich einer Host-Anwendung blind zu lesen, ganz zu schweigen von Schreibversuchen, werden früher oder später (höchstwahrscheinlich ersteres) zur erzwungenen Beendigung des Enklavenprogramms führen. Dies geschieht immer dann, wenn der von der Enklave angeforderte virtuelle Adressraumbereich für die Hostanwendung nicht zugänglich ist.
Wird ein Virenschreiber angesichts dieser harten Realität in der Lage sein, SGX-Enklaven zu nutzen, um seine böswilligen Ziele zu erreichen?
Auf der Grundlage all dessen wird allgemein anerkannt, dass eine Enklave nur die Host-Anwendung bedienen kann und dass die Enklave keine eigene Initiative, auch keine böswillige, ausüben kann. Das bedeutet, dass Enklaven für Virenschreiber keinen praktischen Wert haben. Diese voreilige Annahme ist einer der Gründe, warum der SGX-Schutz asymmetrisch ist: Host-Anwendungscode kann nicht auf den Enclave-Speicher zugreifen, während Enclave-Code jede Speicheradresse der Host-Anwendung lesen und schreiben kann.
Wenn also bösartiger Enklavencode in der Lage wäre, im Namen der Host-Anwendung beliebige Systemaufrufe durchzuführen, in ihrem Namen beliebigen Code auszuführen, den Speicher der Host-Anwendung zu scannen und darin missbräuchliche ROP-Ketten zu finden, könnte er die vollständige Kontrolle über die Host-Anwendung übernehmen Stealth-Modus. Es kann nicht nur Benutzerdateien stehlen und verschlüsseln, sondern auch im Namen des Benutzers agieren. Versenden Sie beispielsweise in seinem Namen Phishing-E-Mails oder führen Sie DoS-Angriffe durch. Ohne Angst vor den modernsten Schutzmechanismen wie Stapelkanarien und Adressdesinfektion.
Wir zeigen Ihnen einige Hacks, mit denen Angreifer die oben beschriebenen Einschränkungen überwinden und SGX für ihre eigenen böswilligen Zwecke ausnutzen können: ROP-Angriffe. Entweder um willkürlichen Code auszuführen, der als Host-Anwendungsprozess getarnt ist (ähnlich dem Process Hollowing, das häufig von Malware verwendet wird), oder um eine fertige Malware zu verschleiern (um ihre Malware vor der Verfolgung durch Antivirenprogramme und andere Abwehrmechanismen zu schützen).
Hack zum Prüfen von Adressen, um zu sehen, ob sie gelesen werden können
Da die Enklave nicht weiß, welche Bereiche des virtuellen Adressraums für die Host-Anwendung zugänglich sind, und da die Enklave beim Versuch, eine unzugängliche Adresse zu lesen, zum Beenden gezwungen wird, steht der Angreifer vor der Aufgabe, einen Weg zu finden, Fehler zu beheben. Scannen Sie den Adressraum tolerant. Finden Sie eine Möglichkeit, verfügbare virtuelle Adressen abzubilden. Der Bösewicht löst dieses Problem, indem er die TSX-Technologie von Intel missbraucht. Nutzt einen der Nebeneffekte von TSX: Wenn die Speicherzugriffsfunktion in einer TSX-Transaktion platziert wird, werden Ausnahmen, die durch den Zugriff auf ungültige Adressen entstehen, von TSX unterdrückt, ohne das Betriebssystem zu erreichen. Wenn versucht wird, auf eine ungültige Speicheradresse zuzugreifen, wird nur die aktuelle Transaktion abgebrochen, nicht das gesamte Enklavenprogramm. Das. TSX ermöglicht einer Enklave den sicheren Zugriff auf jede Adresse innerhalb einer Transaktion – ohne das Risiko eines Zusammenbruchs.
wenn Die angegebene Adresse ist verfügbar Host-Anwendung ist die TSX-Transaktion meistens erfolgreich. In seltenen Fällen kann es aufgrund externer Einflüsse wie Interrupts (z. B. Scheduler-Interrupts), Cache-Räumungen oder gleichzeitiger Änderung eines Speicherorts durch mehrere Prozesse fehlschlagen. In diesen seltenen Fällen gibt der TSX einen Fehlercode zurück, der darauf hinweist, dass der Fehler vorübergehend ist. In diesen Fällen müssen Sie lediglich die Transaktion neu starten.
wenn Die angegebene Adresse ist nicht verfügbar Host-Anwendung unterdrückt TSX die aufgetretene Ausnahme (das Betriebssystem wird nicht benachrichtigt) und bricht die Transaktion ab. Dem Enklavencode wird ein Fehlercode zurückgegeben, damit dieser auf den Abbruch der Transaktion reagieren kann. Diese Fehlercodes weisen darauf hin, dass die betreffende Adresse für die Hostanwendung nicht verfügbar ist.
Diese Manipulation von TSX aus der Enklave heraus hat für den Bösewicht eine nette Funktion: Da die meisten Hardware-Leistungsindikatoren zum Zeitpunkt der Ausführung des Enklave-Codes nicht aktualisiert werden, ist es unmöglich, innerhalb der Enklave ausgeführte TSX-Transaktionen zu verfolgen. Damit bleibt eine böswillige Manipulation des TSX für das Betriebssystem völlig unsichtbar.
Da der obige Hack außerdem nicht auf Systemaufrufen beruht, kann er weder durch einfaches Blockieren von Systemaufrufen erkannt noch verhindert werden; was in der Regel zu einem positiven Ergebnis im Kampf gegen die Eierjagd führt.
Der Bösewicht nutzt den oben beschriebenen Hack, um den Host-Anwendungscode nach Gadgets zu durchsuchen, die für die Bildung einer ROP-Kette geeignet sind. Gleichzeitig muss er nicht jede Adresse prüfen. Es reicht aus, eine Adresse von jeder Seite des virtuellen Adressraums zu prüfen. Das Durchsuchen aller 16 Gigabyte Speicher dauert etwa 45 Minuten (auf einem Intel i7-6700K). Als Ergebnis erhält der Bösewicht eine Liste ausführbarer Seiten, die zum Aufbau einer ROP-Kette geeignet sind.
Hack zum Prüfen von Adressen auf Beschreibbarkeit
Um eine Enclave-Version eines ROP-Angriffs durchzuführen, muss ein Angreifer in der Lage sein, nach beschreibbaren, ungenutzten Speicherbereichen der Host-Anwendung zu suchen. Der Angreifer nutzt diese Speicherorte, um einen gefälschten Stack-Frame und eine Nutzlast (Shellcode) einzuschleusen. Im Endeffekt kann eine böswillige Enklave nicht von der Host-Anwendung verlangen, dass sie sich selbst Speicher zuweist, sondern kann stattdessen bereits von der Host-Anwendung zugewiesenen Speicher missbrauchen. Wenn es ihm natürlich gelingt, solche Gebiete zu finden, ohne dass die Enklave zusammenbricht.
Der Bösewicht führt diese Suche durch, indem er einen weiteren Nebeneffekt von TSX ausnutzt. Zunächst prüft es wie im vorherigen Fall die Adresse auf deren Existenz und überprüft dann, ob die Seite, die dieser Adresse entspricht, beschreibbar ist. Dazu verwendet der Bösewicht den folgenden Hack: Er platziert eine Schreibfunktion in einer TSX-Transaktion und bricht die Transaktion nach Abschluss, aber noch bevor sie abgeschlossen ist, zwangsweise ab (explizite Abbruch).
Durch die Betrachtung des Rückkehrcodes einer TSX-Transaktion erkennt der Angreifer, ob dieser beschreibbar ist. Wenn es sich um eine „explizite Abtreibung“ handelt, ist dem Bösewicht klar, dass die Aufnahme erfolgreich gewesen wäre, wenn er sie durchgeführt hätte. Wenn die Seite schreibgeschützt ist, endet die Transaktion mit einem anderen Fehler als „Explicit Abort“.
Diese Manipulation von TSX hat eine weitere Funktion, die für den Bösewicht nützlich ist (abgesehen von der Unmöglichkeit, die Hardware-Leistungsindikatoren zu verfolgen): Da alle Speicherschreibbefehle nur dann festgeschrieben werden, wenn die Transaktion erfolgreich ist, stellt das Erzwingen des Abschlusses der Transaktion sicher, dass die untersuchte Speicherzelle bleibt unverändert.
Hack, um den Kontrollfluss umzuleiten
Bei einem ROP-Angriff von einer Enklave aus kann der Angreifer – anders als bei herkömmlichen ROP-Angriffen – die Kontrolle über das RIP-Register erlangen, ohne Fehler im angegriffenen Programm auszunutzen (Pufferüberlauf oder ähnliches). Ein Angreifer kann den Wert des auf dem Stack gespeicherten RIP-Registers direkt überschreiben. Insbesondere kann es den Wert dieses Registers durch eine eigene ROP-Kette ersetzen.
Wenn die ROP-Kette jedoch lang ist, kann das Überschreiben eines großen Teils des Stapels der Hostanwendung zu Datenbeschädigung und unerwartetem Programmverhalten führen. Der Bösewicht, der seinen Angriff im Verborgenen durchführen möchte, ist mit dieser Situation nicht zufrieden. Daher erstellt es einen gefälschten temporären Stapelrahmen für sich selbst und speichert darin seine ROP-Kette. Der gefälschte Stapelrahmen wird an einem zufällig beschreibbaren Speicherort abgelegt, sodass der echte Stapel intakt bleibt.
Was bringen die drei oben aufgeführten Hacks dem Bösewicht?
(1) Zuerst die böswillige Enklave durch Hack zum Prüfen von Adressen, um zu sehen, ob sie gelesen werden können, – durchsucht die Host-Anwendung nach missbräuchlichen ROP-Geräten.
(2) Dann bis Hack zum Prüfen von Adressen auf Beschreibbarkeit, – Eine bösartige Enklave identifiziert Bereiche im Speicher der Host-Anwendung, die zum Einschleusen einer Nutzlast geeignet sind.
(3) Als nächstes erstellt die Enklave eine ROP-Kette aus den in Schritt (1) entdeckten Gadgets und fügt diese Kette in den Host-Anwendungsstapel ein.
(4) Wenn die Host-Anwendung schließlich auf die im vorherigen Schritt erstellte ROP-Kette trifft, beginnt die bösartige Nutzlast mit der Ausführung – mit den Privilegien der Host-Anwendung und der Möglichkeit, Systemaufrufe durchzuführen.
Wie ein Bösewicht diese Hacks nutzt, um Ranzowari zu erschaffen
Nachdem die Host-Anwendung die Kontrolle über einen der ECALLs an die Enklave übertragen hat (ohne zu ahnen, dass diese Enklave bösartig ist), sucht die böswillige Enklave nach freiem Speicherplatz im Speicher der Host-Anwendung, um Code einzuschleusen (wobei diese Zellsequenzen als freier Speicherplatz verwendet werden). das mit Nullen gefüllt). Dann durch Hack zum Prüfen von Adressen, um zu sehen, ob sie gelesen werden können, – Die Enklave sucht nach ausführbaren Seiten in der Host-Anwendung und generiert eine ROP-Kette, die eine neue Datei mit dem Namen „RANSOM“ im aktuellen Verzeichnis erstellt (bei einem echten Angriff verschlüsselt die Enklave vorhandene Benutzerdateien) und eine Lösegeldforderung anzeigt. Gleichzeitig glaubt die Host-Anwendung naiv, dass die Enklave einfach zwei Zahlen hinzufügt. Wie sieht das im Code aus?
Um die Wahrnehmung zu erleichtern, führen wir anhand der Definitionen einige Mnemoniken ein:
Wir speichern die ursprünglichen Werte der RSP- und RBP-Register, um den normalen Betrieb der Host-Anwendung nach der Ausführung der Nutzlast wiederherzustellen:
Wir suchen nach einem passenden Stack-Frame (siehe Code aus dem Abschnitt „Hack zur Umleitung des Kontrollflusses“).
Passende ROP-Gadgets finden:
Einen Ort zum Injizieren der Nutzlast finden:
Wir bauen eine ROP-Kette auf:
Auf diese Weise wird die SGX-Technologie von Intel, die zur Abwehr bösartiger Programme entwickelt wurde, von Bösewichten ausgenutzt, um entgegengesetzte Ziele zu erreichen.
Source: habr.com