Pegasus: Mit der Logikgatter-VM im Fax-Algorithmus zum Trojaner

(Foto: mundissima / Shutterstock)
Das Project Zero von Google sucht nicht nur selbst nach Sicherheitslücken, sondern untersucht auch aktiv eingesetzte Malware. In einer aktuellen Analyse des Pegasus-Trojaners der NSO-Group zeigt das Project-Zero-Team dabei, wie weit fortgeschritten die technischen Fähigkeiten des Herstellers sind und dass die Trojaner-Entwickler offenbar extrem viele Ressourcen für die Entwicklung eines Exploits verwenden können, der ohne Nutzerinteraktion funktioniert – ein sogenannter Zero-Click-Angriff. Zuvor mussten für erfolgreiche Angriffe zum Beispiel noch Links in SMS angeklickt werden. Die nun durchgeführte Analyse überrascht selbst die Spezialisten vom Project Zero.
Im konkreten Fall haben die Beteiligten den Trojaner-Code untersucht, den Citizen Lab bereitgestellt hat. Forscher des Citizen Lab der Universität Toronto waren bei der Analyse des Smartphones eines saudi-arabischen Aktivisten auf die Sicherheitslücke (CVE-2021-30860) gestoßen und hatten sie an Apple gemeldet. Das Gerät sei mit der Überwachungssoftware Pegasus der israelischen Firma NSO infiziert gewesen, berichtete Citizen Lab. Die Forcedentry genannte Sicherheitslücke soll mindestens seit Februar 2021 ausgenutzt worden sein. Citizen Lab hatte die Nutzung der Trojaner der NSO Group zuvor bereits als „Staatsterror“ bezeichnet.
Die von Google beschriebene Lücke hat Apple am 13. September 2021 in iOS 14.8 geschlossen. Als Finder der Lücke nennt Apple in den Sicherheitsnotizen dazu explizit Citizen Lab. Darüber hinaus sei zwar der Exploit-Code, dessen Vorgehen das Team nun beschreibt, auf die Ausnutzung von Sicherheitslücken auf iPhones ausgerichtet. Das Google-Team schreibt jedoch, die NSO-Group habe mit Pegasus auch ähnliche Techniken für Android.
Vom GIF, zum PDF, zum Fax
Grundlage des Zero-Click-Angriffs ist, dass Apples iMessage als Ziel zum Unterschieben des Trojaners gewählt wird. Das ist insofern nachvollziehbar, weil für den Angriff dann lediglich die Handynummer oder die Apple-ID des Opfers bekannt sein muss. Apples iMessage unterstützt darüber hinaus die Darstellung von GIF-Dateien standardmäßig.
Diese GIFs werden von Apple in einer Schleife dargestellt, statt diese nur einmal abzuspielen. Sämtliche Dateien mit der Endung .gif werden dazu noch vor der Darstellung in einen bestimmten Prozess ausgelagert, der die Datei nicht nur einfach kopiert, sondern mithilfe der Core-Graphics-API die Ausgangsdatei als neues GIF am Zielpfad rendert.
Die dazu genutzte I/O-Bibliothek versucht dabei, das eigentliche Dateiformat zu erkennen, statt sich auf die Korrektheit der Endung zu verlassen. So wird eine Datei mit einer gefälschten .gif-Endung plötzlich auch als eines von mehr als 20 anderen Dateiformaten untersucht. Im Fall des untersuchten Trojaners wird so ein PDF als fingiertes GIF verschickt, das iOS dann direkt untersucht.
Für den letztlich erfolgreichen Angriff nutzt Pegasus dann eine Sicherheitslücke im Parser für einen eher obskuren und vor allem sehr alten Teil des PDF-Standards. Dabei handelt es sich um den Kompressionsalgorithmus JBIG2, der zusätzlich zu PDFs auch im Fax zum Einsatz kommt und aus einer Zeit stammt, in der kaum Bandbreite zur Verfügung stand. Bekanntheit erlangte JBIG2 dadurch, dass auf bestimmten Geräten beim Scannen eines Dokuments als PDF Zahlen in dem Dokument vertauscht werden. Und das ist offenbar bei weitem nicht das einzige Problem mit JBIG2, wie nun die Analyse zeigt.
Logikgatter im Turing-vollständigen Fax-Algorithmus
Der von Apple für JBIG2 genutzte Code stammt laut der Analyse von Google aus dem in C++ geschriebenen Open-Source-Projekt Xpdf, das seit Jahrzehnten wohl von einer einzigen Person gepflegt wird. Darin ausgenutzt wird von dem Trojaner letztlich ein immer noch typischer Integer-Overflow.
Mit einigen weiteren Tricks erreicht der Exploit einen Punkt, den Googles Project Zero so beschreibt: „An dieser Stelle wäre es auch möglich, auf beliebige absolute Speicheradressen zu schreiben, wenn Sie deren Offsets aus dem Seitenpuffer kennen. Aber wie berechnet man diese Offsets? Bisher verlief dieser Exploit sehr ähnlich wie ein Exploit für eine ‚kanonische‘ Skriptsprache, der in Javascript mit einem unbegrenzten Arraybuffer-Objekt mit Zugriff auf den Speicher enden könnte.“
Um die Berechnungen doch noch umzusetzen, nutzt der Exploit eine Eigenheit der JBIG2-Kompression aus. Ähnlich wie andere Kompressionsalgorithmen sucht auch JBIG2 zunächst nach gleichen beziehungsweise sehr ähnlichen Zeichen (Glyphen) und merkt sich lediglich einmal das eigentliche Symbol und von den anderen Vorkommen im Text nur deren Position, sodass dies beim Wiederherstellen ersetzt werden kann.
Eine VM aus Logikgattern
Der Algorithmus erlaubt dabei aber auch eine möglichst verlustfreie Komprimierung. Erreicht wird das wiederum, indem der Unterschied zwischen Original-Glyphen und dem möglichen Ersatz mithilfe von Logikgattern (AND, OR, XOR, XNOR) gespeichert wird. Die Schritte sind dabei nicht beschränkt und der JBIG2-Algorithmus selbst ist so flexibel, dass dies zu einer Turing-Vollständigkeit führt, wie das Team schreibt.
Aus einer Verknüpfung von AND- und XOR-Gatter lassen sich so etwa NAND-Gatter erzeugen, die auch mehrheitlich in der modernen Mikroelektronik zum Einsatz kommen. Der Pegasus-Trojaner setzt dies nun so zusammen, dass durch eine gezielte Verknüpfung der Logikgatter innerhalb der Parser-Bibliothek eine eigene kleine virtuelle Maschine gebaut wird.
Googles Project Zero schreibt dazu: „Mit über 70.000 Segmentbefehlen, die logische Bitoperationen definieren, definieren sie eine kleine Computerarchitektur mit Funktionen wie Registern und einem vollständigen 64-Bit-Addierer und -Komparator, mit denen sie den Speicher durchsuchen und arithmetische Operationen ausführen. Es ist nicht so schnell wie Javascript, aber es ist im Wesentlichen rechnerisch äquivalent.“
Der Pegasus-Trojaner nutzt diese Fähigkeiten für die ersten Schritte, um den notwendigen Ausbruch aus einer Sandbox vorzubereiten. Googles Project Zero schreibt dazu: „Es ist ziemlich unglaublich und gleichzeitig ziemlich erschreckend.“ In einem weiteren Blogpost wollen die Beteiligten dann erklären, wie der Ausbruch aus der Sandbox gelingt.
Autor des Artikels ist Sebastian Grüner.