Wie Sie wissen, ist der in der Enklave ausgeführte Code in seiner Funktionalität stark eingeschränkt. Er kann keine Systemaufrufe tätigen. Es können keine E / A-Operationen ausgeführt werden. Er kennt die Basisadresse des Host-Codesegments nicht. Es kann nicht jmp und Host-Code aufrufen. Er hat keine Ahnung von der Struktur des Adressraums, der die Hostanwendung steuert (z. B. welche Seiten beworben werden oder welche Art von Daten auf diesen Seiten platziert werden). Er kann das Betriebssystem nicht auffordern, ein Stück Speicher an die Hostanwendung anzuhängen (z. B. über / proc / pid / maps). Naive Versuche, einen blinden beliebigen Speicherbereich einer Host-Anwendung zu lesen - ganz zu schweigen von Schreibversuchen - führen früher oder später (eher der erste) zur erzwungenen Beendigung des Enklavenprogramms. Dies geschieht immer dann, wenn der von der Enklave angeforderte virtuelle Adressraumbereich für die Hostanwendung nicht zugänglich ist.
Wird der Virenschreiber in solch harten Realitäten in der Lage sein, SGX-Enklaven zu verwenden, um seine böswilligen Ziele zu verwirklichen?
- Hack, um Adressen auf die Möglichkeit zu prüfen, sie zu lesen
- Hack zum Prüfen von Adressen auf Beschreibbarkeit
- Hack, um den Kontrollfluss umzuleiten
- Was gibt dem Bösewicht die drei oben aufgeführten Hacks?
- Wie der Bösewicht diese Hacks benutzt, um Ranzomvari zu erstellen
Auf der Grundlage all dieser Punkte wird allgemein angenommen, dass die Enklave nur die Hostanwendung bedienen kann und dass die Enklave keine eigene Initiative ergreifen kann, auch nicht böswillig. Dies bedeutet, dass Enklaven für Virenschreiber keinen praktischen Wert darstellen. Diese voreilige Annahme ist einer der Gründe, warum der SGX-Schutz asymmetrisch ist: Der Hostanwendungscode kann nicht auf den Enklavenspeicher zugreifen, während der Enklavencode jede Speicheradresse der Hostanwendung lesen und schreiben kann.
Wenn es dem böswilligen Enklavencode gelingt, im Namen der Hostanwendung beliebige Systemaufrufe auszuführen, in ihrem Namen beliebigen Code auszuführen, den Speicher der Hostanwendung zu scannen und die für den Missbrauch geeigneten ROP-Ketten zu finden, kann er die vollständige Kontrolle übernehmen Host-Anwendung im Stealth-Modus. Es kann nicht nur Benutzerdateien stehlen und verschlüsseln, sondern auch im Namen des Benutzers handeln. Senden Sie beispielsweise Phishing-E-Mails in seinem Namen oder führen Sie DoS-Angriffe durch. Gleichzeitig haben Sie keine Angst vor den modernsten Schutzmechanismen wie Stapelkanarien und Bereinigung von Adressen.
Wir werden einige Hacks zeigen, durch die die Bösewichte die oben genannten Einschränkungen überwinden und versuchen, die Vorteile von SGX für ihre böswilligen Zwecke zu nutzen: bei der Durchführung von ROP-Angriffen. Entweder um beliebigen Code auszuführen, der als Host-Sawing-Prozess getarnt ist (ähnlich dem häufig von Malware verwendeten Prozessaushöhlungsprozess), oder um eine bereits vorbereitete Malware zu maskieren (um ihre Malware vor der Verfolgung durch Virenschutzprogramme und andere Schutzmechanismen zu schützen).
Hack, um Adressen auf die Möglichkeit zu prüfen, sie zu lesen
Da die Enklave nicht weiß, welche Bereiche des virtuellen Adressraums für die Hostanwendung verfügbar sind, und wenn Sie versuchen, eine unzugängliche Adresse zu lesen, die Enklave beendet werden muss, muss der Bösewicht einen Weg finden, um den Adressraum ausfallsicher zu scannen. Finden Sie eine Möglichkeit, verfügbare virtuelle Adressen zuzuordnen. Der Bösewicht löst dieses Problem, indem er die TSX-Technologie von Intel missbraucht. Es nutzt eine der Nebenwirkungen von TSX: Wenn die Speicherzugriffsfunktion in einer TSX-Transaktion platziert ist, werden Ausnahmen, die sich aus dem Zugriff auf ungültige Adressen ergeben, von TSX unterdrückt, bevor das Betriebssystem erreicht wird. Wenn Sie versuchen, auf eine ungültige Speicheradresse zuzugreifen, wird nur die aktuelle Transaktion unterbrochen und nicht das gesamte Enklavenprogramm. T.O. Mit TSX kann die Enklave innerhalb der Transaktion sicher auf jede Adresse zugreifen - ohne das Risiko eines Zusammenbruchs.
Wenn die angegebene Adresse für die Hostanwendung verfügbar ist , ist die TSX-Transaktion am häufigsten erfolgreich. In seltenen Fällen kann dies aufgrund externer Einflüsse wie Interrupts (z. B. Scheduler-Unterbrechungen), Verdrängung des Caches oder gleichzeitiger Änderung der Speicherzelle durch mehrere Prozesse fehlschlagen. In diesen seltenen Fällen gibt TSX einen Fehlercode zurück, der angibt, dass der aufgetretene Fehler nur vorübergehend ist. In diesen Fällen müssen Sie nur die Transaktion neu starten.
Wenn die angegebene Adresse der Hostanwendung nicht zur Verfügung steht , unterdrückt TSX die Ausnahme (das Betriebssystem wird nicht benachrichtigt) und bricht die Transaktion ab. Ein Fehlercode wird an den Enklavencode zurückgegeben, damit er auf die Tatsache reagieren kann, dass die Transaktion abgebrochen wurde. Diese Fehlercodes zeigen an, dass die betreffende Adresse der Hostanwendung nicht zur Verfügung steht.
Eine solche Manipulation von TSX aus dem Inneren der Enklave hat eine nette Eigenschaft für den Bösewicht: Da zum Zeitpunkt der Ausführung des Enklavencodes die meisten Hardware-Leistungsindikatoren nicht aktualisiert werden, ist es unmöglich, TSX-Transaktionen zu verfolgen, die innerhalb der Enklave mit ihnen ausgeführt werden. Somit bleibt böswilliger Betrug mit TSX'om für das Betriebssystem völlig unsichtbar.
Da der oben beschriebene Hack nicht auf Systemaufrufen beruht, kann er nicht durch einfaches Blockieren von Systemaufrufen erkannt oder verhindert werden. was normalerweise ein positives Ergebnis im Kampf gegen die "Eiersuche" ergibt.
Der Bösewicht verwendet den oben beschriebenen Hack, um im Host-Anwendungscode nach Gadgets zu suchen, die zum Bilden einer ROP-Kette geeignet sind. Er muss jedoch nicht jede Adresse prüfen. Es reicht aus, eine Adresse von jeder Seite des virtuellen Adressraums zu prüfen. Das Testen aller 16 Gigabyte Speicher dauert ungefähr 45 Minuten (auf 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 Enklavenversion eines ROP-Angriffs zu implementieren, muss der Bösewicht nach beschreibbaren, nicht verwendeten Teilen des Speichers der Hostanwendung suchen können. Der Bösewicht verwendet diese Speicherabschnitte, um einen gefälschten Stapelrahmen und eine Nutzlast (Shellcode) zu injizieren. Das Fazit ist, dass eine böswillige Enklave nicht von der Host-Anwendung verlangen kann, Speicher für sich selbst zuzuweisen, sondern den von der Host-Anwendung zugewiesenen Speicher für andere Zwecke verwenden kann. Es sei denn natürlich, er schafft es, solche Orte zu finden, ohne die Enklave zusammenzubrechen.
Der Bösewicht führt diese Suche durch, indem er eine weitere Nebenwirkung von TSX ausnutzt. Zunächst prüft er wie im vorherigen Fall die Adresse auf ihre Existenz und prüft dann, ob die dieser Adresse entsprechende Seite zum Schreiben zugänglich ist. Zu diesem Zweck verwendet der Bösewicht den folgenden Hack: Setzt die Schreibfunktion in die TSX-Transaktion ein und bricht die Transaktion nach Abschluss, jedoch vor Abschluss, gewaltsam ab (expliziter Abbruch).
Wenn der Bösewicht den Rückkehrcode einer TSX-Transaktion betrachtet, erkennt er, ob er beschreibbar ist. Wenn es sich um einen „expliziten Abbruch“ handelt, erkennt der Bösewicht, dass die Aufnahme erfolgreich wäre, wenn er sie zu Ende bringen würde. Wenn die Seite schreibgeschützt ist, schlägt die Transaktion mit einem anderen Fehler als "expliziter Abbruch" fehl.
Eine solche Manipulation von TSX hat eine weitere Funktion, die für den Bösewicht angenehm ist (zusätzlich zu der Unfähigkeit, Hardware-Leistungsindikatoren zu verfolgen): Da alle Schreibbefehle in den Speicher nur aufgezeichnet werden, wenn die Transaktion erfolgreich war, wird durch Erzwingen des Abschlusses der Transaktion sichergestellt, dass die untersuchte Speicherzelle unverändert bleibt.
Kontrollfluss-Umleitungs-Hack
Wenn ein Bösewicht einen ROP-Angriff von einer Enklave aus ausführt - im Gegensatz zu herkömmlichen ROP-Angriffen - kann der Bösewicht die Kontrolle über das RIP-Register erlangen, ohne Fehler im angegriffenen Programm auszunutzen (Pufferüberlauf oder ähnliches). Der Bösewicht kann den Wert des auf dem Stapel gespeicherten RIP-Registers direkt überschreiben. Insbesondere kann es den Wert dieses Registers durch seine ROP-Kette ersetzen.
Wenn die ROP-Kette jedoch lang ist, kann das Umschreiben eines großen Teils des Host-Anwendungsstapels zu Datenbeschädigung und unerwartetem Programmverhalten führen. Als Bösewicht, der versucht, seinen Angriff heimlich durchzuführen, passt dieser Zustand nicht. Daher erstellt er einen gefälschten temporären Stapelrahmen für sich selbst und speichert seine ROP-Kette darin. Ein gefälschter Stapelrahmen wird an einer beliebigen Stelle im Speicher platziert, die beschreibbar ist, so dass der wahre Stapel unberührt bleibt.
Was gibt dem Bösewicht die drei oben aufgeführten Hacks
(1) Zunächst durchsucht eine böswillige Enklave die Host-Anwendung durch einen Hack, um Adressen auf die Möglichkeit des Lesens zu untersuchen , nach ROP-Gadgets, die missbraucht werden können.
(2) Anschließend wird die böswillige Enklave mithilfe eines Hacks zum Überprüfen der Adressen auf Beschreibbarkeit in den Speicherbereichen der Hostanwendung identifiziert, die zum Injizieren der Nutzdaten geeignet sind.
(3) Als nächstes erstellt die Enklave eine ROP-Kette aus den in Schritt (1) gefundenen Gadgets und fügt diese Kette in den Host-Anwendungsstapel ein.
(4) Wenn die Hostanwendung schließlich auf die im vorherigen Schritt erstellte ROP-Kette stößt, beginnt die Ausführung der böswilligen Nutzdaten mit den Berechtigungen der Hostanwendung und der Fähigkeit, Systemaufrufe zu tätigen.
Wie der Bösewicht diese Hacks benutzt, um Ranzomvari zu erstellen
Nachdem die Hostanwendung die Kontrolle über eine der ECALLs an die Enklave übertragen hat (ohne zu vermuten, dass diese Enklave böswillig ist), sucht die böswillige Enklave nach freiem Speicherplatz im Speicher der Hostanwendung für die Code-Injektion (für die Stellen, an denen diese Zellsequenzen benötigt werden) gefüllt mit Nullen). Anschließend sucht die Enklave mithilfe eines Hacks nach ausführbaren Seiten in der Hostanwendung und generiert eine ROP-Kette, die im aktuellen Verzeichnis eine neue Datei mit dem Namen „RANSOM“ erstellt (bei einem echten Angriff verschlüsselt die Enklave vorhandene Benutzerdateien) und Zeigt eine Lösegeldanforderungsnachricht an. Gleichzeitig glaubt die Host-Anwendung naiv, dass die Enklave einfach zwei Zahlen addiert. Wie sieht es im Code aus?
Zur Erleichterung der Wahrnehmung führen wir einige Mnemoniken durch folgende Definitionen ein:
Wir behalten die Anfangswerte der RSP- und RBP-Register bei, um den normalen Betrieb der Hostanwendung nach dem Ausführen der Nutzdaten wiederherzustellen:
Wir suchen nach einem geeigneten Stapelrahmen (siehe den Code im Abschnitt „Hack zum Umleiten des Kontrollflusses“).
Finden Sie geeignete ROP-Gadgets:
Suchen Sie einen Ort zum Einspritzen der Nutzlast:
Aufbau einer ROP-Kette:
Auf diese Weise wird die SGX-Technologie von Intel, die schädlichen Programmen standhält, von Bösewichten genutzt, um gegnerische Ziele zu erreichen.