تشغيل Find My People على Linux وفك تشفير المواقع المشتركة مباشرة

تمكن باحث أمني من إجراء هندسة عكسية لبروتوكول Find My People الخاص بشركة Apple، والوصول إلى طريقة تسمح لجهاز يعمل بنظام Linux بالتسجيل داخل خدمات Apple الداخلية واستقبال مفاتيح مشاركة الموقع وفك تشفير موقع مباشر تمت مشاركته مسبقًا.

المثير للاهتمام أن العملية تمت بالكامل من Linux، دون الحاجة إلى استخدام جهاز Mac أو iPhone لتنفيذ مسار الاتصال وفك التشفير.

المشروع لم يبدأ كمحاولة لاكتشاف ثغرة أمنية، بل كفكرة بسيطة لبناء تنبيهات Geofencing داخل Discord اعتمادًا على موقع صديق كان يشارك موقعه بالفعل من خلال تطبيق Find My.

لكن ما بدا في البداية كأنه مجرد استدعاء API بعد تسجيل الدخول تحول إلى رحلة هندسة عكسية استمرت قرابة أسبوع.

السبب أن Apple تعتمد على مجموعة من بروتوكولات الهوية والمراسلة الداخلية الخاصة بها، ولم يكن هناك مشروع مفتوح المصدر يعيد تنفيذ المسار الكامل المطلوب للوصول إلى بيانات Find My People.

اعتمد الباحث على تحليل وإزالة ترجمة عدد من خدمات Apple الداخلية مثل:

fmfd
findmylocated
searchpartyd

كما استفاد من مشاريع مفتوحة المصدر مثل:

FindMy.py
pypush

ومن خلال دمج نتائج التحليل مع هذه الأدوات، تمكن من إعادة بناء مسار الاتصال الكامل خطوة بخطوة.

#محاكاة جهاز Apple من الصفر

كانت أول عقبة هي عملية المصادقة.

محاولة استخدام رموز تسجيل الدخول التقليدية الخاصة بـ iCloud لم تنجح، حيث كانت واجهة Find My Friends القديمة تعيد الخطأ:

HTTP 401 Unauthorized

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

كل خدمة تقريبًا تحصل على بيانات اعتماد مخصصة لها من خلال عملية تبادل داخلية تعمل كوسيط بين حساب المستخدم والخدمة المطلوبة.

بعد تسجيل الدخول باستخدام GrandSlam، وهو بروتوكول المصادقة الخاص بحسابات Apple، تمكن الباحث من الحصول على Delegate Token لخدمة IDS.

IDS أو Identity Services تعد إحدى الطبقات الداخلية المهمة في بنية Apple، وتستخدم في عدد من الخدمات مثل iMessage وFind My لتنفيذ عمليات الهوية والمراسلة المشفرة.

لكن الحصول على Token لم يكن كافيًا.

كان على Linux أن يبدو أمام خوادم Apple وكأنه جهاز Apple حقيقي مسجل في المنظومة.

#إنشاء هوية جهاز متوافقة مع Apple

لإنشاء هوية الجهاز كان يجب إرسال Certificate Signing Request بتنسيق محدد جدًا.

المتطلبات التي اكتشفها الباحث تضمنت مفتاح RSA بطول:

2048-bit RSA

كما كان يجب توقيع الطلب باستخدام:

SHA-1

حتى قيمة Common Name داخل الشهادة لم تكن عشوائية.

كان يجب توليدها اعتمادًا على SHA-1 Hash لمعرف Profile ID الخاص بالحساب.

بعد ذلك يتم وضع البيانات داخل ملف Property List بصيغة XML، ثم ضغطه باستخدام:

gzip

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

#التسجيل داخل Find My

بعد إنشاء هوية الجهاز جاءت مرحلة تسجيل الجهاز داخل البنية الخاصة بـ Find My.

لكن التسجيل لم يكن يتم مباشرة مع Find My Friends.

بدلًا من ذلك، كان يجب تسجيل الجهاز من خلال خدمة multiplexing داخلية لدى Apple تعرف باسم:

alloy

وكانت عملية التسجيل تحتاج إلى ست خدمات فرعية محددة حتى يتم التعامل مع Linux كجهاز قادر على المشاركة داخل بنية Find My.

هذه المرحلة كانت ضرورية قبل الانتقال إلى الجزء الأهم في العملية، وهو الحصول على مفتاح تشفير مشاركة الموقع.

#كيف يحصل الجهاز الجديد على مفتاح مشاركة قائم بالفعل؟

هنا وصلت التجربة إلى الجزء الأكثر تعقيدًا من الناحية التقنية.

الموقع الذي يحاول الباحث قراءته كان بالفعل مشاركًا مع حسابه، وبالتالي لم تكن المشكلة في الحصول على صلاحية جديدة.

المشكلة كانت في إقناع Apple بأن ترسل مفتاح التشفير الخاص بهذه المشاركة إلى جهاز Linux الجديد.

وفقًا لتحليل نشره الباحث عبر مدونة Zerotistic، فإن إرسال طلب:

SubscribeAndFetch

مع Intent بالقيمة:

distributeKeys

يجعل الجهاز الذي يشارك الموقع يعيد توزيع مفتاح المشاركة الحالي.

عملية التوزيع تتم من خلال Apple Push Notification Service أو APNs.

لكن المفتاح لا يرسل بشكل مباشر.

يتم تغليفه داخل Envelope موقع ومتحقق منه باستخدام ECDH، ويعرف هذا التنسيق باسم:

pair-ec

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

عند إضافة جهاز جديد، لا يحتاج المستخدم إلى إعادة إنشاء مشاركة الموقع أو مشاركة الموقع مرة أخرى يدويًا.

تصميم النظام يسمح للأجهزة الجديدة بالحصول على المفاتيح الموجودة مسبقًا بشكل تلقائي.

#منحنى تشفير مختلف لمفتاح المشاركة

بعد استقبال المفتاح اكتشف الباحث تفصيلًا تشفيريًا إضافيًا.

مفتاح مشاركة الموقع نفسه يستخدم تشفير Elliptic Curve على المنحنى:

P-224

بينما الغلاف المستخدم في عملية المراسلة ونقل المفتاح يعتمد على:

P-256

هذا الاختلاف يعني أن Apple تستخدم أكثر من طبقة تشفير داخل المسار نفسه.

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

#الوصول إلى SearchParty

بعد الحصول على مفتاح المشاركة أصبح بإمكان الباحث الانتقال إلى خدمة أخرى داخل منظومة Apple تعرف باسم:

SearchParty

هذه الخدمة مسؤولة عن الاحتفاظ بتقارير المواقع المشفرة المستخدمة ضمن بنية Find My.

البيانات الموجودة على الخادم لم تكن عبارة عن Coordinates واضحة يمكن قراءتها مباشرة.

بدلًا من ذلك، تقوم الخدمة بتخزين تقارير الموقع في صورة مشفرة.

قام الباحث بجلب هذه البيانات ثم فك تشفيرها محليًا على جهاز Linux.

عملية فك التشفير اعتمدت على:

ECDH
AES-GCM

استخدم ECDH للوصول إلى السر المشترك المطلوب، ثم استخدم AES-GCM لفك تشفير التقرير والتحقق من سلامة البيانات.

#النتيجة

في النهاية تمكن جهاز Linux من الحصول على موقع مباشر تم مشاركته مع الحساب بشكل شرعي.

البيانات المستخرجة شملت:

Latitude
Longitude
Accuracy Radius
Timestamp

أي أن الباحث تمكن من الوصول إلى الإحداثيات، ونطاق دقة الموقع، والوقت المرتبط بآخر تقرير.

كل ذلك تم من خلال Linux ومن دون الاعتماد على Mac أو iPhone لتنفيذ عملية فك التشفير.

#هل تعتبر هذه ثغرة في Find My؟

رغم أن النتيجة تبدو للوهلة الأولى وكأنها تجاوز لأحد قيود Apple، إلا أن التجربة لم تكشف عن ثغرة أمنية تحتاج الشركة إلى إصلاحها.

الباحث لم يحصل على موقع شخص لم يمنحه الإذن.

الموقع كان مشاركًا أصلًا مع حساب الباحث بشكل طوعي من خلال Find My.

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

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

#لماذا تعتبر هذه الهندسة العكسية مهمة؟

أهمية المشروع لا تكمن في اكتشاف ثغرة، بل في توثيق أجزاء لم تكن معروفة بشكل واضح من البنية الداخلية لـ Apple.

التجربة توضح بالتفصيل كيف تتعامل خدمات:

IDS
SearchParty
Find My
APNs

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

كما توفر فهمًا أفضل للطريقة التي تستخدم بها Apple مفاتيح ECDH وAES-GCM لحماية بيانات المواقع أثناء انتقالها وتخزينها.

هذه المعلومات قد تكون مفيدة للباحثين المهتمين ببناء أدوات متوافقة مع Find My أو عملاء مفتوحي المصدر أو حلول Self-hosted تستطيع التعامل مع البروتوكولات نفسها.

وفي الوقت نفسه، توضح التجربة مدى تعقيد البنية الموجودة خلف ميزة تبدو للمستخدم بسيطة جدًا.

ضغطة واحدة لمشاركة الموقع داخل Find My تقف خلفها منظومة كاملة من هويات الأجهزة والشهادات ومفاتيح Elliptic Curve ورسائل Push وبروتوكولات خاصة لم توثقها Apple بشكل علني.

وهنا تحديدًا تظهر قيمة الهندسة العكسية.

ليس بالضرورة أن تنتهي كل عملية Reverse Engineering بثغرة أمنية.

أحيانًا تكون النتيجة الأهم هي فهم النظام نفسه، ومعرفة ما يحدث فعلًا خلف الواجهة التي يستخدمها ملايين الأشخاص يوميًا.