يمكنني أن أصبح أبل ، وأنت أيضًا

الكشف العلني عن رمز Apple توقيع ثغرة الطرف الثالث

على عكس بعض الأعمال السابقة ، لا تتطلب هذه الثغرة حقوق المسؤول ، ولا تتطلب كود JIT أو تلف الذاكرة لتجاوز التحقق من توقيع الرمز. كل ما تحتاجه هو ملف Fat / Universal منسق بشكل صحيح ، وسيظهر التحقق من توقيع الرمز نتيجة صالحة.

الملخص

• العثور على التفاف يستخدمه طرف ثالث API لتوقيع رمز يسمح لك بتقديم أي رمز كما وقعته Apple.
• يتم إخطار جميع البائعين والمشاريع مفتوحة المصدر المعروفة (انظر القائمة أدناه). تتوفر بقع لهم.
• هناك احتمال أن تؤثر المشكلة على برامج الجهات الخارجية الأخرى التي تستخدم واجهات برمجة التطبيقات لتوقيع التعليمات البرمجية الرسمية من Apple.
• المطورون مسؤولون عن الاستخدام الصحيح لواجهة برمجة التطبيقات لتوقيع التعليمات البرمجية. هناك أدوات قرصنة تجريبية (PoC) للاختبارات.
• ينطبق فقط على macOS والإصدارات الأقدم من OSX.

الباعة المتأثرون

• VirusTotal - CVE-2018-10408
• جوجل - سانتا ، مدقق الشيفرات - CVE-2018-10405
• Facebook - OSQuery - CVE-2018-6336
• تطوير الهدف - LittleSnitch - CVE-2018-10470
• F-Secure - xFence (أيضًا LittleFlocker) CVE-2018-10403
• الهدف - انظر - WhatsYourSign و ProcInfo و KnockKnock و LuLu و TaskExplorer (وغيرها) - CVE-2018-10404
• Yelp - OSXCollector - CVE-2018-10406
• أسود الكربون - استجابة Cb - CVE-2018-10407

أهمية توقيع الرمز وكيف يعمل على macOS / iOS

توقيع الرمز عبارة عن تكوين أمان يستخدم بنية أساسية للمفتاح العام (PKI) للتوقيع الرقمي على التعليمات البرمجية المترجمة أو حتى البرامج النصية للتأكد من أنها موثوقة وأن الرمز موثوق. على نظام التشغيل Windows ، يمكنك توقيع أي شيء تقريبًا: من ثنائيات .NET إلى برامج PowerShell النصية. في نظام macOS / iOS ، يشير توقيع الرمز بشكل أساسي إلى ثنائيات Mach-O وحزم التطبيقات للسماح بتنفيذ التعليمات البرمجية الموثوق بها فقط في الذاكرة.

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

تم العثور على مشاكل بالفعل في توقيع الرمز ( 1 ، 2 ، 3 ، 4 ، 5 ). على عكس بعض الأعمال السابقة ، لا تتطلب هذه الثغرة حقوق المسؤول ، ولا تتطلب كود JIT أو تلف الذاكرة لتجاوز التحقق من توقيع الرمز. كل ما تحتاجه هو ملف Fat / Universal منسق بشكل صحيح ، وسيظهر التحقق من توقيع الرمز نتيجة صالحة.

تفاصيل الضعف

يتمثل جوهر الثغرة الأمنية في عدم استخدام مُحمل Mach-O وواجهة برمجة التطبيقات لتوقيع الرمز للتحقق من توقيعات التعليمات البرمجية بشكل غير صحيح. يمكن استغلال هذا الاختلاف باستخدام ثنائي عالمي / دهني معد خصيصًا.

ما هو ملف Fat / Universal؟

Fat / Universal هو تنسيق ثنائي يحتوي على العديد من ملفات Mach-O (ملف قابل للتنفيذ أو dyld أو حزمة) ، يركز كل منها على بنية وحدة معالجة مركزية محددة (على سبيل المثال ، i386 أو x86_64 أو PPC).

المتطلبات الأساسية

• يجب أن يتم توقيع أول Mach-O في ملف Fat / Universal بواسطة Apple ، ويمكن أن يكون ملف i386 أو x86_64 أو حتى PPC.
• يجب تجميع رمز ثنائي أو دخيل ضار موقّع ذاتيًا بموجب i386 لنظام macOS x86_64.
• يجب تعيين CPU_TYPE في رأس Fat ثنائي Apple على نوع معالج أو نوع غير صالح غير أصلي لمجموعة شرائح المضيف.

بدون اجتياز SecRequirementRef المقابل و SecCSFlags ، ستتحقق واجهة برنامج API Code Signing ( SecCodeCheckValidity ) من أول ثنائي في ملف Fat / Universal لمعرفة أصل التوقيع (على سبيل المثال ، Apple) والتحقق من صحة التوقيع. بعد ذلك ، ستتحقق واجهة برمجة التطبيقات من جميع الثنائيات الأخرى في ملف Fat / Universal للتأكد من امتثال معرفات الفريق ومصداقية التوقيع ، ولكن دون التحقق من جذر الثقة في المرجع المصدق . السبب وراء وجوب أن يكون الرمز الخبيث أو الرمز "غير الموقّع" هو i386 لأن واجهة برمجة تطبيقات Code Signing يتم تكوينها افتراضيًا للتحقق من توقيع الرمز لبنية وحدة المعالجة المركزية الأصلية (x86_64).

أحد أسباب اجتياز التعليمات البرمجية الموقعة ذاتيًا الاختبار بنجاح هو أنه حتى في ثنائيات Apple الرئيسية ، يتم تعيين حقل TeamIdentifier على عدم التعيين. يوضح الرسم التوضيحي أدناه ثنائي Mach-O صالح ، موقع من قبل Apple (python.x64) ، بجوار Mach-O (ncat.i386) الموقعة ذاتيًا. كلاهما لديه `TeamIdentifier = لم يتم تعيينه`.



على سبيل المثال ، قمت بتوقيع ثنائي باستخدام معرف المطور وحاولت في ليبو أن تدمجه مع Apple ثنائي في ملف Fat / Universal واحد. فشل هذا النوع من توقيع الرمز.



بلدي PoC الأولي هو ncat (من nmap) ، والذي أسميته ncat.frankenstein. هنا ، يحتوي ملف Fat الناتج على ثعبان Apple الموقّع x86_64 الثنائي و ncat i386 ثنائي (adhoc) ذاتي التوقيع. يتم إنشاء ثنائي ثنائي موقعة ذاتيًا بسهولة باستخدام codesign -s - target_mach-o_or_fat_binary . إليك ما يبدو عليه في MachOView:



إذا قمت بتشغيل هذا الملف ، فسيبدأ python x86_64:



ويتم التحقق من توقيع الرمز:



كيف قمت بتشغيل ثنائي ncat الموقعة ذاتيا؟

يتم ذلك عن طريق تعيين نوع CPU_Type غير صالح أو CPU غير أصلي (على سبيل المثال ، PPC). ثم يتخطى محمل Mach-O ثنائي Mach-O بتوقيع صالح وينفذ كود خبيث (غير موقّع من Apple):



ثم يتم تنفيذ ncat.frankenstein ، وستكون نتيجة التحقق valid :



نشرنا ncat.frankenstein وأربعة أمثلة أخرى بحيث يمكن للمطورين التحقق من وجود ثغرات في منتجاتهم.

التوصيات

في سطر الأوامر

يعتمد على كيفية التحقق من الشفرة الموقعة. إذا كنت تستخدم رمزًا ، فمن المحتمل أنك على دراية بالأوامر التالية:

• codesign –dvvvv - تفريغ سلطة التصديق و TeamIdentifier (معرف المطور)
• codesign –vv - التحقق الصارم من جميع codesign –vv

ولكن للتحقق من هذا النوع من إساءة الاستخدام بشكل صحيح ، تحتاج إلى إضافة متطلبات شهادة الارتساء بالأوامر التالية:

• codesign -vv -R='anchor apple' ./some_application_or_mach-o # للرمز الموقع من Apple
• codesign -vv -R='anchor apple generic' ./some_application_or_mach-o # للرمز الموقع من Apple و Apple

سيظهر مثل هذا الأمر خطأ عند التحقق من الرمز بتوقيع شخص آخر:



يمكنك استخدام الأمر spctl ، ولكنه يتطلب تحليلًا دقيقًا لمخرجات الأمر. على سبيل المثال ، ثنائي Mach-O بتوقيع Apple (/ bin / ls) و Safari يُرجع ما يلي:



وهنا نتيجة تطبيق وقعت عليه Apple:



لاحظ السطر "(الرمز صالح ولكن لا يبدو أنه تطبيق)" لـ / bin / ls ، الذي لا يجتاز الاختبار. للمقارنة ، هنا نتيجة ملف Fat / Universal ncat.frankenstein:



لا يُظهر ملف ncat.frankenstein Fat / Universal أن الرمز صالح. لذلك ، لا يمكنني أن أوصي spctl للتحقق يدويًا من ثنائيات Mach-O غير المتصلة. مجرد استخدام رمز مع العلامات المناسبة.

للمطورين

عادةً ما يتحقق المطورون من ثنائيات Mach-O أو Fat / Universal باستخدام SecStaticCodeCheckValidityWithErrors () أو SecStaticCodeCheckValidity () APIs مع العلامات التالية:

• kSecCSStrictValidate
• KSecCSCheckAllArchitectures

يجب أن تضمن هذه العلامات أن جميع التعليمات البرمجية التي تم تحميلها في الذاكرة في ملف Mach-O أو Fat / Universal موقعة بشكل مشفر. ومع ذلك ، لا توفر واجهات برمجة التطبيقات هذه التحقق الصحيح من الصحة بشكل افتراضي ، لذا يحتاج مطورو الجهات الخارجية إلى عزل كل بنية في ملف Fat / Universal والتحقق من مطابقة الهويات وقويتها في التشفير.

أفضل طريقة لاختبار كل بنية متداخلة في ملف Fat / Universal هي الاتصال أولاً بـ SecRequirementCreateWithString بمتطلب "تفاحة مرساة" ، ثم SecStaticCodeCheckValidity باستخدام kSecCSDefaultFlags | kSecCSCheckNestedCode | kSecCSCheckAllArchitectures | kSecCSEnforceRevocationChecks بالإشارة إلى المتطلبات ؛ كما هو موضح في كود المصدر المرقح لـ WhatsYourSign .

بتمرير "تفاحة مرساة" إلى وظيفة SecRequirmentCreateWithString ، تعمل هذه المكالمة بشكل مماثل codesign -vv -R='anchor apple' ، الذي يتطلب سلسلة ثقة توقيع برامج Apple لجميع الثنائيات المتداخلة في ملف Fat / Universal. بالإضافة إلى ذلك ، من خلال تمرير العلامات ومتطلبات SecStaticCodeCheckValidity ، يتم فحص جميع البنيات لهذا المطلب ، ويتم تطبيق عمليات التحقق من الإبطال.

المظاهرات

أداة Apple codesign والحاجة إلى استخدام علامة -R .



LittleSnitch - لا يعمل التحقق من ملف Fat / Universal على القرص ، ولكن LittleSnitch يتحقق بشكل صحيح من العملية في الذاكرة.





LittleFlocker - اشترت F-Secure LittleFlocker ، والآن تسمى xFence.



F-Secure xFence (LittleFlocker سابقًا)



أدوات انظر الهدف

Taskexplorer





WhatsYourSign



Facebook OSquery هو نتيجة عينات من البرامج الضارة و / bin / ls كمثال صالح.



إصدار Google Santa - يوضح Fileinfo أن ncat.frankenstein مدرج في القائمة البيضاء:



رفض تنفيذ ncat (بدون توقيع) وإذن تنفيذ ncat.frankenstein:



سجل Santa.log يعرض الأحداث من المثال السابق:



استجابة الكربون الأسود



VirusTotal - مثال bash_ppc_adhoc قبل تثبيت التصحيح في VirusTotal:

تواريخ الإفشاء

02/22/2018: تم إرسال تقرير و PoC إلى Apple لتجاوز أنظمة الأمان التابعة لجهات خارجية.

03/01/2018: ردت Apple بأنه يجب على مطوري الجهات الخارجية استخدام kSecCSCheckAllArchitectures و kSecCSStrictValidate مع SecStaticCodeCheckValidity API ، وسيتم تحديث وثائق المطور وفقًا لذلك.

03/06/2018: تم إرسال تقرير و PoC إلى Apple لتجاوز الأعلام والتحقق بدقة من codesign .

03/16/2018: تم إرسال معلومات إضافية إلى Apple.

03/20/2018: قالت شركة آبل إنها لا ترى ذلك كمشكلة أمنية يجب معالجتها مباشرة.

03/29/2018: ذكرت Apple أنه يمكن تحديث الوثائق ، ولكن "[...] يجب على مطوري الطرف الثالث القيام بعمل إضافي للتحقق من أن جميع الهويات في ثنائي عالمي هي نفسها إذا كانوا يريدون تقديم نتيجة ذات مغزى."

04/02/2018: أول اتصال مع CERT / CC والتعاون اللاحق لتوضيح نطاق وتأثير الضعف.

04/09/2018: يتم إخطار جميع مطوري الجهات الخارجية المعروفين المتأثرين بالثغرة بالتنسيق مع CERT / CC.

04/18/2018: الاتصال الأخير مع CERT / CC مع التوصية بأن الكشف العلني عن المعلومات على المدونة هو الأفضل لإخطار مطوري الطرف الثالث الآخرين الذين يستخدمون واجهة برمجة تطبيقات توقيع كود Apple بشكل خاص.

06/05/2018: الاتصال النهائي مع المطورين قبل النشر.

06/12/2018: الكشف عن المعلومات.

في الختام

شكرًا لجميع مطوري الجهات الخارجية على عملهم الشاق واحترافيتهم في حل هذه المشكلة. ثغرات توقيع الرمز هي أخطاء معنوية بشكل خاص ، خاصة للشركات التي تحاول توفير أمان أفضل من الافتراضي في نظام التشغيل.

---

إجراء GMO GlobalSign روسيا لمشتركي هبر


يمكنك الحصول على معلومات إضافية عن طريق الاتصال بمدير GlobalSign عبر الهاتف: +7 (499) 678 2210 ، أو ملء النموذج على الموقع الإلكتروني ، مع الإشارة إلى الرمز الترويجي CS002HBFR.