Zero-Click-Schwachstellenkette bei Calendar-Einladungen in macOS

 (medium.com/@mikko-kenttala)
1 Punkte von GN⁺ 2024-09-14 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Fehler in der Verarbeitung von Einladungsanhängen in macOS Calendar ermöglichte Angreifern, beliebige Dateien innerhalb der Calendar-Sandbox zu schreiben und zu löschen; daraus entstand eine Kette bis hin zu Remote Code Execution und Zugriff auf Photos-Daten
  • Stufe 1, CVE-2022-46723, bereinigte Path-Traversal-Eingaben wie FILENAME=../../../PoC.txt im ATTACH-Abschnitt nicht korrekt, sodass Anhänge außerhalb des vorgesehenen Speicherorts abgelegt werden konnten
  • Die Remote-Code-Execution-Kette nutzte das Open File-Verhalten von Calendar während des Upgrades von Monterey auf Ventura, injizierte mehrere Dateien und kombinierte DMG, SMB-Mounts und ein eigenes URL-Schema
  • In der Photos-Stufe wurden per defaults import bösartige Einstellungen angewendet, um die System Photo Library auf /var/tmp/mypictures/Syndication.photoslibrary umzustellen und iCloud-Originalfotos in ein nicht durch TCC geschütztes Verzeichnis synchronisieren zu lassen
  • Apple behob alle zugehörigen Schwachstellen zwischen Oktober 2022 und September 2023; die Photos-Schwachstelle wurde als CVE-2023-40434, der Gatekeeper-Bypass als CVE-2023-40433 behandelt

Path Traversal bei Calendar-Anhängen

  • Eine bösartige Calendar-Einladung konnte Dateianhänge enthalten; wegen unzureichender Validierung der Anhangsdateinamen war Directory Traversal möglich
  • Angreifer konnten im ATTACH-Abschnitt einen beliebigen Pfad wie FILENAME=../../../PoC.txt angeben
    • Der normale Speicherort war ~/Library/Calendar/[CalendarID]/Attachments/[eventid]/
    • Beim verwundbaren Verhalten wurde die Datei unter ~/Library/Calendar/PoC.txt gespeichert
  • Existierte bereits eine Datei mit demselben Namen, wurde die neue Datei als PoC.txt-2 gespeichert; wenn später jedoch das vom Angreifer gesendete Event oder der Anhang gelöscht wurde, konnte die ursprüngliche Datei PoC.txt entfernt werden
  • Dieses Verhalten konnte auch genutzt werden, um bestehende Dateien innerhalb der Calendar-Sandbox im Dateisystem zu löschen
  • Die Schwachstelle war mindestens in der neuesten Version von macOS Monterey 12.5 vorhanden; macOS 13.0 beta4 war nachweislich nicht mehr verwundbar

Erweiterung zur Remote Code Execution

  • Die kurz vor der Veröffentlichung von macOS Ventura entdeckte Schwachstelle wurde durch den Versions-Upgrade-Prozess und die Open File-Funktion von Calendar zu Remote Code Execution erweitert
  • Der Angreifer injizierte über die Calendar-Schwachstelle zum Schreiben beliebiger Dateien mehrere Dateien und konfigurierte sie so, dass die RCE-Kette beim Upgrade von Monterey auf Ventura ausgelöst wurde

  • Aufbau der injizierten Dateien

    • 000Hacked-$RANDOM.calendar
      • Enthielt Calendar-Daten, die wie ein „Siri Suggested“-Calendar wirkten
      • Enthielt wiederkehrende Events und Benachrichtigungsfunktionen und öffnete andere injizierte Dateien
    • CalendarTruthFileMigrationInProgress
      • Eine Datei, die dafür sorgte, dass ein bestehender Calendar aus einem alten Format in die neue Datenbank aktualisiert und zusammengeführt wurde
    • CalPoCInit.dmg
      • Die erste Calendar-Benachrichtigung öffnete ~/Library/Calendars/CalPoCInit.dmg
      • Das Bookmark in der .DS_Store innerhalb des DMG enthielt eine Referenz auf ein Hintergrundbild auf einem externen Samba-Server
      • Selbst wenn CalPoCInit.dmg selbst unter Quarantäne stand, erfolgte das Mounten ohne quarantine flag
    • stage1.url
      • Die zweite Calendar-Benachrichtigung öffnete ~/Library/Calendars/stage1.url
      • Diese Datei enthielt eine file:///Volumes/CalPoCPayload/MyMidiTest.app-URL, die auf eine App im zuvor gemounteten Samba-Volume zeigte
      • Als Finder /Volumes/CalPoCPayload/ öffnete, wurde automatisch eine Indexierung ausgelöst und MyMidiTest.app indexiert
      • Die Info.plist des App-Bundles registrierte mymiditest als Handler für ein eigenes URL-Schema
    • stage2.url
      • Die dritte Calendar-Benachrichtigung öffnete ~/Library/Calendar/stage2.url
      • Diese Datei referenzierte mymiditest:// und startete die bösartige App ohne Benutzerinteraktion

Gatekeeper-Bypass und App-Ausführung

  • Die Ausführung von mymiditest:// war möglich, weil sich die App in einem durch den Exploit erstellten Samba-Mount befand und dieser Speicherort keinen quarantine flag hatte
  • Die mymiditest-App schrieb die für Stufe 3 benötigten Dateien nach /var/tmp/ und führte mit open /var/tmp/PhotosPoC.sh ein Skript in Terminal aus
  • Die gesamte Kette war so aufgebaut, dass sie mehrere Dateien injizierte, um aus der Calendar-Sandbox auszubrechen, anschließend mit einem SMB-Trick Gatekeeper-Abhilfemaßnahmen umging und danach beliebigen Code ausführte

Zugriff auf iCloud-Fotos durch Änderung der Photos-Einstellungen

  • Die Phase nach der Remote Code Execution konzentrierte sich darauf, Photos-Einstellungen zu ändern, um auf sensible Fotodaten des Nutzers zuzugreifen, insbesondere auf iCloud Photos
  • Normalerweise sollte TCC den Zugriff auf sensible Dateien wie Photos beschränken; durch Änderung der Photos-Einstellungen konnte die System Photo Library jedoch auf einen nicht durch TCC geschützten Pfad zeigen
  • Der Angreifer konnte eine Photos-Einstellungsdatei erstellen, die eine andere System Photo Library verwendete, und diese per defaults import importieren
  • In der PoC-Kette bereitete Stufe 2 automatisch Einstellungen vor, die /var/tmp/mypictures/Syndication.photoslibrary als System Photo Library nutzten
    • Die zugehörigen bösartigen Einstellungsdateien wurden unter /var/tmp/mypictures/*.plist erstellt
    • Laufende Photos-bezogene Anwendungen wurden beendet
    • Die ursprünglichen Einstellungen wurden unter /var/tmp/mypictures/*-orig.plist gesichert
    • Die bösartigen Einstellungen wurden aus /var/tmp/mypictures/ importiert
    • Die neue Fotomediathek wurde mit open /var/tmp/mypictures/Syndication.photoslibrary in Photos geöffnet
  • Syndication.photoslibrary war eine leere Vorlagen-Mediathek; sobald Photos mit ihr als neuer System Photo Library ausgeführt wurde, wurde die iCloud-Synchronisierung aktiviert und die Originaldateien in ein nicht geschütztes Verzeichnis heruntergeladen
  • Die auf die Festplatte synchronisierten Dateien wurden in ein neues Verzeichnis unter /var/tmp/PoCLoot$RANDOM/ kopiert
  • Mit geringfügigen Änderungen hätte der PoC die Daten auf eine externe Ressource kopieren oder per curl-Befehl an einen externen Webserver senden können

Zeitplan der Fixes und offene Bounty-Frage

  • Die gesamte Kette musste nacheinander mehrere macOS-Sicherheitsbarrieren überwinden
    • Mehrere Dateien wurden in Calendar injiziert, um die Sandbox zu umgehen und die nächsten Stufen zu aktivieren
    • Mit einem SMB-Trick wurden Gatekeeper-Abhilfemaßnahmen umgangen, um beliebigen Code auszuführen
    • TCC-Schutz wurde umgangen, um auf sensible Daten wie iCloud Photos zuzugreifen
  • Vor der Behebung hätte eine bösartige Calendar-Einladung an Apple-iCloud-Nutzer gesendet und iCloud Photos ohne Benutzerinteraktion gestohlen werden können
  • Apple behob alle zugehörigen Schwachstellen zwischen Oktober 2022 und September 2023

  • Timeline

    • 2022-08-08: Schreiben und Löschen beliebiger Dateien innerhalb der Calendar-Sandbox gemeldet
    • 2022-10-24: In macOS Monterey 12.6.1 und Ventura 13 behoben
      • Für diesen Punkt gab es keine CVE; Ventura beta3 war verwundbar
    • 2022-11-14: PoC eingereicht, der die Calendar-Schwachstelle auf beliebige Codeausführung und Gatekeeper-Bypass ausweitete
    • 2022-12-04: PoC zum Zugriff auf iCloud Photos eingereicht
    • 2023-02-20: Credit und CVE CVE-2022-46723 für die Calendar-Schwachstelle hinzugefügt
    • 2023-03-27: Gatekeeper-Bypass in macOS Ventura 13.3 behoben
      • Zu diesem Zeitpunkt gab es weder CVE noch Credit
    • 2023-09-26: Photos-Schwachstelle CVE-2023-40434 behoben und Credit vergeben
    • 2023-10-09: Bug Bounty für Gatekeeper-Bypass und Photos-Schwachstelle angekündigt
    • 2023-12-21: Credit CVE-2023-40433 für den Gatekeeper-Bypass vergeben
    • 2024-09-12: Für die ursprüngliche Calendar-Schwachstelle zum Schreiben und Löschen beliebiger Dateien, CVE-2022-46723, gab es weiterhin keine Bounty
    • Update vom 2024-10-20: Apple entschied, dass die Schwachstelle zum Schreiben und Löschen beliebiger Dateien in Calendar, CVE-2022-46723, nicht bounty-berechtigt sei, da sie nur macOS Monterey betraf und Ventura bereits in der Beta-Phase nicht mehr betroffen war

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-14
Kommentare auf Hacker News

  • Gut, dass ich die iCloud-Fotomediathek nicht nutze, aber es ist schon seltsam, dass ein neuer Speicherort keinerlei Schutz erhält, wenn man den Ort der Fotomediathek ändert.
    Wenn man /var/tmp/mypictures/Syndication.photoslibrary als Systemfotomediathek festlegt und Fotos öffnet, hätte ich erwartet, dass der Exploit fehlschlägt, weil die Fotos-App dieses Verzeichnis schützen müsste.
    Bei einem schnellen Test unter Sonoma 14.6.1 wurde einer App ohne Vollzugriff auf die Festplatte und ohne Foto-Berechtigungen der Zugriff auf den Ordner verweigert, wenn man mit gedrückter Option-Taste Fotos öffnet und in ~/Pictures eine neue Fotomediathek erstellt.
    Erstellt man die neue Fotomediathek jedoch in /tmp, konnte dieselbe App darauf zugreifen; dieses Verhalten ist verwirrend und inkonsistent.
    Wenn Apple wirklich unterstützen will, dass man die Fotomediathek an eine beliebige Stelle im Dateisystem verschiebt, muss auch der Schutz korrekt greifen.

    • Bis zu einem gewissen Grad ist das nachvollziehbar. /tmp war historisch gesehen in der Verzeichnishierarchie ein Ort, den jeder lesen und beschreiben konnte, und ist keine gute Wahl zum Speichern privater Daten.
    • TCC war schon immer in dieser Hinsicht etwas seltsam und ziemlich löchrig.
    • Unter Linux lässt sich inzwischen alles deutlich einfacher isolieren als unter macOS.
      Auch ohne AppArmor oder Firejail bekommen die meisten Dienste standardmäßig ein eigenes temporäres Verzeichnis.

  • In diesem Thread ist viel von Bug-Bounty-Auszahlungen die Rede, aber wenn ein großer Tech-Konzern mit einem laufenden Bounty-Programm keine Prämie zahlt, gibt es dafür meist wahrscheinlich einen guten Grund.
    Die Anreize solcher Programme sind nahezu vollständig darauf ausgerichtet, legitime Einreichungen zu vergüten.
    Das ist einer der seltenen Fälle, in denen die Anreize ziemlich gut ausgerichtet sind: Ein Unternehmen richtet ein Bounty-Programm ein, um eine bestimmte Art von Forschung zu fördern, und keine angemessene Belohnung zu zahlen, läuft diesem Ziel zuwider.
    Die zuständige Person auf Anbieterseite gibt ja nicht ihr eigenes Geld aus, und die Beträge sind aus Sicht des Unternehmens nicht relevant groß.
    Normalerweise sind die Mitglieder des Programmteams eher dazu motiviert, mehr auszuzahlen als weniger.

    • Nein. Der Grund ist, dass Apples Product-Security-Team, das Bug-Bountys untersucht und auszahlt, schlecht geführt und ineffizient ist.
      Es wurde kürzlich aus dem SWE Program Office zu SEAR (Security Engineering & Arch) verschoben, und der Manager wurde vor Kurzem hinausgeworfen und ist zu AirBNB gegangen.
      Die meisten Teammitglieder sind auf dem Niveau frisch graduierter ICT2/ICT3, Leute, die anderswo im Unternehmen nicht einmal Coding-Interviews bestehen würden, und arbeiten hauptsächlich wie Bug-Triager.
      Sie verbringen mehr Zeit auf Konferenzen und beim Abhängen mit Hackern als vor dem Computer.
      Der Graph im Portal „laufende Untersuchung“ steigt immer weiter; E-Mails häufen sich nur an, und es wird nicht einmal versucht, aufzuholen.
      Leute, die eine Bounty bekommen sollten, sie aber nicht erhalten, müssen Ivan, den Leiter von SEAR, öffentlich auf Twitter unter Druck setzen, wenn sie Fortschritt sehen wollen.
    • Kann sein. Apples schlechtes Bug-Bounty-Programm ist vielleicht eher das Ergebnis von Inkompetenz als von absichtlicher Böswilligkeit.
      Aber ist das für Sicherheitsforscher oder die Öffentlichkeit wichtig? Nein. Unabhängig davon, warum es kaputt ist, muss Apple sein Bounty-Programm reparieren.
      Letztlich ist dieser Blogpost nur ein weiteres Beispiel auf einem bereits großen Haufen[1][2][3][4][5].
      1: https://arstechnica.com/information-technology/2021/09/three...
      2: https://mjtsai.com/blog/2021/07/13/more-trouble-with-the-app...
      3: https://medium.com/macoclock/apple-security-bounty-a-persona...
      4: https://theevilbit.github.io/posts/experiences_with_asb/
      5: https://shail-official.medium.com/accessing-apples-internal-...
    • Wenn damit nicht gemeint ist, dass der Autor die Situation verzerrt hat, sehe ich nicht, welchen „sehr guten Grund“ es geben könnte, wenn es klare Aufzeichnungen gibt, dass jemand den Bug lange vor seiner Behebung gemeldet hat.
      Im besten Fall wirkt es wie klassische träge Bürokratie, und das ist kein besonders guter Grund.
      Wenn das Unternehmen so etwas wirklich fördern würde, gäbe es keinen Grund, warum die Freigabe länger als ein Jahr dauern sollte.
      Die Logik mag stimmen, aber angesichts solcher Situationen fällt es schwer zu sagen, „das Unternehmen ist geizig oder, wie in fast allen anderen Situationen, übermäßig bürokratisch“ sei weniger plausibel als „es gibt einen legitimen Grund, eine dem Anschein nach verdiente Bounty nicht auszuzahlen“.
      Wenn der Autor den Vorfall korrekt beschreibt, wirkt es viel plausibler, dass die Anreize, die überall sonst wirken, auch in diesen Bereich eingesickert sind.
    • Hast du schon einmal Sicherheits- oder Datenschutzprobleme an Apple gemeldet? Ich schon. Ich habe aktuell mindestens einen noch offenen Fall bei Apple.
      Einer davon ließe sich ohne Nebenwirkungen mit einer einzigen Codezeile beheben, ist aber seit zwei Jahren offen.
      Apples Security-Team hat entweder kein Interesse oder ist inkompetent; beides ist schlecht.
      Es war eine der ärgerlichsten und frustrierendsten Erfahrungen, die ich im Computing je gemacht habe.
      Sie wollen offensichtlich nicht, dass man das Problem öffentlich teilt, ziehen es aber auf unbestimmte Zeit in die Länge.
      Ehrlich gesagt bin ich nahe an meiner Grenze.
      Die Bounty ist mir völlig egal; ich will einfach, dass der Bug behoben wird.
      Wenn ich glauben könnte, dass die Sache ernsthaft behandelt wird, würde ich ihnen so viel Spielraum wie möglich geben, aber das fällt schwer zu glauben.
    • Es gab viele dokumentierte Fälle, in denen große Tech-Konzerne die Auszahlung schlicht verweigert haben.
      Etwa indem sie die Teilnahmebedingungen nachträglich änderten, Sicherheitsforscher stillschweigend aus einem laufenden Bounty-Programm ausschlossen, gutgläubige Offenlegungen an Strafverfolgungsbehörden weitergaben oder sich Manager extrem kleinkariert verhielten.
      Gerade weil „die Beträge aus Sicht des Unternehmens keine Rolle spielen“, ist diese schlampige Abwicklung umso schwerer zu verstehen.

  • Das ist eine weitere Methode, am Quarantine-Flag herumzudrehen. Die andere ist dieser Link: https://imlzq.com/apple/macos/2024/08/24/Unveiling-Mac-Secur...
    Es sieht so aus, als könnten viel zu viele verschiedene Systeme dieses Quarantine-Flag verändern.

  • „Ein Angreifer kann dem Opfer eine bösartige Kalendereinladung mit Dateianhang schicken … Vor der Korrektur konnte man jedem Apple-iCloud-Nutzer eine bösartige Kalendereinladung senden und ohne Nutzerinteraktion iCloud Photos stehlen.“
    Wie groß ist dieser Umfang eigentlich? Bedeutet das, dass jede Person von überall in macOS irgendjemandem, der iCloud nutzt, beliebige Einladungen schicken kann? Wer will so etwas nicht?

    • Nicht sarkastisch gemeint, aber wie sollten Einladungen denn sonst funktionieren?
    • Ich verstehe es nicht. Worin unterscheidet sich der Empfang einer Kalendereinladung vom Empfang einer anderen E-Mail? Verarbeitet macOS per Design bei Kalendereinladungen irgendetwas automatisch?
    • Ist das bei Google Calendar nicht dasselbe?
    • Das scheint nicht nur iCloud-spezifisch zu sein. Im Allgemeinen werden Einladungen automatisch aus E-Mails erkannt.
      Kalendereinladungen sind schon lange eine Quelle von Spam, daher ist es nicht überraschend, dass es auch Schwachstellen gibt.

  • „Wenn die vom Angreifer angegebene Datei bereits existiert, wird die angegebene Datei unter dem Namen PoC.txt-2 gespeichert. Wird das vom Angreifer gesendete Event/der Anhang später jedoch gelöscht, wird die Datei mit dem ursprünglichen Namen (PoC.txt) entfernt. Diese Schwachstelle kann genutzt werden, um bestehende Dateien innerhalb der Dateisystem-‚Sandbox‘ zu löschen.“
    Das ist schlechtes Engineering.

  • Der Status der Belohnung hier gefällt mir nicht besonders. Ist es für Sicherheitsforscher üblich, bei Apple oder anderen FAANG-ähnlichen Unternehmen so lange zu warten?

    • Sehr sogar.

  • Schon Stufe 1 allein ist eine absurde Schwachstelle. Wie konnte Apple das nicht bedacht haben?
    „Der Angreifer kann im Abschnitt ATTACH einen beliebigen Pfad für die Datei setzen, etwa FILENAME=../../../PoC.txt, und so erfolgreich einen Directory-Traversal-Angriff durchführen.“

    • Das zeigt ein größeres Problem, das es wohl in jedem Unternehmen geben kann. Jemand bei Apple hat dafür bestimmt eine Library-Funktion geschrieben, die das sicher behandelt, aber wie kann man erzwingen, dass diese Funktion auch verwendet wird?
      Besonders wenn auch die Code-Reviewer diese Library nicht kennen, ist es schwer zu verhindern, dass jemand es von Grund auf erneut unsicher implementiert.
      Gibt es für dieses Problem eine moderne Lösung?

  • Immer wenn eine große Sicherheitslücke auftaucht, die nichts mit Memory Safety zu tun hat, bin ich seltsam begeistert.
    Ich weiß, das ist etwas kleinlich, aber mir gefällt die Vorstellung, dass all die Zeit und Energie, die in Rust geflossen ist, am Ende durch einen einzigen Path-Traversal-Bug zunichtegemacht wird.

  • Verhindert der Lockdown Mode das?

    • Reine Spekulation, aber ich hoffe es.
      Wenn man an frühere Zero-Click-Exploits mit Bildanhängen denkt, wirkt es so, als sei der Lockdown Mode genau dafür gemacht worden, und ich vermute, dass alle Dateien auf diese Weise behandelt werden.

  • Wow. Ein ziemlich altmodischer Exploit.
    An Pfade in Dateinamen erinnere ich mich noch, das vor etwa 10 Jahren gelesen zu haben.