Von kommerziellem Überwachungsanbieter in Ägypten ausgenutzte 0-Day-Schwachstellen

 (blog.google)
1 Punkte von GN⁺ 2023-09-23 | 1 Kommentare | Auf WhatsApp teilen
  • Google TAG und The Citizen Lab haben in realen Angriffen eine gegen iPhones gerichtete 0-Day-Exploit-Chain entdeckt, mit der Intellexa heimlich die Spyware Predator installierte
  • Apple hat CVE-2023-41991·41992·41993 in iOS 16.7 und iOS 17.0.1 gepatcht; Google empfiehlt iOS-Nutzern ein sofortiges Update
  • Der Angriff fing per MITM-Injection den Traffic ab, wenn das Ziel eine HTTP-Website aufrief, und leitete ihn zu c.betly[.]me und sec-flare[.]com um; ein zusätzlicher Klick oder das Annehmen eines Anrufs war nicht nötig
  • Die iOS-Chain führte von einer Remote Code Execution in Safari über ein Problem bei der Zertifikatsprüfung bis zu einer lokalen Rechteausweitung im XNU Kernel; anschließend entschied ein kleines Binary, ob das vollständige Predator-Implantat installiert wird
  • Auch Angriffe auf Android-Ziele wurden in Ägypten beobachtet; die initiale Renderer-Remote-Code-Execution-Schwachstelle in Chrome, die CVE-2023-4762 ausnutzte, wurde am 5. September gepatcht

Intellexas Exploit-Chain zur Installation von Predator

  • Die Google Threat Analysis Group (TAG) hat zusammen mit The Citizen Lab eine in realen Angriffen eingesetzte 0-Day-Exploit-Chain für iPhones entdeckt
  • Diese von dem kommerziellen Überwachungsanbieter Intellexa entwickelte Chain wurde genutzt, um heimlich die Predator-Spyware auf Geräten zu installieren
  • Apple hat in iOS 16.7 und iOS 17.0.1 die folgenden Schwachstellen gepatcht
    • CVE-2023-41991
    • CVE-2023-41992
    • CVE-2023-41993
  • Durch die schnelle Behebung wurde der Schutz der Nutzer verbessert; allen iOS-Nutzern wird empfohlen, das Update so bald wie möglich zu installieren

Auslieferung per MITM

  • Intellexas Exploit-Chain wurde über einen Man-in-the-Middle(MITM)-Angriff ausgeliefert
  • Bei einem MITM-Angriff schaltet sich der Angreifer zwischen das Ziel und die Website, die das Ziel aufrufen will, und fängt den Traffic ab
  • Wenn das Ziel eine http-Website aufruft, kann der Angreifer gefälschte Daten zurückgeben und es auf eine andere Website weiterleiten
  • Bei https-Websites ist der Traffic verschlüsselt, und Zertifikate können prüfen, ob die empfangenen Daten von der beabsichtigten Website stammen
  • In dieser Kampagne wurde das Ziel beim Aufruf einer beliebigen http-Website durch Traffic-Injection unbemerkt auf die Intellexa-Site c.betly[.]me umgeleitet
    • Wenn der Nutzer dem erwarteten Zielprofil entsprach, wurde er erneut auf den Exploit-Server sec-flare[.]com weitergeleitet
    • Nutzeraktionen wie das Öffnen eines Dokuments, das Anklicken eines bestimmten Links oder das Annehmen eines Anrufs waren nicht erforderlich

Aufbau der iOS-Exploit-Chain

  • Sobald das Ziel auf den Exploit-Server umgeleitet wurde, wurde die iOS-Exploit-Chain ausgeführt
  • Die Chain besteht aus drei Schwachstellen
    • CVE-2023-41993: initiale Remote Code Execution (RCE) in Safari
    • CVE-2023-41991: Problem bei der Zertifikatsprüfung
    • CVE-2023-41992: lokale Rechteausweitung (LPE) im XNU Kernel
  • Anschließend wurde ein kleines Binary ausgeführt, das entschied, ob das vollständige Predator-Implantat installiert wird
  • TAG konnte das vollständige Predator-Implantat nicht sichern
  • Google plant, gemäß der Google vulnerability disclosure policy eine technische Tiefenanalyse dieses Exploits zu veröffentlichen

Angriffe auf Android-Ziele und Chrome-Schwachstelle

  • Die Angreifer verfügten auch über eine Exploit-Chain, um Predator auf Android-Geräten in Ägypten zu installieren
  • TAG beobachtete zwei Wege, über die der Android-Exploit ausgeliefert wurde
    • MITM-Injection
    • Einmal-Links, die direkt an die Zielperson gesendet wurden
  • TAG konnte nur die initiale Renderer-Remote-Code-Execution-Schwachstelle in Chrome sichern; diese Schwachstelle nutzt CVE-2023-4762 aus
  • Der betreffende Bug war bereits von einem anderen Sicherheitsforscher an das Chrome Vulnerability Rewards Program gemeldet worden und wurde am 5. September gepatcht
  • Google schätzt, dass Intellexa diese Schwachstelle zuvor als 0-Day verwendet hat

MITM-Schutz in Chrome und Googles Reaktion

  • Chrome treibt seit Jahren die breite Einführung von HTTPS im gesamten Web voran
  • Der „HTTPS-First Mode“ von Chrome kann die Möglichkeit verringern, Exploits über MITM-Netzwerk-Injection auszuliefern
    • Er versucht, alle Seiten zuerst über HTTPS zu laden
    • Vor dem Zurückfallen auf HTTP-Anfragen wird eine deutliche Warnung angezeigt
  • Diese Einstellung ist für Nutzer, die im Advanced Protection Program registriert und in Chrome angemeldet sind, standardmäßig aktiviert
  • Google empfiehlt allen Nutzern, zur Abwehr von MITM-Angriffen den „HTTPS-First Mode“ zu aktivieren
  • Diese Kampagne zeigt, dass die Verbreitung kommerzieller Überwachungsanbieter ein ernstes Risiko für die Sicherheit von Online-Nutzern schaffen kann
  • TAG wird weiterhin Maßnahmen gegen die kommerzielle Spyware-Industrie ergreifen und Forschungsergebnisse veröffentlichen sowie mit dem öffentlichen und privaten Sektor zusammenarbeiten, um entsprechende Gegenmaßnahmen fortzusetzen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-23
Kommentare auf Hacker News

  • Es ist gut, dass weitere Informationen aufgetaucht sind, aber dass nur der Chrome-Patch erwähnt wird, ist etwas beunruhigend. Ich frage mich, was der Sandbox-Escape unter Android war.
    Selbst wenn Codeausführung innerhalb des Chrome-Prozesses auf Android möglich wurde, sollte das keine Persistenz ermöglichen; es muss also eindeutig noch eine weitere Schwachstelle geben.
    Der Angriffsvektor war in diesem Fall zwar ein HTTP-Man-in-the-Middle-Angriff und ein einmaliger Link in einer gezielten Kampagne, aber ich sehe keinen Grund, warum jemand das nicht in eine Werbekampagne oder Spam über SMS/Discord/Matrix einbauen könnte, um es massenhaft zu verbreiten, ein Botnet aufzubauen oder Zugangsdaten von Nutzern zu stehlen.

    • Genau das ist der entscheidende Punkt. Im Blogpost fehlt diese Information, man muss also zwischen den Zeilen lesen, und es klingt so, als gäbe es auf Android-Seite derzeit ein ungepatchtes Problem.
    • Es heißt, dass die nachfolgenden Schritte der Android-Kette nicht erfasst werden konnten und nur die anfängliche Ausführungskomponente gesichert wurde.
      Das bedeutet, dass der Sandbox-Escape und der Fehler zur Rechteausweitung fehlen.
      Außerdem scheint die Auslieferung hier über einen ISP-Level-Man-in-the-Middle-Angriff unter Nutzung legaler Abhörfunktionen erfolgt zu sein, aber es gibt keinen Grund, warum dieser Exploit nicht auch als One-Click-Angriff über einen Phishing-Link ausgeliefert werden könnte.
    • Es gibt Millionen von Android-Geräten, die von ihren Herstellern aufgegeben wurden; deshalb lassen sie möglicherweise einige Details weg, weil es sich um eine noch nicht gepatchte und vermutlich nie gepatchte Schwachstelle handelt.
    • Der Schwerpunkt des Artikels liegt auf der iPhone-Exploit-Kette: Safari-Exploit → PAC-Bypass → Kernel-Exploit.
      Die Android-Version war offenbar ziemlich ähnlich, brauchte aber wohl zwei weitere Exploits, um die Mitigations des Linux-Kernels zu umgehen.
      Bei PZ gibt es eine gute technische Analyse.
    • Ich kenne mich im Mobile-Bereich nicht besonders gut aus, aber wenn man aus der Chrome-Sandbox ausbricht, landet man dann nicht im zugrunde liegenden Betriebssystem? Kann man von dort aus ohne Ausnutzung weiterer Schwachstellen keine Persistenz herstellen?

  • Es ist besser als gar kein HTTPS, und dieser Angriff nutzt HTTP zur Injektion der initialen Payload, aber ich könnte mir vorstellen, dass staatlich unterstützte Angreifer in manchen Ländern die CA- oder CDN-Infrastruktur einfach umgehen oder übernehmen können.

    • Wenn sie auf diese Weise Zertifikate fälschen, ist die Wahrscheinlichkeit groß, dass alle Browser es bemerken und die betreffende CA entfernen; es gibt also Schutzmechanismen.
    • Oder sie könnten einen dazu bringen, auf eine Spoofing-Domain zu klicken, die von unserem allseits geliebten LetsEncrypt zertifiziert wurde.
      Alles, was nötig zu sein scheint, ist eine HTTP-302/307-Redirect-Antwort, die den Client zu c.betly[.]me schickt. Eine HTML-Redirect-Payload oder vielleicht auch DNS könnten ebenfalls möglich sein.
    • Wichtig ist, dass offenbar schon ein einmaliger Besuch irgendeiner HTTP-Website ausreichte oder ausreicht, um ein Gerät zu kompromittieren.

  • Es gibt eine aktuelle passende Folge von Darknet Diaries über die Predator-Spyware: https://darknetdiaries.com/episode/137/

  • Was uns solche 0-days lehren, ist: Wer Ziel eines mächtigen Gegners ist, muss extrem paranoid handeln und die Angriffsfläche so weit wie möglich reduzieren.
    Wenn James Bond sicher mit M kommunizieren will, sollte er besser ein maßgeschneidertes, hardwareartiges Mobilgerät verwenden, das nur diese eine Funktion hat. Er müsste verschlüsselte Nachrichten auf einem zufälligen Forum hinterlassen, von einem anonymen Prepaid-Gerät eines Dritten aus, in einer vorab vereinbarten rotierenden Reihenfolge eines geogesperrten Codebuchs. Sobald die operative Sicherheit auch nur ein bisschen schwächer ist, ist es vorbei.
    Wenn ein normaler Mensch vernetzte digitale Geräte auf normale Weise nutzt, sollte er davon ausgehen, dass alles, was er darauf gespeichert hat, bereits gestohlen wurde. Wenn etwas wirklich privat bleiben soll, sollte es nicht digital abgelegt werden, sondern auf Papier oder einem altmodischen analogen Band. Dann muss es wenigstens physisch gestohlen werden, was je nach Situation deutlich schwieriger sein kann, aber nicht zwingend sicherer ist. Am Ende verliert man so oder so.
    Der einzige echte Ausweg sind demokratische Regierungen mit starker Transparenz und wirksamen Checks and Balances, streng durchgesetzte Datenschutzgesetze und starke Unterstützung für Aktivitäten wie die von Citizen Lab.

  • Diese Schwachstelle wurde mit hoher Wahrscheinlichkeit von ägyptischen Behörden genutzt, um das Telefon von Ahmed El Tantawy zu hacken, einem Kandidaten, der bei der Präsidentschaftswahl gegen den amtierenden Präsidenten Abdel Fatah El Sisi antritt.
    https://x.com/jsrailton/status/1705271600868692416?s=46&t=Kq...

  • Im Artikel steht es nicht, aber der Lockdown Mode von iOS hat diese Exploit-Kette blockiert.

  • Eine Sache verstehe ich nicht: Sowohl Spyware-Anbieter als auch 0-day-Verkäufer beschäftigen eigene Teams, die 0-days finden. Warum werben Google und Apple diese Leute nicht einfach ab?
    Google und Apple könnten doch sehr konkurrenzfähige Gehälter bieten; ich frage mich, warum sie es nicht tun. Halten sie die Kosten dafür, praktisch alle erfahrenen 0-day-Jäger abzuwerben, für höher als die Kosten, einfach Patches zu veröffentlichen?

    • Ich bin jemand, der genau so etwas macht. Ich arbeite als 0-day-Forscher.
      Aus Mitarbeitersicht sind die Gehälter ähnlich. Die Arbeit bei Big Tech ist weniger interessant. Man baut große Bug-Finding-Maschinen, die viele Bugs finden, und legt die gefundenen Bugs im Bugtracker ab, wo sie vielleicht drei Monate später behoben werden. Offensive Security ist interessanter. Die oberflächlichen Schwachstellen findet Big Tech, man braucht also nur wenige, muss aber das untersuchte System tief verstehen. Man braucht auch das Wissen, um von einer Schwachstelle bis zur Codeausführung zu kommen. Exploits zu schreiben ist nicht einfach. Es ist schwer zu erklären, warum Ingenieure bei Unternehmen arbeiten, die ich für unethisch halte, aber vermutlich fühlen sie nicht so wie ich.
      Aus Arbeitgebersicht ist es eine Frage von „Wie viel geben wir für eine bestimmte Rate von X gefundenen Schwachstellen pro Jahr aus?“ Wenn der Code trotz Bugs als der sicherste am Markt gilt, liegt es möglicherweise nicht im Interesse des Unternehmens, das Sicherheitsbudget zu erhöhen. Wenn man das Sicherheitsbudget erhöht, muss man überlegen, welchem Bereich man Budget entzieht und wie der Nettoeffekt auf die Gesundheit des Unternehmens aussieht.
      Wenn man Schwachstellen beheben will, muss man den Preis dafür, Schwachstellen zu finden und auszunutzen, so weit erhöhen, dass Käufer ihn sich nicht mehr leisten können. Und man muss diesen Preis weiter hochhalten, während Fortschritte in der Offensive Security die Kosten für Entdeckung und Ausnutzung senken. Defensive Unternehmen verdienen ihr Geld hauptsächlich nicht mit der Vermeidung von Bugs, während offensive Unternehmen ihr Geld hauptsächlich mit dem Finden von Bugs verdienen; daraus entsteht die Diskrepanz. Die letztliche Schwachstelle jedes Unternehmens oder jeder Organisation sind begrenzte Ressourcen.
    • Google hat eines der besten Teams, die man mit Geld und Prestige bekommen kann: https://en.m.wikipedia.org/wiki/Project_Zero
      Auch die Zusammenarbeit mit unabhängigen Forschern weltweit ist hervorragend. Aber angesichts der Menge an Software, die jeden Tag geschrieben wird, können trotzdem einige Probleme übersehen werden.
    • Das klingt ein bisschen so, als würde man sich den US-Haushalt ansehen und fragen: „Warum kauft man nicht einfach alle potenziellen Kriminellen, um den Großteil der Kriminalität in den USA zu reduzieren?“
    • Manche von ihnen wollen unabhängig vom Gehalt von vornherein nicht bei Google oder Apple arbeiten.
      Selbst wenn man sie heute abwirbt, gäbe es morgen wieder jede Menge neuer Leute, die bei solchen Firmen arbeiten; es wäre ein endloser Kreislauf.
    • Die Idee ist gut, aber in gewisser Weise ähnelt das der schwierigen Frage: „Warum stellt das reichste Land der Welt nicht alle besten Generäle der Welt ein, sodass für andere Länder keiner übrig bleibt?“
      Es gibt viele Gründe, warum das unmöglich ist, aber letztlich läuft es darauf hinaus, dass die Welt und die Menschheit zu groß und zu komplex sind, als dass ein einzelner Akteur alles oder auch nur den Großteil besitzen könnte. In allem steckt zu viel unterschiedliche Heterogenität. Es gibt viele Weltanschauungen und Loyalitäten, die über Geld hinausgehen.

  • Firefox hat ebenfalls Https First, aber offenbar muss man die Einstellung dom.security.https_first aktivieren.
    Wenn möglich, ist der „HTTPS-Only Mode“ sicher am besten.

    • Trotzdem muss man dem Drang widerstehen, auf „trotzdem erlauben“ zu klicken. Ehrlich gesagt würde ich wahrscheinlich selbst klicken, obwohl ich das Risiko kenne. Einfach, weil ich diese Website besuchen will.
      Solange der Prompt nicht extrem verdächtig aussieht, etwa wenn er bei einer Seite wie Google.com erscheint, von der man weiß, dass sie HTTPS unterstützt, löst das gar nichts.

  • Der in diesem Artikel verlinkte Beitrag von Citizen Lab enthält Details zum Man-in-the-Middle-Angriff. Es ist fast schon fraglich, ob man das überhaupt Angriff nennen kann; das Netzwerk ist darauf ausgelegt, bei Bedarf Inhalte zu injizieren.