Slik fikk Zerotistic Apples Finn personer til å fungere på Linux – uten å knekke krypteringen

Det betyr likevel ikke at hvem som helst kunne spørre Find My fra en anonym Linux-PC. Maskinen måtte gjennom Apples autentiserings- og registreringsflyt og få en enhetsidentitet som kontoen var autorisert til å bruke. Forskningen viser dermed at et ikke-Apple-operativsystem kunne etterligne den relevante klientoppførselen – ikke at sikkerheten i tjenesten ble fjernet.

Slik gjenskapte Linux-klienten Find My-flyten

Prosjektet koblet sammen flere deler av Apples normalt skjulte infrastruktur:

1. Innlogging på kontoen: Zerotistic brukte Apples GrandSlam-protokoll. Flyten omfattet en Secure Remote Password-utveksling og tofaktorautentisering, som ga kontoidentifikatorer og et kortvarig token som fungerte som en passordekvivalent.

2. Registrering av enheten: Klienten opprettet en PKCS#10-forespørsel om sertifikatsignering med en 2048-bits RSA-nøkkel og en SHA-1-signatur. Forespørselen ble sendt til Apples eldre authenticateDS-endepunkt for profilregistrering, som returnerte et sertifikat fra Apple Identity Services.

3. Registrering i IDS: Med sertifikatet og tilhørende enhetsinformasjon kunne Linux registreres som en enhet med støtte for Identity Services (IDS), oppgi hvilke krypteringstyper den støttet, abonnere på de nødvendige meldingstjenestene og hente leveringsinformasjon for Apple Push Notification Service (APNs).

4. Synkronisering med Find My: Klienten gjenskapte den opprinnelige forespørselssekvensen for Finn personer, blant annet initialisering, oppdateringer og en SubscribeAndFetch-forespørsel med

   intent: distributeKeys

   og

   mode: proactive

   . Apple ba deretter den samtykkende kontaktens enhet sende det gjeldende posisjonsnøkkelmaterialet til den nyregistrerte identiteten via IDS og APNs.

5. Dekryptering lokalt: Den krypterte IDS-meldingen inneholdt informasjon om relasjonen og nøkler fra SearchParty-systemet. Åpen kildekode-biblioteket pypush håndterte push- og IDS-laget, mens FindMy.py hentet og dekrypterte Find My-rapportene til koordinater, tidspunkt og opplysninger om nøyaktighet.

Dette var protokoll-etterligning, ikke et forfalsket Apple-sertifikat. Serveren utstedte fortsatt legitimasjonen først etter at kontoautentiseringen og registreringen var fullført.

Hva IDS-meldingen sier om nøkkeldistribusjon

Den demonstrerte SubscribeAndFetch-oppførselen tyder på at Apple kan sende gjeldende posisjonsnøkler til en ny enhet som er autorisert etter at en delingsrelasjon allerede er opprettet. Det er nødvendig for at en bruker skal kunne bytte eller legge til en enhet uten å måtte be alle kontakter stoppe og starte posisjonsdelingen på nytt.

Den rapporterte meldingen inneholdt blant annet en relasjons-ID, en nøkkelindeks, en 32-byte hash av annonseringsnøkkelen og en 85-byte representasjon av en privat nøkkel. Feltene tyder på at dekryptering av Find My-posisjoner bygger på materiale som er knyttet både til den konkrete relasjonen og til den aktuelle nøkkelversjonen, og at materialet kan distribueres på nytt gjennom IDS.

Den offentlige gjennomgangen viser synkronisering og rotasjon av nøkler, men fastslår ikke et universelt intervall for hvor ofte nøklene roteres. Det er en viktig begrensning: Forskningen viser hvordan den gjeldende nøkkeltilstanden leveres, ikke en komplett offentlig spesifikasjon av Apples nøkkelhåndtering.

Hva klienten kunne – og ikke kunne – gjøre

Klienten var bevisst begrenset. Den kunne lese en posisjonsdeling som allerede var godkjent for forskerens Apple-konto, og behandle dataene lokalt. Geogjerdene ble også håndtert lokalt, ikke av en Apple-funksjon på serversiden.

Ifølge gjennomgangen hadde den ingen funksjoner for å:

• sende nye invitasjoner til posisjonsdeling;
• endre eksisterende delingstillatelser;
• legge til familiemedlemmer;
• opprette geogjerder hos Apple; eller
• sende kommandoer til enheter.

Resultatet bør derfor forstås som et funn om samhandling og tillitsgrenser, ikke som et fjernangrep for å spore tilfeldige personer. Den mer realistiske sikkerhetsbekymringen er kompromitterte kontoer eller betrodde enheter: Hvis en angriper fikk kontroll over en Apple-konto eller registrerte en uautorisert enhet på den, kunne posisjonsdelinger som kontoen allerede hadde tilgang til, potensielt bli eksponert.

Forskjellen fra nRootTag-forskningen i 2025

Zerotistics demonstrasjon og nRootTag undersøkte ulike deler av Find My og representerer forskjellige trusselmodeller.

Zerotistic undersøkte Finn personer. Arbeidet gjenskapte mottakersiden i en eksisterende og autorisert delingsrelasjon. Kontoen og enheten måtte godkjennes av Apple, og personen måtte allerede ha delt posisjonen sin med kontoen.

nRootTag rettet seg mot Find My Network og frakoblet sporing. Forskerne rapporterte at Apples tjeneste godtok flere Bluetooth-adressetyper enn forventet. Det kunne gjøre det mulig for en angriper å få en Bluetooth-kompatibel datamaskin til å opptre som en AirTag-lignende sporingsbrikke, slik at Apple-enheter i nærheten videreformidlet posisjonen uten at eieren av den sporede enheten visste om det.

Kort sagt: Zerotistics prosjekt mottok data som en konto allerede var autorisert til å se. nRootTag forsøkte å skape en uautorisert sporingsmekanisme. Å blande de to funnene sammen får Linux-demonstrasjonen til å fremstå langt kraftigere enn dokumentasjonen tilsier.

Målet var Discord-varsler og lokale geogjerder

Det opprinnelige målet var samtykkebasert automatisering. En venn som allerede delte posisjonen sin, hadde sagt ja til at et Linux-system skulle følge med på lokale geogjerder og sende varsler i Discord når personen kom til eller forlot bestemte steder.

Zerotistic forventet først at oppgaven skulle begrense seg til en autentisert nettforespørsel, og anslo at den kunne ta omtrent en kveld. Reverse engineering-arbeidet ble imidlertid betydelig mer omfattende enn først antatt. Det tilgjengelige materialet fastslår ikke en nøyaktig total tidsbruk for det ferdige prosjektet, så et mer presist anslag ville vært spekulativt.

Apples svar

De tilgjengelige, kildebelagte omtaler viser at demonstrasjonen fant sted, men inneholder ingen bekreftet offentlig uttalelse fra Apple om akkurat denne Linux-implementeringen av Finn personer. De dokumenterer heller ingen bekreftet løsning eller kjent resultat fra Apples bug bounty-program.

Hovedlærdommen står likevel fast: At en funksjon er begrenset til Apple-maskinvare, betyr ikke automatisk at maskinvaren i seg selv er sikkerhetsgrensen. Hvis tilliten på serversiden i hovedsak avgjøres av legitimasjon, sertifikater, deklarerte funksjoner og riktig protokolloppførsel, kan en tilstrekkelig kompatibel klient på et annet operativsystem krysse produktgrensen – samtidig som den fortsatt er bundet av kontotillatelsene og de kryptografiske nøklene den faktisk får tilgang til.