NetAuthAgent-Schwachstelle unter macOS, durch die Passwörter hätten preisgegeben werden können

• Apple hat CVE-2024-54471 in macOS Sequoia 15.1, Sonoma 14.7.1 und Ventura 13.7.1, veröffentlicht am 28. Oktober 2024, behoben; in Umgebungen vor dem Update konnten über NetAuthAgent gespeicherte Zugangsdaten offengelegt werden
• Kern des Problems war, dass der MIG-Server von NetAuthAgent Routinen zum Abfragen, Erstellen und teilweisen Überschreiben von Dateiserver-Zugangsdaten offenlegte, ohne den Absender der Nachricht zu prüfen
• Ein Angreifer konnte Nachrichten an den Mach-Service com.apple.netauth.user.gui senden, NetAuthAgent dazu bringen, stellvertretend internet password-Einträge im Keychain abzufragen, und so Benutzernamen und Passwörter erhalten
• Die Auswirkungen beschränkten sich nicht auf per „Connect to Server“ im Finder gespeicherte Zugangsdaten für FTP, Samba, WebDAV und Druckserver; über eine separate Chain konnte dies bis zur Offenlegung von iCloud-Kontoinformationen und API-Tokens führen
• Nach dem Patch prüft NetAuthAgent anhand des audit token der Mach-Nachricht die Entitlements des sendenden Prozesses und antwortet nicht, wenn com.apple.private.netauth.useragent.allow=true fehlt

---

Patch-Umfang von CVE-2024-54471

• CVE-2024-54471 ist eine macOS-Schwachstelle, die im Rahmen von Apples Sicherheitsupdates behoben wurde
• Die Versionen mit dem Patch wurden alle am 28. Oktober 2024 veröffentlicht
  • macOS Sequoia 15.1
  • macOS Sonoma 14.7.1
  • macOS Ventura 13.7.1
• macOS-Geräte, die noch nicht auf diese Versionen aktualisiert wurden, sollten umgehend aktualisiert werden

macOS-IPC und Mach-basierte Architektur

• Der Kernel von macOS und den meisten Apple-Betriebssystemen ist XNU, ein Hybridkernel mit BSD-Komponenten und einer stark modifizierten Variante des Mach-Kernels
• Mach basiert auch im modernen macOS auf vier Abstraktionen
  • task: die Ausführungsumgebung, in der Threads laufen, und die Basiseinheit für Ressourcenzuweisung
  • thread: die Basiseinheit der CPU-Nutzung
  • port: ein Kommunikationskanal, der einer vom Kernel geschützten Nachrichtenwarteschlange entspricht
  • message: eine Sammlung typisierter Datenobjekte für die Kommunikation zwischen Threads
• Ports in Mach sind keine direkt im Userspace sichtbaren Queues, sondern werden als port rights innerhalb des Port-Namensraums eines jeweiligen Task behandelt
• Es gibt zwei zentrale Rechte
  • send right: kann von mehreren Tasks für denselben Port gehalten werden
  • receive right: kann nur von einem Task gehalten werden
• Diese Struktur bildet ein Client-Server-Modell, bei dem ein Server-Task Nachrichten von mehreren Client-Tasks empfängt
• Der bootstrap server von macOS erhält einen Port, für den alle Tasks ein send right besitzen, und ermöglicht Clients, anhand eines String-Namens das send right eines registrierten Mach-Service anzufordern

Authentifizierungslücke im MIG-Server

• MIG ist ein Werkzeug, das das Senden und Empfangen von Mach-Nachrichten in eine funktionale Schnittstelle verpackt
• MIG besteht aus einer pseudo-C-IDL und einem Compiler und erzeugt aus einer IDL-Datei folgende Dateien
  • C-Quellcode für den Client
  • C-Quellcode für den Server
  • C-Header, die von beiden Seiten verwendet werden
• Jede Funktion wird als routine bezeichnet, eine Sammlung von Routinen als subsystem; Subsystem-Nummer und Routine-Index spiegeln sich in der Message-ID wider
• In der Userspace-Kommunikation von macOS wurde MIG weitgehend von der XPC API verdrängt, doch auch XPC ist auf Mach-Nachrichten aufgebaut
• Ein MIG-Server selbst besitzt keinen erzwungenen Authentifizierungsmechanismus; wenn der Server den Absender nicht prüft, kann jeder Task mit send right Remote-Routinen aufrufen
• Für die Suche nach MIG-Servern ist blacktops ipsw CLI nützlich; dabei wird nach Binärdateien gesucht, die das Symbol NDR_record importieren
  • Diese Methode kann nicht nur MIG-Server, sondern auch MIG-Clients finden
  • Server- und Client-Code lassen sich in Disassemblern oder Decompilern relativ leicht unterscheiden

Zugangsdaten, die NetAuthAgent verarbeitet

• NetAuthAgent ist ein User-Agent in macOS, der Zugangsdaten für Dateiserver wie FTP, Samba und WebDAV verarbeitet
• Der Authentifizierungsdialog, der beim Verbinden mit einem Dateiserver über „Go → Connect To Server“ im Finder erscheint, wird von NetAuthAgent oder verwandten Prozessen bereitgestellt
• Wenn der Nutzer die Checkbox zum Speichern des Passworts auswählt, werden die Zugangsdaten im macOS-Keychain gespeichert
• NetAuthAgent speichert Passwörter nicht direkt, sondern nutzt den Keychain als zentralen Secret Store
• Keychain-Einträge besitzen eigene Zugriffskontrolllisten, die normalerweise verhindern, dass Anwendungen auf Geheimnisse zugreifen, auf die sie nicht zugreifen sollten
• Wenn jedoch ein bestimmter Prozess einen Mechanismus offenlegt, der Keychain-Abfragen stellvertretend für andere Prozesse ausführt, kann das gesamte Sicherheitsmodell geschwächt werden

Der verwundbare MIG-Service von NetAuthAgent

• NetAuthAgent legte einen MIG-Server offen, der über den bootstrap server auffindbar war
• Der Service-Name lautet com.apple.netauth.user.gui
• Dieser Server bot Routinen zum Lesen, Erstellen und in manchen Fällen Überschreiben von Dateiserver-Zugangsdaten an
• Vor dem Patch prüften diese Routinen den Absender der Nachrichten nicht
• Routine 19, Message-ID 40219, konnte Abfragen von internet password-Klasseneinträgen im Keychain proxien
• Diese Routine nahm ein serialisiertes Options-Dictionary als out-of-line data descriptor entgegen und gab Benutzername und Passwort als zwei out-of-line data descriptors zurück

Angriffsablauf und Aufbau des PoC

• Der PoC nutzt das in Swift geschriebene Sicherheitsforschungs-Tool Kass, um Mach-Nachrichten und MIG-Clients zu handhaben
• Der NetAuthAgent-Client wird mit folgenden Werten definiert
  • Service-Name: com.apple.netauth.user.gui
  • Routine-ID auf Subsystem-Basis: 40200
• Abfrageoptionen werden als Property List serialisiert und können Felder wie Scheme, Host, AlternatePort und Path enthalten
• Die macOS-Keychain-API SecItemCopyMatching kann, wenn keine geheimen Werte angefordert werden, auch von nicht berechtigten Prozessen genutzt werden, um Metadaten von Keychain-Einträgen zu erhalten
• Auch Zugriffskontrolllisten sind als Metadaten zugänglich, sodass geprüft werden konnte, ob die Liste der trusted applications eines Eintrags /System/Library/CoreServices/NetAuthAgent.app enthielt
• Angriffscode konnte internet password-Einträge durchlaufen, auf die NetAuthAgent zugreifen konnte, und folgende Informationen extrahieren
  • Anzeigename
  • Protokoll
  • Host
  • Port
  • Pfad
  • Benutzername
  • Passwort

Auswirkungen der Offenlegung von Dateiserver-Zugangsdaten

• Vor dem Patch konnte ein bösartiger Prozess, der ein send right für NetAuthAgent erlangte, sämtliche Dateiserver-Zugangsdaten exfiltrieren
• In Unternehmensumgebungen könnten diese Zugangsdaten SSO-Zugangsdaten sein, wodurch ein Angreifer potenziell auf mehrere Ressourcen in Firmensystemen zugreifen könnte
• Wie verbreitet die Nutzung der Finder-Funktion Connect to Server ist, ist unbekannt; Hilfedokumente mehrerer Hochschulen und Bildungseinrichtungen wiesen Studierende und Mitarbeitende jedoch auf diese Funktion hin, und einige empfahlen, die Checkbox zum Speichern im Keychain zu aktivieren
• Auch Anleitungen von Druckserver-Anbietern zum Verbinden mit Druckern wurden gefunden; NetAuthAgent verarbeitet auch Zugangsdaten für Druckserver
• Mindestens ein Dokument empfahl, die Speichern-Checkbox nicht auszuwählen, weil die Keychain Access-App für normale Nutzer beim Aktualisieren gespeicherter Passwörter schwer zu bedienen sei
• Wenn auf verwalteten Geräten dieselben Zugangsdaten auch als Superuser-Zugangsdaten verwendet werden, könnte dies zu Privilegienausweitung führen; mangels Tests auf verwalteten Geräten wurde dies jedoch nicht bestätigt
• Auch wenn Privatnutzer per Finder auf ein NAS zugreifen und die Zugangsdaten speichern, konnten die NAS-Zugangsdaten einem Angreifer offengelegt werden
• Wenn dieselben Zugangsdaten für andere Internetkonten wiederverwendet wurden, könnten auch diese Konten kompromittiert werden
• FTP, Samba und WebDAV haben klar definierte Schnittstellen, wodurch sich nach einem Credential Leak das Durchsuchen und Exfiltrieren von Serverdateien leicht automatisieren lässt

Weitere Ausnutzung über den Keychain

• Da NetAuthAgent auch eine Routine zum Erstellen von Keychain-Einträgen offenlegte, konnte ein bösartiger Prozess beliebige Daten im Feld password verstecken
• Diese Methode kann direkte Schreibvorgänge auf die Festplatte vermeiden und so als Datenversteck dienen, das Sicherheitssoftware umgeht
• Über Sicherheitssoftware, die verdächtige Keychain-Einträge explizit prüft, ist nichts bekannt
• Ein bösartiger Prozess konnte außerdem legitime Zugangsdaten im Keychain speichern
• Für sich allein dürfte dieses Verhalten nur begrenzte Wirkung haben, könnte aber in kombinierten Angriffen genutzt werden, bei denen ein Angreifer Zugangsdaten für einen von ihm kontrollierten Dateiserver speichert und den Nutzer anschließend per Social Engineering dorthin lenkt

Exploit-Chain bis hin zu iCloud-API-Tokens

• Auch Nutzer, die Connect to Server nicht verwenden, waren nicht frei von den Auswirkungen dieser Schwachstelle
• Auf den meisten macOS-Geräten existieren Keychain-Einträge mit einer ACL, die weit genug gefasst ist, dass NetAuthAgent darauf zugreifen kann
• Dieser Keychain-Eintrag enthält einen Entschlüsselungsschlüssel, mit dem eine bestimmte Datei auf der Festplatte entschlüsselt wird
• Diese Datei enthält die iCloud-Kontoinformationen und API-Tokens des Nutzers
• Ein Angreifer konnte mithilfe des Keychain-Eintrags und der Datei an bekannter Stelle folgende Informationen erhalten
  • Vor- und Nachname
  • E-Mail-Adresse
  • E-Mail-Aliasse
  • aktivierte Funktionen und Endpoints
  • mehrere langlebige API-Tokens

Mögliche Aktionen mit iCloud-Tokens

• Frühere Forschung von Wojciech Reguła zeigte, dass dieselben API-Tokens auf anderem Wege gefunden und zur Exfiltration folgender Daten verwendet werden konnten
  • Contacts
  • Calendars
  • Reminders
  • Standort des Nutzers über Find My
• Von diesen Ergebnissen wurden alle Punkte außer Reminders reproduziert
• Reminders neuer und migrierter Accounts wurden von Apple in das sicherere CloudKit verschoben und sind nur noch in verschlüsselter Form zugänglich
• Zusätzlich waren folgende Aktionen möglich
  • Exfiltration von Kontaktfotos
  • CloudKit-Abfragen, jedoch ohne Entschlüsselung
  • Exfiltration von Daten aus dem iCloud key-value store
  • Exfiltration von iCloud-Backup-Metadaten, einschließlich Geräteseriennummern
  • Offenlegung des Standorts anderer Geräte des Nutzers über Find My
  • Offenlegung des Standorts von Freunden des Nutzers über Find My
  • Ausführen von Sperren, Löschen und Tonwiedergabe über Find My
• Die Entschlüsselung von CloudKit-Daten wurde untersucht, aber nicht abgeschlossen
• Es wurde nicht ausgeschlossen, dass kommerzielle Forensik-Anbieter diese API-Tokens, bei Bedarf zusammen mit der PIN eines iOS-Geräts, verwenden könnten, um CloudKit-Daten oder CloudKit-Daten aus iCloud-Backups zu entschlüsseln

Apples Korrektur

• Nach dem Patch prüft NetAuthAgent beim Empfang einer Nachricht zuerst das entitlement des Absenders
• Entitlements sind Key-Value-Paare, die beim Codesignieren an ein Binary angehängt werden
• Unter macOS mit Standard-Sicherheitseinstellungen prüft Apple Mobile File Integrity beim Start eines Prozesses restricted entitlements und beendet den Prozess, wenn kein passendes provisioning profile vorhanden ist
• Da das provisioning profile von Apple signiert sein muss, ist diese Prüfung so ausgelegt, dass sie schwer zu umgehen ist
• Das von NetAuthAgent geforderte entitlement lautet wie folgt
  • Schlüssel: com.apple.private.netauth.useragent.allow
  • Wert: boolean true
• NetAuthAgent antwortet nicht an Absender ohne dieses entitlement
• Der Trailer, den der Kernel beim Empfang an Mach-Nachrichten anhängt, enthält ein audit token
• Der empfangende Task kann mit dem audit token den sendenden Task identifizieren, beim Kernel das entitlement-Dictionary dieses Tasks anfordern und den Wert prüfen

Schwache Glieder in der Sicherheitsarchitektur

• Selbst wenn Dateiserver-Zugangsdaten so gespeichert wurden, dass nur bestimmte Anwendungen darauf zugreifen können, wird diese Anwendung zum schwachen Glied, wenn sie Abfragebefehle anderer Anwendungen akzeptiert
• Selbst wenn iCloud-API-Tokens in einer verschlüsselten Datei auf der Festplatte gespeichert sind, wird die ACL zum schwachen Glied, wenn der Entschlüsselungsschlüssel in einem Keychain-Eintrag mit breiter ACL liegt
• macOS verfügt über Sicherheitsmechanismen, die Prozessinjektion erschweren, und die gesamte Sicherheitsinfrastruktur gilt als vergleichsweise stark
• Wie diese Schwachstelle zeigt, kann jedoch bereits eine einfache fehlende Absenderprüfung zur Offenlegung von Dateiserver-Zugangsdaten und iCloud-API-Tokens führen

Empfohlene Maßnahmen für Nutzer

• Falls noch möglich, wird empfohlen, Advanced Data Protection zu aktivieren
• Wer iCloud nicht im Webbrowser nutzt, kann außerdem den Webzugriff auf iCloud-Daten deaktivieren
• Die iCloud-Website verwendet in manchen Fällen andere API-Endpoints als Apples iCloud-Apps
• Über diese Schwachstelle ist der Zugriff auf Tokens nicht mehr möglich, doch sie könnten durch frühere Schwachstellen offengelegt worden sein und künftig durch andere Schwachstellen erneut offengelegt werden
• Es gibt keine Belege dafür, dass dieser Exploit von böswilligen Akteuren genutzt oder entdeckt wurde
• Wer dennoch besonders besorgt über den Missbrauch von Zugangsdaten ist, sollte Passwörter ändern
• Geräte, die seit Oktober 2024 kein macOS-Update erhalten haben, sollten sofort aktualisiert werden

[GN⁺]

Meinungen auf Hacker News

• Gut geschriebener Artikel; erinnert mich an den Zero-Day, bei dem sich ein Root-Login durch zweimaliges Eingeben eines leeren Passworts umgehen ließ, den Apple damals in gewissem Maß unter den Teppich zu kehren versuchte. Das war etwa 2017, vielleicht auch 2018.
  Wenn man irgendwo in einer Root-Login-Box den Admin-Benutzernamen eingab und das Passwort leer ließ, hieß es beim ersten Versuch, das Passwort sei falsch; schloss man die Warnung und klickte ein zweites Mal, war man als dieser Benutzer eingeloggt.
  Das war an dem Tag zu 100 % reproduzierbar und wurde kurz nachdem es sich in den sozialen Medien verbreitet hatte gepatcht, wirkte aber trotzdem wie ein gewaltiges Oversight. Rund um die Authentifizierungsmechanismen des Mac scheinen noch alte Altlasten übrig zu sein, und interessant ist auch, dass das Port-System des Mach-Kernels erwähnt wird.

  • Die Formulierung leeres Passwort zweimal erinnert mich an die Zeit, als meine Katze sich auf die Tastatur setzte und eine Sun 3/60 hackte.
    Als der Benutzernamen-Puffer 256 beliebige Zeichen erreichte, crashte XDM und startete eine Root-Shell. Allerdings war das Anfang der 90er, als alle beim Thema Sicherheit noch deutlich naiver waren.
  • Scheint 2017 gewesen zu sein; der damalige Beitrag hieß „macOS High Sierra: Anyone can login as “root” with empty password“ – 3001 Punkte | 1073 Kommentare – https://news.ycombinator.com/item?id=15800676
  • Das ist gar nichts. Früher konnte man jahrelang das FileVault-Passwort beliebiger Nutzer mit einer einzigen grep-Zeile aus der Page File ziehen, und es funktionierte zu 100 %.
  • Wenn man etwas über Mach weiß, ist es eher erstaunlich, dieses Kernsystem nicht zu kennen. Für mich ist gerade das Port-System das prägende Faktum, mit dem man Mach erklärt.
  • Zu Logins ohne Passwort hatte ich auch CVE-2011-3226 gemeldet; es wird hier referenziert: https://support.apple.com/en-us/103345

• „ACLs don't“: https://waterken.sourceforge.net/aclsdont/current.pdf

• Der Artikel wurde geringfügig korrigiert: Die Entitlement-Prüfung liegt nicht in der Mach-Schicht des Kernels.
  https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3
  Es ist eine Änderung um ein einziges Wort, die einen sachlichen Fehler in der Erklärung des XNU-Verhaltens behebt.

• Die Stelle „Wenn ein Prozess einen Mechanismus offenlegt, durch den andere Prozesse Keychain-Abfragen faktisch über ihn proxien können, kann das die Sicherheit des gesamten Systems schwächen“ sieht nach einem Confused-Deputy-Problem aus: https://en.wikipedia.org/wiki/Confused_deputy_problem
  Ein Capability-basiertes Design sollte solche Probleme systematisch verhindern können.

  • Entitlements lassen sich wohl ebenfalls als eine Art Capability betrachten. Dann stimmt das, und die tatsächliche Lösung bestand auch darin, dass man ein Entitlement benötigt, um mit dem Daemon selbst zu sprechen.

• Ich frage mich, wo der Autor den eigentlichen PoC-Code bereitgestellt hat. Ich würde gern ein paar Tests zu den Mitigations machen; Beispielcode sehe ich zwar, aber er wirkt unvollständig.
  Wie groß ist das reale Risiko?

  • Der PoC-Code sollte funktionieren. Man muss lediglich Kass als Abhängigkeit installieren. Wenn es danach noch ein anderes Problem gibt, würde mich interessieren, welches.
    Was das Risiko angeht: Eine App, die ein Send Right für NetAuthAgent bekommen kann – also praktisch fast jede nicht gesandboxte App –, kann NetAuthAgent stillschweigend nach gespeicherten Zugangsdaten für File Drives wie FTP, WebDAV oder Samba fragen. Das kann außerdem zum vollständigen Abfluss von iCloud-Kontakten und -Kalendern sowie weiteren iCloud-bezogenen Daten führen.
    Sandboxing macht das schwieriger, aber nicht unmöglich. Wenn du auf dem aktuellen Stand bist, liegt das Risiko bei 0; der Patch kam im Oktober letzten Jahres, also sollte man ehrlich gesagt längst aktualisiert haben. Wenn du nicht aktualisiert hast und es auch künftig nicht vorhast, ist das Risiko deutlich größer, sofern du nicht ausnahmslos jeden Prozess überprüfst, der auf dem Gerät läuft.

• Sehr ausführlicher Artikel, und ich fand es gut, dass auch die Geschichte mehrerer Kernel behandelt wurde. Bei einem Beitrag über ein ernstes Sicherheitsproblem wäre es aber hilfreich, gleich am Anfang eine sehr kurze Erklärung zu Impact, Angriffsbedingungen und dazu zu haben, ob es sich um einen Logikfehler oder Memory Corruption handelt.
  Es reicht völlig, wenn es kurz genug ist, um entscheiden zu können, ob man den Rest lesen will.

  • Danke für das Feedback. Ich habe den Kernpunkt absichtlich etwas später gebracht, damit die Leser weiterlesen, aber ich verstehe diese Sichtweise gut.

• Wirklich interessanter Artikel. Ich wusste nicht, dass hinter der Entstehung von Mach und dem Darwin-Kernel so viel Hintergrundgeschichte steckt.

  • Davon gibt es ziemlich viel. Mach geht bis auf Accent, einen noch früheren CMU-Kernel, zurück: https://en.wikipedia.org/wiki/Accent_kernel

• Inzwischen fühlt sich Mach wie eine verlässliche Quelle für macOS-Bugs an. Ich weiß, dass Apple viel daran absichert, aber gibt es einen Weg, sich vollständig von Mach zu lösen?

  • Die Ursache des Bugs sehe ich hier eher in der fehlenden Entitlement-Prüfung als in Mach. Entitlements sind ehrlich gesagt ein sehr gutes Sicherheitssystem, aber opt-in.
    Wenn ein Daemon das Entitlement nicht prüft, ist er nicht sicher. Man sollte eher die Art der Nutzung kritisieren als den Messaging-Mechanismus.
    Tatsächlich braucht jedes abgesicherte Messaging-System mehr als bloße Nachrichtenübermittlung, etwa eine Überprüfung des Absenders. Das bekommt man bei einem Low-Level-Kommunikationsprotokoll wie Mach nicht einfach so gratis dazu – es sei denn, Apple überarbeitet den MIG-Compiler und fügt Entitlement-Prüfungen hinzu.
    Mach ist hervorragend, wenn es zusammen mit Entitlement-Prüfungen verwendet wird.
  • Kürzlich gab es einen Artikel darüber, dass immer mehr Teile aus Mach heraus verlagert werden: teils nach L4, teils in den Userspace.
    Technisch können dadurch mehr unterschiedliche Komponenten nebeneinander existieren, was die potenzielle Angriffsfläche vergrößern könnte. Spezialisiertere Flächen können die Kontrolle aber vereinfachen und letztlich dazu führen, dass diese Flächen besser geschützt werden.