整個項目將 Apple 生態系統入面幾個平時睇唔到嘅部分串埋一齊:
登入 Apple Account: Zerotistic 使用 Apple 嘅 GrandSlam 登入協議。據報流程包括 Secure Remote Password(SRP)交換同雙重認證,最後取得帳戶識別資料,以及一個短時間有效、相當於密碼嘅 token。
註冊裝置身份: 客戶端產生 PKCS#10 格式嘅證書簽署請求(CSR),內含 2,048-bit RSA 金鑰,並以 SHA-1 簽署。之後,請求會送到 Apple 舊有嘅 authenticateDS profile-enrollment 端點,由對方回傳 Apple Identity Services(IDS)證書。
註冊 IDS: 有咗證書同相關裝置資料之後,Linux 就可以註冊成支援 IDS 嘅裝置,聲明支援嘅加密類型、訂閱所需嘅訊息子服務,並取得 Apple Push Notification Service(APNs)推送憑證。
同步 Find My 資料: 客戶端重現原生 Find My People 嘅請求次序,包括初始化、重新整理,以及一個帶有 intent: distributeKeysmode: proactiveSubscribeAndFetch 請求。之後,Apple 會指示已同意分享位置嘅聯絡人裝置,經 IDS 同 APNs 將目前嘅位置金鑰資料傳送畀新註冊嘅身份。
喺本機解密: 加密嘅 IDS 封包包括關係資料同 SearchParty 金鑰材料。開源套件 pypush 負責推送及 IDS 層,而 FindMy.py 就查詢及解密 Find My 報告,還原出位置座標、時間戳同準確度資料。
示範中嘅 SubscribeAndFetch 行為,似乎顯示 Apple 可以喺一段位置分享關係已經存在之後,將目前嘅位置金鑰資料傳送畀一部新獲授權嘅裝置。對裝置更換同帳戶同步嚟講,呢個安排相當合理:用戶新增一部裝置時,唔應該要逐個聯絡人先停止、再重新開啟位置分享。
據報相關封包包括:
測試中嘅客戶端功能相當有限:佢可以讀取研究員 Apple Account 已經獲准接收嘅位置分享,然後喺本機處理資料。電子圍欄(geofencing)亦係喺本機運算,而唔係由 Apple 伺服器提供。
根據研究員公開嘅說明,客戶端冇有以下功能:
所以,今次結果應該理解為互通性及信任邊界發現,而唔係可以遠端任意追蹤陌生人嘅漏洞。較實際嘅保安風險係 Apple Account 或可信裝置被人控制:如果攻擊者取得帳戶,或者喺帳戶入面註冊咗未經授權嘅裝置,該帳戶原本可以接收嘅位置分享就可能暴露。
Zerotistic 同 nRootTag 處理嘅係 Find My 入面完全唔同嘅部分,威脅模式亦唔一樣。
nRootTag 就針對 Find My Network 同離線尋找功能。 研究員報告指,Apple 服務接受咗預期以外嘅 Bluetooth 位址類型。呢個弱點可能令攻擊者將一部支援 Bluetooth 嘅電腦變成類似 AirTag 嘅追蹤信標,再利用附近 Apple 裝置轉送位置,而目標裝置擁有人未必知情。
簡單講,Zerotistic 嘅項目係接收帳戶已經有權睇到嘅資料;nRootTag 就係嘗試建立未經授權嘅追蹤能力。將兩者混為一談,會令 Linux 示範聽落比證據實際支持嘅程度更加嚴重。
Zerotistic 表示,最初動機係做一個有對方同意嘅自動化工具:一位朋友本身已經同意分享位置,於是研究員想用 Linux 維持本機電子圍欄,當對方抵達或離開指定地點時,經 Discord 發出通知。
現有引用報道確認咗呢次示範,但未有提供一份經核實、專門回應呢個 Linux Find My People 實作嘅 Apple 公開聲明;同樣未有確認 Apple 已修正問題,或者已經作出漏洞獎賞安排。
今次研究嘅核心啟示仍然清楚:將功能限制喺 Apple 硬件上,唔代表硬件本身就一定係安全邊界。如果伺服器主要根據帳戶憑證、證書、功能能力同協議行為授予信任,一個足夠兼容嘅非 Apple 客戶端,仍然可能跨過產品限制——但佢能夠睇到嘅資料,始終受帳戶權限同合法取得嘅加密金鑰所限制。