كيف أعاد الباحث بناء المسار التقني؟

ربط المشروع بين عدة أجزاء عادةً ما تخفيها منظومة Apple:

1. تسجيل الدخول إلى الحساب: استخدم Zerotistic بروتوكول تسجيل الدخول الخاص بـ Apple المعروف باسم GrandSlam. وتضمن المسار تبادلًا عبر بروتوكول SRP، ثم المصادقة الثنائية، قبل الحصول على معرّفات للحساب ورمز قصير الأجل يعادل كلمة مرور مؤقتة.

2. تسجيل الجهاز: أنشأ العميل طلب توقيع شهادة بصيغة PKCS#10، مستخدمًا مفتاح RSA بطول 2048 بت وتوقيعًا بخوارزمية SHA-1. ثم أرسل الطلب إلى نقطة التسجيل القديمة authenticateDS، التي أعادت شهادة لخدمات Apple Identity Services.

3. التسجيل في IDS: باستخدام الشهادة ومواد هوية الجهاز المرتبطة بها، تمكن لينكس من التسجيل كجهاز يدعم Identity Services، والإعلان عن أنواع التشفير التي يدعمها، والاشتراك في خدمات المراسلة المطلوبة، والحصول على بيانات اعتماد لتسليم الإشعارات عبر Apple Push Notification Service (APNs).

4. مزامنة Find My: أعاد العميل تنفيذ تسلسل الطلبات المستخدم في Find My People، بما في ذلك التهيئة والتحديثات، ثم طلب SubscribeAndFetch مع intent: distributeKeys وmode: proactive. بعد ذلك، طلبت Apple من جهاز الشخص الذي وافق على مشاركة موقعه إرسال مواد مفاتيح الموقع الحالية إلى الهوية المسجلة حديثًا عبر IDS وAPNs.

5. فك التشفير محليًا: احتوت حزمة IDS المشفرة على معرّف العلاقة ومواد مفاتيح SearchParty. تولت مكتبة pypush مفتوحة المصدر طبقة الدفع وIDS، بينما استخدمت مكتبة FindMy.py للاستعلام عن تقارير Find My وفك تشفيرها إلى إحداثيات ومواعيد وبيانات دقة الموقع.

وهذا محاكاة للبروتوكول، وليس تزويرًا لشهادة Apple. فقد أصدرت الخوادم بيانات الاعتماد بعد اكتمال خطوات مصادقة الحساب وتسجيل الجهاز.

ماذا تكشف التجربة عن حدود الثقة لدى Apple؟

تشير النتيجة إلى أن حصرية الأجهزة كانت في هذا المسار حدًا تنفيذيًا وسياسة منتج، وليست بالضرورة شرطًا تشفيريًا مطلقًا لا يمكن تحقيقه إلا بعتاد من صنع Apple. فعندما قدم عميل لينكس بيانات الحساب، وهوية الجهاز، والشهادات، والقدرات، والسلوك الشبكي المتوقع، تعاملت الخوادم معه كمستقبل موثوق آخر.

لكن ذلك لا يعني أن أي شخص يستطيع تشغيل لينكس مجهول والاتصال بـ Find My. ما أثبته البحث هو أن نظام تشغيل غير تابع لـ Apple يستطيع تقليد سلوك العميل المناسب بعد اجتياز خطوات المصادقة والتسجيل لدى Apple.

بعبارة أخرى، تكمن حدود الثقة هنا في بيانات اعتماد الحساب، وهوية الجهاز، والشهادات، والقدرات المعلنة، وتسلسل البروتوكول، لا في وجود شريحة Apple وحدها. وهذه نتيجة مهمة في تصميم الأنظمة: حظر ميزة على أجهزة بعينها لا يجعل تلك الأجهزة تلقائيًا هي الحاجز الأمني الحقيقي.

ماذا تكشف حزمة IDS عن توزيع مفاتيح الموقع؟

يوحي سلوك SubscribeAndFetch الذي جرى عرضه بأن Apple تستطيع إرسال مواد مفاتيح الموقع الحالية إلى جهاز جديد حصل على التفويض، بعد أن تكون علاقة المشاركة قائمة أصلًا. وهذا منطقي من ناحية الاستخدام: عند إضافة جهاز جديد إلى الحساب، لا ينبغي للمستخدم أن يطلب من كل جهة تشاركه موقعها إيقاف المشاركة ثم تشغيلها من جديد.

وتضمنت الحزمة التي جرى رصدها معرّف العلاقة، وفهرسًا للمفتاح، ومفتاحًا مجزأً للإعلان بطول 32 بايت، وتمثيلًا لمفتاح خاص بطول 85 بايت. وتشير هذه العناصر إلى أن فك تقارير الموقع يعتمد على مواد مرتبطة بكل علاقة وبإصدار المفتاح، ويمكن إعادة توزيع حالة المفاتيح الحالية عبر IDS.

مع ذلك، لا تثبت الكتابة التقنية العامة وجود فترة زمنية موحدة لتدوير المفاتيح. فهي توضح آلية تسليم حالة المفتاح الحالية وسلوك المزامنة والتدوير، لكنها لا تقدم مواصفة عامة كاملة للجدول الزمني الذي تتبعه Apple في إدارة المفاتيح.

ما الذي كان عميل لينكس قادرًا عليه؟

كان العميل محدودًا عمدًا. فقد استطاع قراءة مشاركة موقع مقبولة مسبقًا على حساب الباحث، ثم معالجة البيانات محليًا. كما نُفذت منطقية تحديد النطاق الجغرافي محليًا بعد فك التشفير، وليس عبر ميزة مستضافة على خوادم Apple.

وبحسب العرض التقني، لم يتضمن العميل وظائف من أجل:

• إرسال دعوات جديدة لمشاركة الموقع؛
• تعديل أذونات المشاركة القائمة؛
• إضافة أفراد العائلة؛
• إنشاء نطاقات جغرافية مستضافة على Apple؛ أو
• إصدار أوامر للأجهزة.

لذلك، فالنتيجة أقرب إلى اكتشاف يتعلق بالتوافق وحدود الثقة منها إلى ثغرة تتيح تتبع أي شخص عن بُعد. أما مصدر القلق الأكثر واقعية فيتعلق باختراق حساب Apple أو جهاز موثوق مرتبط به؛ إذ قد يؤدي ذلك إلى كشف المشاركات المتاحة أصلًا لذلك الحساب.

ما الفرق بين هذه التجربة وهجوم nRootTag؟

يتعلق عمل Zerotistic وnRootTag بجزأين مختلفين من منظومة Find My، كما يقدمان نموذجَي تهديد مختلفين تمامًا.

تجربة Zerotistic ركزت على Find My People: أعادت بناء جانب المستقبل ضمن علاقة مشاركة موجودة ومصرح بها. كان لا بد من قبول الحساب والجهاز لدى Apple، كما كان يجب أن يكون موقع الشخص قد شُورك مع ذلك الحساب.

أما nRootTag فاستهدف Find My Network والعثور على الأجهزة غير المتصلة: أفاد الباحثون بأن خدمة Apple قبلت أنواعًا من عناوين البلوتوث تتجاوز النوع العشوائي الثابت المتوقع. وقد يتيح ذلك للمهاجم جعل حاسوب يدعم البلوتوث يتصرف كمنارة شبيهة بـ AirTag، مستفيدًا من أجهزة Apple القريبة لترحيل موقعه من دون علم مالك الجهاز المستهدف.

باختصار، تلقت تجربة Zerotistic بيانات كان الحساب مخولًا أصلًا برؤيتها، بينما سعى nRootTag إلى إنشاء قدرة تتبع غير مصرح بها. وخلط التجربتين يجعل عرض لينكس يبدو أقوى بكثير مما تثبته الأدلة.

الهدف الأصلي ومدة العمل

كان الدافع المعلن للتجربة أتمتة قائمة على موافقة واضحة. فقد وافق صديق كان يشارك موقعه أصلًا على تشغيل نظام لينكس ينشئ نطاقات جغرافية محلية ويرسل إشعارات عبر Discord عند وصوله إلى أماكن محددة أو مغادرتها.

توقع Zerotistic في البداية أن تقتصر المهمة على طلب ويب يتطلب مصادقة، وقدّر أنها ستستغرق «أمسية من العمل». لكن الهندسة العكسية توسعت كثيرًا مقارنة بهذا التقدير الأولي. ولا تثبت المواد المتاحة مدة إجمالية دقيقة لإنجاز المشروع، لذلك فإن تحديد إطار زمني أكثر دقة سيكون تخمينًا غير مدعوم.

ماذا قالت Apple؟

تؤكد التغطية المتاحة تنفيذ العرض، لكنها لا تقدم بيانًا عامًا موثقًا من Apple يتناول تحديدًا تطبيق Find My People على لينكس، ولا تؤكد إصلاحًا بعينه أو نتيجة معلنة لبرنامج مكافآت الأخطاء.

وتبقى الرسالة الأساسية واضحة: حصر ميزة في أجهزة Apple لا يعني تلقائيًا أن العتاد هو الحد الأمني الفعلي. فإذا منحت الخوادم الثقة اعتمادًا أساسًا على بيانات الاعتماد والشهادات والقدرات وسلوك البروتوكول، فقد يتمكن عميل متوافق بدرجة كافية، حتى لو كان يعمل على نظام تشغيل آخر، من عبور الحد الذي تفرضه سياسة المنتج—مع بقائه مقيدًا بأذونات الحساب والمفاتيح التشفيرية التي يحصل عليها بصورة مشروعة.

كيف أعاد الباحث بناء المسار التقني؟

ربط المشروع بين عدة أجزاء عادةً ما تخفيها منظومة Apple:

1. تسجيل الدخول إلى الحساب: استخدم Zerotistic بروتوكول تسجيل الدخول الخاص بـ Apple المعروف باسم GrandSlam. وتضمن المسار تبادلًا عبر بروتوكول SRP، ثم المصادقة الثنائية، قبل الحصول على معرّفات للحساب ورمز قصير الأجل يعادل كلمة مرور مؤقتة.

2. تسجيل الجهاز: أنشأ العميل طلب توقيع شهادة بصيغة PKCS#10، مستخدمًا مفتاح RSA بطول 2048 بت وتوقيعًا بخوارزمية SHA-1. ثم أرسل الطلب إلى نقطة التسجيل القديمة authenticateDS، التي أعادت شهادة لخدمات Apple Identity Services.

3. التسجيل في IDS: باستخدام الشهادة ومواد هوية الجهاز المرتبطة بها، تمكن لينكس من التسجيل كجهاز يدعم Identity Services، والإعلان عن أنواع التشفير التي يدعمها، والاشتراك في خدمات المراسلة المطلوبة، والحصول على بيانات اعتماد لتسليم الإشعارات عبر Apple Push Notification Service (APNs).

4. مزامنة Find My: أعاد العميل تنفيذ تسلسل الطلبات المستخدم في Find My People، بما في ذلك التهيئة والتحديثات، ثم طلب SubscribeAndFetch مع intent: distributeKeys وmode: proactive. بعد ذلك، طلبت Apple من جهاز الشخص الذي وافق على مشاركة موقعه إرسال مواد مفاتيح الموقع الحالية إلى الهوية المسجلة حديثًا عبر IDS وAPNs.

5. فك التشفير محليًا: احتوت حزمة IDS المشفرة على معرّف العلاقة ومواد مفاتيح SearchParty. تولت مكتبة pypush مفتوحة المصدر طبقة الدفع وIDS، بينما استخدمت مكتبة FindMy.py للاستعلام عن تقارير Find My وفك تشفيرها إلى إحداثيات ومواعيد وبيانات دقة الموقع.

وهذا محاكاة للبروتوكول، وليس تزويرًا لشهادة Apple. فقد أصدرت الخوادم بيانات الاعتماد بعد اكتمال خطوات مصادقة الحساب وتسجيل الجهاز.

ماذا تكشف التجربة عن حدود الثقة لدى Apple؟

تشير النتيجة إلى أن حصرية الأجهزة كانت في هذا المسار حدًا تنفيذيًا وسياسة منتج، وليست بالضرورة شرطًا تشفيريًا مطلقًا لا يمكن تحقيقه إلا بعتاد من صنع Apple. فعندما قدم عميل لينكس بيانات الحساب، وهوية الجهاز، والشهادات، والقدرات، والسلوك الشبكي المتوقع، تعاملت الخوادم معه كمستقبل موثوق آخر.

لكن ذلك لا يعني أن أي شخص يستطيع تشغيل لينكس مجهول والاتصال بـ Find My. ما أثبته البحث هو أن نظام تشغيل غير تابع لـ Apple يستطيع تقليد سلوك العميل المناسب بعد اجتياز خطوات المصادقة والتسجيل لدى Apple.

بعبارة أخرى، تكمن حدود الثقة هنا في بيانات اعتماد الحساب، وهوية الجهاز، والشهادات، والقدرات المعلنة، وتسلسل البروتوكول، لا في وجود شريحة Apple وحدها. وهذه نتيجة مهمة في تصميم الأنظمة: حظر ميزة على أجهزة بعينها لا يجعل تلك الأجهزة تلقائيًا هي الحاجز الأمني الحقيقي.

ماذا تكشف حزمة IDS عن توزيع مفاتيح الموقع؟

يوحي سلوك SubscribeAndFetch الذي جرى عرضه بأن Apple تستطيع إرسال مواد مفاتيح الموقع الحالية إلى جهاز جديد حصل على التفويض، بعد أن تكون علاقة المشاركة قائمة أصلًا. وهذا منطقي من ناحية الاستخدام: عند إضافة جهاز جديد إلى الحساب، لا ينبغي للمستخدم أن يطلب من كل جهة تشاركه موقعها إيقاف المشاركة ثم تشغيلها من جديد.

وتضمنت الحزمة التي جرى رصدها معرّف العلاقة، وفهرسًا للمفتاح، ومفتاحًا مجزأً للإعلان بطول 32 بايت، وتمثيلًا لمفتاح خاص بطول 85 بايت. وتشير هذه العناصر إلى أن فك تقارير الموقع يعتمد على مواد مرتبطة بكل علاقة وبإصدار المفتاح، ويمكن إعادة توزيع حالة المفاتيح الحالية عبر IDS.

مع ذلك، لا تثبت الكتابة التقنية العامة وجود فترة زمنية موحدة لتدوير المفاتيح. فهي توضح آلية تسليم حالة المفتاح الحالية وسلوك المزامنة والتدوير، لكنها لا تقدم مواصفة عامة كاملة للجدول الزمني الذي تتبعه Apple في إدارة المفاتيح.

ما الذي كان عميل لينكس قادرًا عليه؟

كان العميل محدودًا عمدًا. فقد استطاع قراءة مشاركة موقع مقبولة مسبقًا على حساب الباحث، ثم معالجة البيانات محليًا. كما نُفذت منطقية تحديد النطاق الجغرافي محليًا بعد فك التشفير، وليس عبر ميزة مستضافة على خوادم Apple.

وبحسب العرض التقني، لم يتضمن العميل وظائف من أجل:

• إرسال دعوات جديدة لمشاركة الموقع؛
• تعديل أذونات المشاركة القائمة؛
• إضافة أفراد العائلة؛
• إنشاء نطاقات جغرافية مستضافة على Apple؛ أو
• إصدار أوامر للأجهزة.

لذلك، فالنتيجة أقرب إلى اكتشاف يتعلق بالتوافق وحدود الثقة منها إلى ثغرة تتيح تتبع أي شخص عن بُعد. أما مصدر القلق الأكثر واقعية فيتعلق باختراق حساب Apple أو جهاز موثوق مرتبط به؛ إذ قد يؤدي ذلك إلى كشف المشاركات المتاحة أصلًا لذلك الحساب.

ما الفرق بين هذه التجربة وهجوم nRootTag؟

يتعلق عمل Zerotistic وnRootTag بجزأين مختلفين من منظومة Find My، كما يقدمان نموذجَي تهديد مختلفين تمامًا.

تجربة Zerotistic ركزت على Find My People: أعادت بناء جانب المستقبل ضمن علاقة مشاركة موجودة ومصرح بها. كان لا بد من قبول الحساب والجهاز لدى Apple، كما كان يجب أن يكون موقع الشخص قد شُورك مع ذلك الحساب.

أما nRootTag فاستهدف Find My Network والعثور على الأجهزة غير المتصلة: أفاد الباحثون بأن خدمة Apple قبلت أنواعًا من عناوين البلوتوث تتجاوز النوع العشوائي الثابت المتوقع. وقد يتيح ذلك للمهاجم جعل حاسوب يدعم البلوتوث يتصرف كمنارة شبيهة بـ AirTag، مستفيدًا من أجهزة Apple القريبة لترحيل موقعه من دون علم مالك الجهاز المستهدف.

باختصار، تلقت تجربة Zerotistic بيانات كان الحساب مخولًا أصلًا برؤيتها، بينما سعى nRootTag إلى إنشاء قدرة تتبع غير مصرح بها. وخلط التجربتين يجعل عرض لينكس يبدو أقوى بكثير مما تثبته الأدلة.

الهدف الأصلي ومدة العمل

كان الدافع المعلن للتجربة أتمتة قائمة على موافقة واضحة. فقد وافق صديق كان يشارك موقعه أصلًا على تشغيل نظام لينكس ينشئ نطاقات جغرافية محلية ويرسل إشعارات عبر Discord عند وصوله إلى أماكن محددة أو مغادرتها.

توقع Zerotistic في البداية أن تقتصر المهمة على طلب ويب يتطلب مصادقة، وقدّر أنها ستستغرق «أمسية من العمل». لكن الهندسة العكسية توسعت كثيرًا مقارنة بهذا التقدير الأولي. ولا تثبت المواد المتاحة مدة إجمالية دقيقة لإنجاز المشروع، لذلك فإن تحديد إطار زمني أكثر دقة سيكون تخمينًا غير مدعوم.

ماذا قالت Apple؟

تؤكد التغطية المتاحة تنفيذ العرض، لكنها لا تقدم بيانًا عامًا موثقًا من Apple يتناول تحديدًا تطبيق Find My People على لينكس، ولا تؤكد إصلاحًا بعينه أو نتيجة معلنة لبرنامج مكافآت الأخطاء.

وتبقى الرسالة الأساسية واضحة: حصر ميزة في أجهزة Apple لا يعني تلقائيًا أن العتاد هو الحد الأمني الفعلي. فإذا منحت الخوادم الثقة اعتمادًا أساسًا على بيانات الاعتماد والشهادات والقدرات وسلوك البروتوكول، فقد يتمكن عميل متوافق بدرجة كافية، حتى لو كان يعمل على نظام تشغيل آخر، من عبور الحد الذي تفرضه سياسة المنتج—مع بقائه مقيدًا بأذونات الحساب والمفاتيح التشفيرية التي يحصل عليها بصورة مشروعة.