Это не означает, что любой Linux-компьютер может просто подключиться к Find My. Исследование показало другое: сторонняя операционная система способна воспроизвести поведение штатного клиента, если пройти процедуры авторизации и регистрации устройства в экосистеме Apple.
Проект объединил несколько обычно скрытых компонентов инфраструктуры Apple.
Авторизация аккаунта. Zerotistic использовал протокол входа Apple GrandSlam. Описанный процесс включал обмен по протоколу Secure Remote Password (SRP) и двухфакторную аутентификацию. На выходе клиент получал идентификаторы аккаунта и краткоживущий токен, эквивалентный паролю.
Регистрация устройства. Клиент сформировал запрос на подпись сертификата PKCS#10 с 2048-битным RSA-ключом и подписью SHA-1. Этот запрос был отправлен на устаревшую точку регистрации профиля Apple authenticateDS, которая вернула сертификат Apple Identity Services.
Подключение к IDS. Имея сертификат и связанные с ним данные устройства, Linux-клиент смог зарегистрироваться как устройство, поддерживающее Identity Services (IDS), объявить поддерживаемые типы шифрования, подписаться на необходимые подсервисы обмена сообщениями и получить реквизиты доставки через Apple Push Notification Service (APNs).
Синхронизация Find My. Клиент воспроизвёл последовательность запросов штатного Find My People: инициализацию, обновление данных и запрос SubscribeAndFetch с параметрами intent: distributeKeysmode: proactive
Локальная расшифровка. Зашифрованное сообщение IDS содержало данные об отношении между аккаунтами и ключевой материал SearchParty. Библиотека с открытым исходным кодом pypush обрабатывала push-уведомления и слой IDS, а FindMy.py запрашивала и расшифровывала отчёты Find My, превращая их в координаты, временные метки и сведения о точности.
Речь шла именно об эмуляции протокола, а не о подделке сертификата Apple. Учётные данные всё равно выдавались сервером только после прохождения аутентификации аккаунта и процедуры регистрации.
Поведение SubscribeAndFetch указывает, что Apple может передать актуальный ключ геолокации новому авторизованному устройству, если отношения обмена местоположением уже существуют. Это логично с точки зрения синхронизации: при добавлении нового устройства пользователю не пришлось бы просить каждого контакта заново отключать и включать общий доступ к геопозиции.
В продемонстрированном сообщении присутствовали идентификатор отношения, индекс ключа, 32-байтовый хешированный ключ рекламных сообщений и 85-байтовое представление закрытого ключа. Эти поля указывают, что расшифровка отчётов Find My зависит от материала, привязанного одновременно к конкретным отношениям и версии ключа, а обновлённые ключи могут повторно распространяться через IDS.
При этом публичное описание демонстрирует процессы синхронизации и ротации ключей, но не устанавливает универсальный интервал их смены. Иными словами, исследование показывает, как доставляется актуальное состояние ключей, но не раскрывает полную публичную спецификацию графика управления ими.
Прототип был намеренно узким. Он мог прочитать уже разрешённую геопозицию в учётной записи Apple исследователя и обработать эти данные локально. Геозоны также создавались и проверялись локально, а не на стороне Apple.
Согласно опубликованному описанию, клиент не поддерживал:
Поэтому результат правильнее считать исследованием совместимости и границ доверия, а не удалённым эксплойтом для слежки за любым человеком. Более реалистичный риск связан с компрометацией аккаунта или доверенного устройства: если злоумышленник получит контроль над Apple Account или зарегистрирует в нём несанкционированное устройство, он потенциально сможет раскрыть геопозиции, уже доступные этому аккаунту.
Работы Zerotistic и nRootTag затрагивают разные компоненты Find My и описывают разные модели угроз.
Zerotistic исследовал Find My People. Его клиент воспроизводил сторону получателя в уже существующих и разрешённых отношениях обмена. Аккаунт и устройство должны были быть приняты Apple, а человек — заранее поделиться своим местоположением с этим аккаунтом.
nRootTag был направлен на Find My Network и офлайн-поиск. Исследователи сообщили, что сервис Apple принимал не только ожидаемые случайные статические Bluetooth-адреса. Это позволяло заставить компьютер с Bluetooth работать как маяк, похожий на AirTag, а находящиеся рядом устройства Apple — передавать его местоположение без ведома владельца целевого устройства.
Коротко говоря, проект Zerotistic получал данные, которые аккаунт уже имел право видеть, тогда как nRootTag стремился создать примитив для несанкционированного отслеживания. Смешивать эти два результата нельзя: такое сравнение делает Linux-демонстрацию значительно опаснее и мощнее, чем позволяют факты.
Изначальная цель была связана с автоматизацией на основе согласия. Друг исследователя уже делился с ним геопозицией и согласился на запуск Linux-системы, которая создавала бы локальные геозоны и отправляла уведомления в Discord, когда человек входил в определённое место или покидал его.
Сначала Zerotistic рассчитывал, что задача сведётся к одному аутентифицированному веб-запросу и займёт примерно вечер. Однако обратная разработка протоколов оказалась существенно масштабнее. Доступные публикации не подтверждают точную общую продолжительность завершённого проекта, поэтому более конкретная оценка была бы предположением.
В доступных источниках подтверждается сама демонстрация, но нет проверенного публичного заявления Apple именно по этой реализации Find My People для Linux, подтверждённого исправления или раскрытого результата программы bug bounty.
Главный вывод остаётся прежним: ограничение функции устройствами определённого производителя само по себе ещё не делает аппаратное обеспечение границей безопасности. Если серверное доверие в основном строится на учётных данных, сертификатах, заявленных возможностях и корректном поведении протокола, достаточно совместимый клиент для другой операционной системы может пересечь продуктовую границу — при этом оставаясь ограниченным разрешениями аккаунта и криптографическими ключами, которые он получает легитимным образом.