Wenn es um mobile Sicherheit geht, werden Benutzer regelmäßig dazu aufgefordert, sehr vorsichtig zu sein und verdächtige Links, E-Mails und Anhänge zu vermeiden. Doch die Zunahme klickloser Angriffe umgeht diese flexiblen Abwehrmaßnahmen.
Google hat jüngst einen solchen Angriff durchgesetzt, der, wie sich herausstellte, ein iPhone traf. „Wir glauben, dass dies einer der technisch ausgefeiltesten Exploits ist, die wir je gesehen haben, und zeigt einmal mehr, dass die Fähigkeiten (eines Anbieters) mit denen konkurrieren, die zuvor für eine Handvoll Nationalstaaten als nicht verfügbar galten“, heißt es in der Erklärung von Google.
Der beängstigendste Teil des Google-Berichts – und er enthält viele beängstigende Teile – besteht darin, dass er gegen eine der ungeschriebenen Regeln von Sicherheitswarnungen verstößt, nämlich dass es nicht optimal ist, Einzelheiten eines Angriffs zu melden, für den es keine wirksame Abwehr gibt. Ich stimme mit Google darin überein, dass die Details besprochen werden müssen, damit die Community schneller eine Verteidigung vorbereiten kann.
„Es ist dokumentiert, dass NSO seinen Kunden klicklose Betriebstechnologie anbietet, bei der selbst technisch versierte Ziele, die möglicherweise nicht auf einen Phishing-Link klicken, überhaupt nicht wissen, dass sie angegriffen werden. Im No-Click-Szenario ist keine Benutzerinteraktion erforderlich. Das bedeutet, dass der Angreifer keine Phishing-Nachrichten versenden muss. Der Exploit funktioniert nur unbemerkt im Hintergrund. Sofern Sie kein Gerät verwenden, gibt es keine Möglichkeit, die Ausnutzung durch einen No-Click-Exploit zu verhindern. Es ist eine Waffe, gegen die es keine Verteidigung gibt.
Kommen wir mit diesem ergreifenden Gedanken zu den Details.
Das Diagramm, das nicht wirklich ein Diagramm ist
Das Unternehmen NSO, das hinter der bei diesen Angriffen verwendeten Software steckt, nutzte angeblich einen gefälschten GIF-Hack, um eine Schwachstelle im PDF-Parser von CoreGraphics anzugreifen. Die Dateien haben die Erweiterung .gif, sind jedoch keine GIF-Bilddateien. Der Name soll nur verhindern, dass sich ein Benutzer Sorgen macht.
„Die ImageIO-Bibliothek wird verwendet, um das richtige Format der Quelldatei zu erraten und sie zu analysieren, wobei die Dateierweiterung vollständig ignoriert wird. Mit diesem gefälschten GIF-Trick werden plötzlich über 20 Bildcodecs Teil der klicklosen Angriffsfläche von iMessage, darunter einige sehr obskure und komplexe Formate, die aus der Ferne wahrscheinlich Hunderttausende Codezeilen offenlegen.
Wie Google betont hat, sind diese Angriffe schwer zu vereiteln. Es ist unwahrscheinlich, dass das Blockieren aller GIF-Bilder wirksam ist. Erstens handelt es sich bei diesen Dateien eigentlich nicht um GIFs. Der einfachste Ansatz besteht darin, alles mit einer GIF-Erweiterung zu blockieren, aber die Bösewichte wechseln einfach zu einer anderen, harmlos aussehenden Erweiterung.
(Hinweis: Aus dem Bericht von Google geht hervor, dass Apple versucht hat, den GIF-Angriff durch im Jahr 2021 veröffentlichte Fixes rückgängig zu machen. „Apple teilt uns mit, dass sie die verfügbaren ImageIO-Formate, auf die über IMTranscoderAgent zugegriffen werden kann, seit iOS 14.8.1 (26. Oktober 2021) eingeschränkt und vollständig entfernt haben Der GIF-Codepfad von IMTranscoderAgent aus iOS 15.0 (20. September 2021) und die GIF-Dekodierung wurden vollständig in BlastDoor durchgeführt.
Kompressionstechnik
Dies ist eine gängige und legitime Taktik, um die Dateigröße durch das Ersetzen bestimmter sich wiederholender Zeichen zu reduzieren. Geht ein wenig auf den Punkt: „Dies gibt der aktuellen Landingpage von JBIG2Bitmap einen unbekannten, aber sehr großen Wert für h.“ Da dieser h-Wert zur Grenzüberprüfung verwendet wird und die zugewiesene Größe des Seitenspeicherpuffers widerspiegeln soll, hat dies den Effekt, dass die Zeichenfläche „umrandet“ wird. Dies bedeutet, dass nachfolgende JBIG2-Segmentbefehle Speicher außerhalb der ursprünglichen Grenzen des Speicherseitenpuffers lesen und schreiben können.
Das Ergebnis?
„Durch das Rendern von 4-Byte-Bitmaps an den richtigen Canvas-Koordinaten können sie in alle Felder der JBIG2Bitmap-Seite schreiben, und durch sorgfältige Auswahl neuer Werte für w, h und line können sie in beliebige Pufferoffsets schreiben.“ Speichern der Seite. Zu diesem Zeitpunkt wäre es auch möglich, in beliebige absolute Speicheradressen zu schreiben, wenn Sie deren Seitenpuffer-Offsets kennen würden. Doch wie berechnet man diese Entschädigungen? Bisher wurde dieser Exploit weitgehend auf die gleiche Weise entwickelt wie ein kanonischer Skriptsprachen-Exploit, der in Javascript zu einem unbegrenzten ArrayBuffer-Objekt mit Zugriff auf den Speicher führen könnte. In diesen Fällen hat der Angreifer jedoch die Möglichkeit, beliebiges JavaScript auszuführen, mit dem offensichtlich Offsets berechnet und beliebige Berechnungen durchgeführt werden können. Wie erfolgt dies in einem einstufigen Bildanalysator? In der Praxis bedeutet dies, dass es möglich ist, die logischen Operatoren AND, OR, XOR und XNOR zwischen Speicherbereichen an beliebigen Offsets des JBIG2Bitmap-Sicherungspuffers der aktuellen Seite anzuwenden. Und da es grenzenlos war ... ist es möglich, diese logischen Operationen im Speicher an beliebigen Offsets außerhalb der Grenzen auszuführen.
Hierbei handelt es sich um ein Codierungsproblem, das es Angreifern ermöglicht, einzudringen und nicht autorisierten Code auszuführen. Dies sind wichtige Informationen, da sie es Programmierern ermöglichen, diese Lücke von Zeit zu Zeit zu umgehen und der Software außerdem etwas Konkretes zu finden und zu blockieren geben.
Angriffe außerhalb der Reichweite
Ein weiterer Punkt von Google: „JBIG2 verfügt über keine Skriptfähigkeiten, aber in Kombination mit einer Schwachstelle ist es in der Lage, beliebige Logikgatterschaltungen zu emulieren, die in einem beliebigen Speicher laufen.“ Warum also nicht damit Ihre eigene IT-Architektur erstellen und schreiben? ? Genau das macht dieser Exploit. Mithilfe von mehr als 70 Segmentbefehlen, die logische Binäroperationen definieren, definieren sie eine kleine Computerarchitektur mit Funktionen wie Registern und einem vollständigen 000-Bit-Addierer und -Komparator, mit denen sie Speicher finden und arithmetische Operationen ausführen. Es ist nicht so schnell wie Javascript, aber im Grunde rechnerisch gleichwertig. Die Bootstrap-Operationen für den Sandbox-Escape-Exploit sind so geschrieben, dass sie in dieser Logikschaltung ausgeführt werden, und alles läuft in dieser seltsamen emulierten Umgebung, die aus einem einzigen Dekomprimierungsschritt durch ein JBIG64-Skript besteht.
Google hat völlig recht, wenn es sagt, dass diese Dinge dem nationalstaatlichen Standard von „Schmuddelig“ nahekommen. Aber zumindest werden diese Details CIOs und CISOs dabei helfen, dies zu umgehen.
Copyright © 2022 IDG Communications, Inc.