Apple „Wo ist?“ auf Linux: Warum die Hardware-Schranke keine absolute Sicherheitsgrenze war

Ein Linux-Rechner kann Apples Dienst „Wo ist?“ normalerweise nicht wie ein iPhone, iPad oder Mac nutzen. Der Sicherheitsforscher, der unter dem Namen Zerotistic arbeitet, zeigte jedoch, dass diese Beschränkung in einem wichtigen Punkt keine absolute kryptografische Hardwaregrenze ist: Wenn ein Client die erwarteten Anmelde-, Identitäts- und Protokollschritte korrekt nachbildet, akzeptieren Apples Server ihn offenbar als weiteres autorisiertes Gerät.

Das bedeutet allerdings nicht, dass sich damit beliebige Apple-Nutzer orten lassen. Der getestete Client konnte ausschließlich eine Standortfreigabe lesen, die der verwendete Apple Account bereits erhalten durfte. Die Verschlüsselung von „Wo ist?“ wurde nicht gebrochen und keine Einwilligung umgangen.

Vom Apple-Login zum Linux-Gerät

Zerotistics Projekt verband mehrere normalerweise verborgene Teile des Apple-Ökosystems:

1. Anmeldung über GrandSlam: Zunächst nutzte der Client Apples GrandSlam-Anmeldeprotokoll. Nach einem Secure-Remote-Password-Austausch (SRP) und einer Zwei-Faktor-Authentifizierung lieferte der Ablauf unter anderem Account-Kennungen sowie ein kurzlebiges, passwortähnliches Token.

2. Geräte-Registrierung: Anschließend erzeugte der Linux-Client eine PKCS#10-Zertifikatsanforderung mit einem 2048-Bit-RSA-Schlüssel und einer SHA-1-Signatur. Diese wurde an Apples ältere Profil-Registrierungsschnittstelle authenticateDS gesendet. Als Antwort stellte Apple ein Zertifikat für Apple Identity Services (IDS) aus.

3. Anbindung an IDS: Mit diesem Zertifikat und den zugehörigen Gerätdaten konnte sich Linux als IDS-fähiges Gerät registrieren, die unterstützten Verschlüsselungsverfahren angeben, die benötigten Nachrichtendienste abonnieren und Zugangsdaten für Apples Push-Dienst APNs erhalten.

4. Nachbildung des „Wo ist?“-Ablaufs: Der Client reproduzierte die Abfolge, die ein nativer „Wo ist?“-Client normalerweise ausführt. Dazu gehörten Initialisierung, Aktualisierungen und schließlich eine SubscribeAndFetch-Anfrage mit

   intent: distributeKeys

   und

   mode: proactive

   . Daraufhin veranlasste Apple das Gerät des zustimmenden Kontakts, das aktuelle Schlüsselmaterial für die Standortdaten über IDS und APNs an die neu registrierte Identität zu senden.

5. Entschlüsselung auf dem Rechner: Die verschlüsselte IDS-Nachricht enthielt Beziehungs- und SearchParty-Schlüsselmaterial. Die Open-Source-Bibliothek pypush übernahm die Push- und IDS-Kommunikation; FindMy.py fragte die resultierenden „Wo ist?“-Daten ab und entschlüsselte sie lokal in Koordinaten, Zeitstempel und Genauigkeitsangaben.

Wichtig ist die Einordnung: Dabei wurde kein Apple-Zertifikat gefälscht. Die erforderlichen Zugangsdaten wurden erst nach erfolgreicher Kontoanmeldung und Geräte-Registrierung von Apples Infrastruktur ausgestellt.

Was das über Apples Vertrauensmodell zeigt

Apples Entscheidung, „Wo ist?“-Funktionen auf eigene Geräte zu beschränken, erwies sich in diesem Ablauf eher als Produkt- und Implementierungsgrenze denn als zwingende kryptografische Voraussetzung. Sobald der Linux-Client die erwarteten Kontodaten, Geräteidentität, Zertifikate, Fähigkeiten und Netzwerkabläufe präsentierte, behandelten die Server ihn wie einen weiteren vertrauenswürdigen Empfänger.

Das ist ein klassisches Beispiel dafür, dass Hardware-Exklusivität nicht automatisch die eigentliche Sicherheitsgrenze bildet. Entscheidend war hier nicht allein, ob ein Gerät von Apple stammt, sondern ob es eine gültige Identität besitzt und sich gegenüber den Servern wie ein berechtigter Client verhält.

Der Befund ist dennoch begrenzt: Ein beliebiger Linux-Rechner konnte nicht anonym eine Anfrage an „Wo ist?“ stellen. Er musste zunächst mit einem Apple Account authentifiziert und als Gerät registriert werden. Außerdem erhielt er nur die Schlüssel und Daten, zu denen dieser Account bereits berechtigt war.

Einblick in Schlüsselverteilung und Synchronisierung

Die demonstrierte SubscribeAndFetch-Funktion deutet darauf hin, dass Apple aktuelles Schlüsselmaterial nachträglich an ein neu autorisiertes Gerät übertragen kann. Das ist für die alltägliche Kontosynchronisierung sinnvoll: Wer ein neues Gerät hinzufügt, sollte nicht jede Person bitten müssen, die Standortfreigabe zu beenden und erneut zu starten.

Die übermittelte Nutzlast enthielt laut der technischen Beschreibung unter anderem:

• eine Kennung für die bestehende Beziehung,
• einen Schlüsselindex,
• einen 32 Byte langen Hash-Schlüssel für die Anzeige- beziehungsweise Werbedaten und
• eine 85 Byte lange Darstellung des privaten Schlüssels.

Diese Felder sprechen dafür, dass die Entschlüsselung von Standortmeldungen auf beziehungs- und versionsabhängigem Schlüsselmaterial basiert. Zugleich zeigt der Versuch, dass der aktuelle Schlüsselstand über IDS an ein neu autorisiertes Gerät weitergegeben werden kann. Die veröffentlichte Analyse beschreibt Synchronisierungs- und Rotationsverhalten, legt aber kein allgemeingültiges Intervall für den Schlüsselwechsel offen.

Was der Client konnte – und was nicht

Der getestete Linux-Client war bewusst eng begrenzt. Er konnte eine bereits akzeptierte Standortfreigabe auf dem Apple Account lesen und die Daten anschließend lokal verarbeiten. Auch die Geofencing-Logik lief auf dem Linux-Rechner, nicht als Apple-seitige Funktion.

Nicht vorgesehen waren laut der Veröffentlichung:

• neue Einladungen zur Standortfreigabe zu verschicken,
• bestehende Freigaberechte zu ändern,
• Familienmitglieder hinzuzufügen,
• auf Apple-Servern verwaltete Geozäune anzulegen oder
• Gerätebefehle auszuführen.

Damit handelt es sich eher um einen Interoperabilitäts- und Vertrauensgrenzen-Befund als um einen Angriff, mit dem sich beliebige Personen aus der Ferne verfolgen lassen. Das realistischere Risiko läge bei der Übernahme eines Apple Accounts oder eines bereits vertrauenswürdigen Geräts: In diesem Fall könnten Standortfreigaben sichtbar werden, auf die der Account ohnehin Zugriff hatte.

Der Unterschied zum Angriff nRootTag

Die Arbeit von Zerotistic wird teilweise mit der 2025 vorgestellten nRootTag-Forschung vermischt. Beide Untersuchungen betreffen jedoch unterschiedliche Bereiche von „Wo ist?“ und haben deutlich verschiedene Bedrohungsmodelle.

Zerotistic untersuchte „Wo ist?“-Personenfreigaben. Der Linux-Client empfing Daten aus einer bereits bestehenden und genehmigten Freigabebeziehung. Sowohl der Account als auch das Gerät mussten von Apple akzeptiert werden; außerdem musste die betreffende Person ihren Standort mit diesem Account teilen.

nRootTag zielte auf das „Wo ist?“-Netzwerk und die Offline-Ortung. Die Forschenden berichteten, dass Apples Dienst auch Bluetooth-Adressarten akzeptierte, die dort nicht erwartet wurden. Dadurch konnte ein Bluetooth-fähiger Computer unter bestimmten Bedingungen wie ein AirTag-ähnlicher Tracker auftreten und über Geräte in der Umgebung Standortmeldungen an Apples Netzwerk weiterleiten – ohne Wissen des Besitzers des verfolgten Geräts.

Kurz gesagt: Zerotistic empfing Daten, die ein Account bereits sehen durfte. nRootTag sollte dagegen ein unbefugtes Tracking-Werkzeug schaffen. Die beiden Ergebnisse gleichzusetzen, würde die Linux-Demonstration deutlich gefährlicher erscheinen lassen, als es die vorliegenden Belege rechtfertigen.

Das ursprüngliche Ziel und die Dauer des Projekts

Der Ausgangspunkt war laut Zerotistic eine einvernehmliche Automatisierung. Ein Freund, der seinen Standort bereits teilte, stimmte einem Linux-System zu, das lokale Geozäune verwalten und über Discord melden sollte, wenn die Person bestimmte Orte betrat oder verließ.

Ursprünglich rechnete der Forscher offenbar mit einer authentifizierten Web-Anfrage und ungefähr einem Abend Arbeit. Die notwendige Protokollanalyse wurde jedoch deutlich umfangreicher. Die verfügbaren Quellen nennen keine verlässlich belegte Gesamtdauer für das fertige Projekt; eine präzisere Zeitangabe wäre daher spekulativ.

Wie Apple reagiert hat

Die zitierten Berichte bestätigen die Demonstration, enthalten aber keine verifizierte öffentliche Stellungnahme von Apple zu genau dieser Linux-Implementierung. Ebenso ist in den vorliegenden Quellen weder ein bestätigter konkreter Fix noch ein öffentlich dokumentiertes Bug-Bounty-Ergebnis belegt.

Die zentrale Lehre bleibt damit bestehen: Eine Funktion auf Apple-Hardware zu beschränken, macht die Hardware nicht automatisch zur Sicherheitsgrenze. Wenn ein Dienst Vertrauen vor allem anhand von Zugangsdaten, Zertifikaten, Fähigkeiten und korrekt nachgebildetem Protokollverhalten vergibt, kann ein ausreichend kompatibler Client auf einem anderen Betriebssystem diese Produktgrenze überschreiten – bleibt dabei aber an die Berechtigungen und kryptografischen Schlüssel gebunden, die er legitim erhält.