Im Zuge der immer weiter steigenden Bedeutung von Datenschutz in digitalen Produkten hat Apple mit seinem Betriebssystem iOS eine Reihe von Mechanismen eingeführt, um Nutzerdaten vor unbefugtem Zugriff zu schützen. Insbesondere spielt das System namens Transparency, Consent, and Control (TCC) eine Schlüsselrolle, indem es Apps zwingt, die Einwilligung der Nutzer einzuholen, bevor auf sensible Daten oder Funktionen wie Kontakte, Fotos, Mikrofon, Kamera oder auch Bluetooth Low Energy (LE) zugegriffen werden darf. Gerade bei Bluetooth LE besteht das Risiko, dass Apps mit dessen Hilfe Rückschlüsse auf die Anwesenheit und Identität von Geräten in der Umgebung ziehen und damit Nutzerprofiling und Tracking ermöglichen können. Aus diesem Grund hat Apple bereits mit iOS 13 damit begonnen, für den Zugriff auf Bluetooth LE eine explizite Nutzererlaubnis einzufordern. Mit iOS 18 wurde dieser Prozess weiterentwickelt, indem die Erlaubnisaufforderung um zusätzliche Informationen ergänzt wurde.
So zeigt die Berechtigungsanfrage nun an, wie viele Bluetooth-Geräte potenziell erreichbar sind und beinhaltet eine Mini-Karte, auf der einige der Geräte grafisch dargestellt werden. Diese Neuerung sollte die Transparenz erhöhen und das Bewusstsein der Nutzer für die möglichen Datenschutzrisiken stärken. Doch gerade diese gut gemeinte Maßnahme führte zu einer unvorhergesehenen Sicherheitslücke, die von einem Entwickler entdeckt wurde und unter der Bezeichnung CVE-2025-31212 bekannt wurde. Die Schwachstelle liegt darin, wie das System die Daten, die für den Berechtigungsdialog benötigt werden, verarbeitet und an die App übermittelt. Im Kern empfängt die App bereits vor Einholung der Nutzerbestätigung Informationen über in der Nähe befindliche Bluetooth LE Geräte.
Dies erfolgt über eine Schnittstelle, die zwischen der App und dem Bluetooth-Daemon läuft und ursprünglich dazu gedacht war, die Daten zur Darstellung des Informationsdialogs bereitzustellen. Im Detail arbeitet die CoreBluetooth-Bibliothek, welche Apps für die Bluetooth-Kommunikation nutzen, bei der Initialisierung des zentralen Managers, der als Bindeglied fungiert, über eine XPC-Verbindung mit dem Bluetooth-Daemon. Dabei sendet der zentrale Manager eine Anfrage, auf die der Daemon mit einer Antwort zurückkommt, die unter anderem enthält, dass für den Zugriff eine Erlaubnis benötigt wird, aber auch detaillierte Informationen über die Anzahl der gefundenen Geräte sowie deren Identifizierungsmerkmale und Signalstärken. Diese Daten werden von der App genutzt, um den Berechtigungsdialog mit Informationen anzureichern, sodass der Nutzer nachvollziehen kann, welche Geräte in seinem Umfeld erkannt werden. Das Problem tritt auf, weil diese Informationen bereits bei der Kommunikation zwischen Daemon und App an die App geliefert werden, bevor die Nutzererlaubnis vorliegt.
Somit kann eine App diesen Datenstrom abgreifen und ohne jemals eine Erlaubnis vom Nutzer einzuholen, umfangreiche Informationen über Bluetooth-Geräte in der Nähe sammeln und auswerten. Dabei ist es unerheblich, ob die App überhaupt die CoreBluetooth-Funktionalität nutzt oder die geforderte Datenschutzbeschreibung im System hinterlegt hat. Die Forschungen zeigten, dass es genügte, den beschriebenen Handshake mit dem Daemon regelmäßig durchzuführen, um fortlaufend aktualisierte Listen von Bluetooth-Geräten zu sammeln. Diese Listen enthalten nicht nur technische Daten wie Signalstärke (RSSI), sondern auch vom Nutzer vergebene Namen der Geräte, die häufig Rückschlüsse auf die Person oder den Standort zulassen. Die Gefahren, die sich daraus ergeben, sind vielfältig.
So könnten bösartige Apps solche Informationen aggregieren und an Server übertragen, um Nutzerprofile zu erstellen oder Bewegungsprofile anhand der erfassten Geräte zu verfolgen. Geräte-Labels wie „Guilherme’s Apple Watch“ oder „Aqara Smart Door Lock“ geben deutlich Auskunft über Besitzverhältnisse und potenzielle Aufenthaltsorte der Nutzer. Ein weiteres erschreckendes Detail war, dass eine manipulierte App nicht nur die Daten abgreifen konnte, sondern auch den Berechtigungsdialog selbst verändern konnte. Indem die App Methoden der CoreBluetooth-Bibliothek überschreibt, lässt sich die Anzeige im Dialog modifizieren, sodass die Warnhinweise abgeschwächt oder ganz entfernt werden. So können Nutzer gezielt in die Irre geführt werden, indem sie glauben, eine Anwendung sei von Apple überprüft und sicher.
Dieses Vorgehen unterminiert das Vertrauen in die Datenschutzmechanismen und erhöht das Risiko unbewusster Freigabe von kritischen Zugriffsrechten. Die Veröffentlichung der Schwachstelle führte zu einer raschen Reaktion seitens Apple. Bereits in der Beta von iOS 18.5 wurde eine entsprechende Korrektur präsentiert. Dabei übernahm Apple einen bewährten Ansatz anderer Berechtigungsdialoge, bei denen data-sensitive Informationen nicht direkt an die anfragende App geleitet werden.
Stattdessen nutzt das System sogenannte Erweiterungen, welche im Hintergrund laufen und direkt vom jeweiligen Systemdienst die für den Dialog notwendigen Daten beziehen. Im konkreten Fall des Bluetooth LE Prompts übernahm eine speziell entwickelte Erweiterung namens CoreLocationNumberedMapCalloutPromptPlugin die Aufgabe, den Informationsdialog objektiv und ohne Datenleck zu erzeugen. Durch diese Architekturtrennung wird sichergestellt, dass die Anwendung selbst keine sensiblen Informationen zu den gefundenen Geräten vor der expliziten Erlaubnis erhält. Die Geschichte hinter CVE-2025-31212 ist ein Paradebeispiel dafür, wie gut gemeinte Datenschutzmaßnahmen durch technische Details und Implementationsfehler leicht zum Gegenteil führen können. Sie zeigt, dass bei der Entwicklung von Sicherheitssystemen nicht nur die Oberfläche berücksichtigt werden muss, sondern auch die internen Abläufe und Datenflüsse.
Gerade bei einem komplexen Zusammenspiel aus Betriebssystem, Systemdiensten und App-Schnittstellen ist eine ganzheitliche Überprüfung entscheidend, um unbeabsichtigte Schwachstellen zu vermeiden. Für Nutzer bleibt neben der fortwährenden Wachsamkeit gegenüber App-Berechtigungen auch die Erkenntnis wichtig, dass kein System absolut fehlerfrei ist. Regelmäßige Systemupdates und eine kritische Haltung bei der Vergabe von Zugriffsrechten sind essenzielle Werkzeuge für den persönlichen Datenschutz. Entwickler und Sicherheitsexperten sind gleichermaßen aufgefordert, solche Entdeckungen offen zu kommunizieren und schnell mit Herstellern an Lösungen zu arbeiten, um die digitale Privatsphäre aller Beteiligten zu schützen. Zusammenfassend verdeutlicht die Bluetooth-LE-Berechtigungslücke auf iOS, wie schwierig und komplex der Schutz sensibler Daten in modernen Betriebssystemen ist.
Obwohl Apple mit TCC ein robustes Modell aufgebaut hat, können Feinheiten in der Implementierung fatale Folgen haben. Erfreulicherweise reagierte Apple schnell und implementierte eine Verbesserung, die nun respektiert, dass schützenswerte Informationen erst nach ausdrücklicher Nutzerfreigabe preisgegeben werden dürfen. Für die Zukunft bleibt es eine Herausforderung, technische Innovationen und Datenschutz in Einklang zu bringen und dabei stets die Sicherheit von Nutzerdaten im Fokus zu behalten.
