تشغيل ثغرات المتصفح لتخطي Windows Defender Application Control (WDAC)

Windows Defender Application Control (WDAC) هي ميزة أمان في نظام Windows تساعد على منع تشغيل الكود غير المصرح به (مثل البرامج الضارة أو الملفات التنفيذية والنصوص البرمجية غير الموثوقة) على النظام. وتُعد آلية موثوقة للتطبيقات تفرض سياسات تسمح فقط بتشغيل الملفات التنفيذية والنصوص البرمجية وبرامج التشغيل الموثوقة بشكل واضح على النظام. تُستخدم كثيرًا في بيئات فائقة الموثوقية أو خاضعة لضوابط صارمة حيث يكون كل من الأمان وسلامة النظام أمرًا مهمًا، مثل تلك التي يعمل فريق X-Force Red Adversary Simulation على اختبارها.

قبل بضعة أسابيع، نشر زميلي Bobby Cooke منشور مدونة يوضح طريقة لتخطي حتى أكثر سياسات WDAC صرامة من خلال تطبيقات Electron الموثوقة بطريقة الباب الخلفي. أنصح بشدة بقراءة منشور مدونته لتتعرف على كيفية استخدام تطبيقات Electron لبيئة Node.js وكيف يمكن تحويلها إلى باب خلفي.

وكجزء من البحث، جعل أيضًا Loki C2 مفتوح المصدر، وهو إطار عمل قيادة وتحكم يعتمد على Node.js. وبفضل العمل الممتاز الذي قام به Bobby وDylan Tran في تطوير Loki C2، تمكن فريق X-Force Adversary Simulation من تنفيذ الكود في المهام المنفذة في البيئات المحصنة التي تستخدم WDAC.

إذن، ما دور هذا البحث؟ التقنية السابق ذكرها بها عيب واحد: أنك مقيد بتنفيذ كود JavaScript فقط، ولا يمكنك تنفيذ الكود الأصلي، مثل تحميل ملفات DLL أو تشغيل ملفات ExE. كما لا يمكنك تنفيذ كود shellcode لتشغيل حمولة C2 في المرحلة الثانية. يتناول منشور المدونة هذا التقنية التي استخدمناها للتغلب على هذه القيود.

في البداية، بدأتُ أنا وBobby بإجراء هندسة عكسية لوحدات Node.js الموقّعة التي تحمّلها تطبيقات Electron، بحثًا عن الثغرات التي يمكن أن تتيح إمكانية تنفيذ كود منخفض المستوى وعلى مستوى التعليمات. بعد بعض الاستكشافات الأولية وبناءً على اقتراح من jeffssh، تحوّل انتباهي إلى محرك V8 الذي يستخدمه Node.js ومتصفح Chrome.

بدلاً من إيجاد ثغرة في وحدة Node.js، ماذا عن استغلال محرك V8 باستخدام ثغرة N-day؟

يُعد سيناريو الهجوم أحد سيناريوها الهجوم المألوفة: إحضار ملف ثنائي معرض للخطر ولكنه موثوق، واستغلال حقيقة أنه موثوق به للحصول على موطئ قدم على النظام. في هذه الحالة، نستخدم تطبيق Electron موثوق يحتوي على إصدار V8 معرض للخطر، مع استبدال main.js بثغرة V8 التي تنفذ المرحلة الثانية كحمولة، وهكذا نتمكن من تنفيذ كود shellcode الأصلي. إذا كان التطبيق المستغل معتمدًا/موقّعًا من جهة موثوق بها (مثل Microsoft) ويُسمح عادةً بتشغيله بموجب سياسة WDAC المستخدمة، فيمكن استخدامه كوعاء للحمولة الخبيثة.

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

بدا هذا النهج بسيطًا ومباشرًا، ولكن كان يدور في ذهني بعض الأسئلة التي لم أجد لها إجابة. هل يمكن أن تعمل ثغرة Chrome V8 N-day العامة داخل تطبيق Electron؟ ما مدى اختلاف محرك V8 المستخدم في Chrome عن المحرك الموجود في Node.js؟ ما التعديلات التي ستحتاجها الثغرة؟ وكيف يمكنني تصحيح ذلك؟

اتضح أن هناك عملاً عامًا موجودًا حول استغلال ثغرات V8 في تطبيقات Electron، والذي، مع الأسف، لم أكتشف أنه موجود إلا بعد أن انتهيت من عملي. يؤدي Turb0 عملاً ممتازًا في تغطية عملية (كانت مرهقة بعض الشيء) تكييف ثغرة v8 عامة وبيانات القراءة/الكتابة البدائية المقابلة لها للعمل داخل تطبيق Electron. يغطي منشور مدونة Turb0 بالفعل الكثير من التفاصيل التقنية المتعمقة لما اضطررت إلى التعامل معه، والتي أنصح بشدة بمراجعتها. ستركز بقية منشور المدونة هذا على المراحل المتبقية من دورة تطوير الاستغلال فيما يتعلق باستهداف Windows بهدف محدد متمثل في إنشاء عملية تخطي WDAC والمشكلات التي واجهتها في تشغيل الاستغلال عمليًا.

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

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

توصلت إلى أن أسهل طريقة هي استخدام ثغرة مصححة بعد نشر إصدار التطبيق. وبهذه الطريقة، لن يكون هناك أي احتمال على الإطلاق أن يكون هذا الإصدار من التطبيق قد خضع للتصحيح بعد. وبعد إجراء بعض الأبحاث، وجدت روابط تنزيل لإصدارات  VSCode خلال العامين الماضيين تقريبًا. وأصبح لديّ مجموعة لا بأس بها من التطبيقات الموقعة من Microsoft والمعرضة للاختراق للاختيار من بينها 😊.

في البداية، أخذت ببساطة نموذج إثبات المفهوم العام الأخير الخاص باستغلال V8 واخترقت تطبيق Electron المعرض للخطر باستخدامه، واستبدلت main.js بالثغرة، على أمل أن أنجح. ربما يكون الأمر بهذه السهولة، أليس كذلك؟ كنت أتمنى حدوث عطل على الأقل. وكما هو متوقع، لم يحدث أي شيء عندما شغلت التطبيق. وأدركت أنني سأحتاج إلى إنشاء V8 مكرهًا لفهم ما حدث على مستوى أعمق. من خلال إنشاء V8 بنفسي، سأتمكن من إصدار التصحيح (d8)، والدخول في أعماق الثغرة، ثم تعديلها لتتناسب مع الإصدار المحدد الذي كنت استهدفه.

كان هدفي الأول هو إنشاء "حقيقة مثبتة" – أي تكرار البيئة نفسها التي من المعروف أن عملية الاستغلال ستعمل فيها. بعد ذلك، تمكنت من فحص أوجه الاختلاف بين هذا الإصدار والإصدار الذي كنت أستهدفه لفهم الخطأ الذي حدث.

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

وعندئذٍ، أعددت إصدار V8 الذي كنت أستهدفه (الإصدار نفسه المستخدم في تطبيق Electron)، ولكن على Linux. لم تنجح عملية الاستغلال في البداية. تكمن ميزة إنشاء مشروع بنفسك في أنك تستطيع التأمل في الكود كما تريد. على وجه الخصوص، يحتوي V8 على d8، وهي الواجهة المستقلة لمحرك V8 JavaScript، والتي تُستخدم بشكل أساسي لاختبار وتصحيح الأخطاء وتشغيل كود JavaScript وWebAssembly خارج المتصفح أو خارج بيئة Node.js. تحتوي d8 على مزايا تصحيح أخطاء داخلية تُمكّن باستخدام --allow-natives-syntax علامة. وعلى وجه الخصوص،%DebugPrint(value) والذي يطبع التمثيل الداخلي الموسوم للقيمة داخل محرك V8، بما في ذلك عنوانها في الذاكرة.

وبهذا، يمكنني طباعة عناوين الكائنات المهمة وضبط قيم التعويض المشفرة ضمنيًا للثغرة العامة. الآن يمكنني القول إني قد حققت شيئًا. كل ما تبقى هو نقل ثغرتي إلى نظام Windows.

لقد سبب لي إعداد إصدار أقدم من V8 على Windows الكثير من المتاعب. كان عليّ إصلاح العديد من المشكلات المتعلقة بالتبعيات، لذا أجريت بعض التعديلات الداخلية في مواضع الشك على الكود. لا أتذكر التفاصيل الآن -- لقد حجبها عقلي حفاظًا على سلامتي. وبعد ساعات من الصعوبات، تمكنت أخيرًا من إعداد الإصدار الذي أحتاجه! وقد فوجئت بأن الثغرة المعدلة في Linux نجحت في العمل على نظام Windows من دون أي تعديلات.

الآن، كل ما تبقى هو اختبار عملية الاستغلال على تطبيق Electron والترقب... أوه، لم تنجح! لكن ما السبب؟

في البداية، كنت متفائلاً لأن الهدف قد تعطل بالفعل. لكن بعد كل ذلك، لم أكن قد كيّفت حمولة Linux مع Windows، لذا لم أتوقع حدوث أي شيء مثير للاهتمام. وللتأكد من السلوك، غيرت حمولة الاستغلال لتنفيذها في العنوان 0x4141414141. وهذه تقنية شائعة يستخدمها كُتاب أكواد الاستغلال ليتمكنوا من رؤية/إثبات أنهم قد تمكنوا من السيطرة على البرنامج من خلال التحكم في عنوان مؤشر التعليمات. لكن، بعد فحص العطل في WinDbg، لم أكن أرى النتيجة التي أريدها. كان يظهر لي خطأ في التجزئة عند استبدال مؤشر الدالة المستهدفة.

هل تتذكر ما قلته من قبل عن اختيار Electron لعمليات تنفيذ V8 بعناية؟ اتضح أنه على الرغم من أن التطبيق الذي كنت أستخدمه في عملية الاستغلال كان عرضة للخطأ، إلا أن طريقة الهروب من آلية تحديد الوصول التي استخدمها الاستغلال العام كانت قد جرى تصحيحها بالفعل عبر الاختيار الانتقائي. إذا لم تكن تعرف آلية تحديد الوصول/قفص الذاكرة في V8، فيمكنك القراءة عنها هنا. باختصار، هي طريقة لجعل استغلال V8 أكثر صعوبة في حال وجود ثغرة أمنية.

ولكي أدرك ما كان يحدث، كنت بحاجة إلى إنشاء الإصدار المستهدف من V8 مرة أخرى، مع تطبيق التصحيحات المختارة بعناية هذه المرة. بالإضافة إلى تصحيحات الأمان، تُطبق Node.js أيضًا تصحيحات Node.js خاصة على إصدار V8 الذي يستخدمه Electron. لقد استغرق الأمر مني وقتًا طويلاً لأدرك أنني بحاجة إلى القيام بذلك، لأن كيفية تعامل Electron وNode.js مع تبعياتهما المختلفة لم تكن واضحة من البداية.

بعد يوم أو يومين من محاولة التأكد من أن إصدار V8 الذي كنت أعمل على إعداده *مطابقٌ* لهدفي، بالإضافة إلى القراءة عن تقنيات الهروب الحديثة من آلية تحديد الوصول، أحرزت تقدمًا. لقد تمكنت من العثور على تقنية هروب تناسب هدفي. بعد ضبط عملية الاستغلال، تمكنت أخيرًا من تعطيل التطبيق من خلال التحكم في مؤشر التعليمات. كان انتصارًا رائعًا، لقد رأيت الضوء في نهاية النفق...

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

إذا كنت تعرف عن البرمجة باستخدام كود shellcode، فستعرف أن كتابة كود shellcode في Windows أكثر صعوبة من كتابة كود shellcode في Linux، ويرجع ذلك أساسًا إلى أنه لا توجد طريقة بسيطة لإجراء استدعاءات نظام مباشرة بشكل مستقل عن الموقع كما هو الحال في Linux. تحتاج الحمولة أيضًا إلى "تهريبها باستخدام JOP" داخل مصفوفة أرقام عشرية:

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

تكمن المشكلة في حمولة التشغيل التمهيدي في أنها رغم أنني كنت أتحكم في البرنامج، فإنني لم تكن لدي طريقة لتمرير الوسيطات إلى الحمولة المنفذة. لذلك، لن يعرف كود shellcode الذي هربته عنوان الحمولة النهائية التي يجب النسخ منها. لقد تمكنت من التغلب على هذا من خلال ما سميته "تهريب الوسيطات".

كنت أعلم أن عنوان كائن JSFunction المستبدل سوف يُخزن في السجل rcx. لذلك، باستخدام بيانات الكتابة العشوائية البدائية، خزنت الصفحة المعينة في أحد حقول الكائن والذي لن تكون هناك حاجة إليه. استغرق هذا الأمر فترة من التجربة والخطأ، حيث تسبب استبدال بعض قيم التعويض في حدوث أعطال. وفعلت الشيء نفسه مع القيمة المراد نسخها وقيمة التعويض التي ستُلصق فيها. يمكن أن تكون قيمة تعويض الحقل مشفرة ضمنيًا في كود shellcode، حتى يكون معروفًا المكان الذي تُنسخ منه الحمولة. لقد اتصلت بالحمولة n عدة مرات، حيث تشير n إلى عدد وحدات البايت المراد نسخها.

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

واجهت أيضًا مشكلات في نسخ كود shellcode إذا كانت حمولة المرحلة الثانية كبيرة جدًا، وربما يرجع ذلك إلى عدد المرات التي احتجت فيها إلى استدعاء دالة JSFunction وTurboFan المتلاعب بهما، في محاولة لتحسين ذلك. تمكنت في النهاية من التغلب على هذه المشكلة بنسخ عدة حلقات ولصقها في "WriteShellcode" بدلاً من استخدام حلقة واحدة كبيرة. وهذا أمر مروع، لكنه نجح! لاحقًا، بدل Bobby وDylan حمولة C2 بحمولة وسيطة استردت الحمولة الأكبر من مخزن البيانات الثنائية الكبيرة، لذا لم يكن من الضروري تخزين الحمولة النهائية على القرص. وقد ساعد ذلك أيضًا على الحفاظ على حجم ملف main.js عند حد معقول.

يجب أن يتضمن الاستعداد للاستخدام التشغيلي الفعلي للثغرات دائمًا الاختبار في بيئات مختلفة. في سياق المهمة، لم نكن نعرف البيئة التي ستُنفذ فيها الحمولة، كنا نعرف فقط أنها ستكون على نظام Windows الذي من المحتمل أن يكون قد جرى تمكين WDAC عليه. لذلك، يجب أن تنجح عملية الاستغلال بغض النظر عن نظام التشغيل. كنت واثقًا أنه بما أن إصدار التطبيق V8 وجميع التبعيات كانت موجودة داخل التطبيق، فلن نلاحظ الكثير من الاختلاف. وقد كنت مخطئًا في هذا الافتراض.

لأسباب لا أعرفها، تغيرت قيمة تعويض مؤشر الدالة التي بها ثغرة والمراد استبداله عبر إصدارات Windows. لم يكن هذا منطقيًا لأنه كما أعرف، مسافة التعويض يحددها محرك V8 JIT، والذي تُحمَّل مكتباته مباشرةً من حزمة التطبيق. وهذا يعني أن مكتبات V8 نفسها تُحمَّل بغض النظر عن نظام التشغيل. ولجعل الأمور أكثر إرباكًا، كان التغيير لا يتبع أي نمط. أحيانًا كانت قيمة التعويض مختلفة بمقدار 4 بايت في بعض إصدارات Windows (القديمة والحديثة). وكان هذا مزعجًا بشكل خاص لأنه لم تكن هناك أية طريقة (على حد علمي) لاستخلاص قيمة التعويض الصحيحة من داخل ثغرة JavaScript. الطريقة الوحيدة لحسابها كانت استخدام واجهة التصحيح لقراءة عنوان الذاكرة وإجراء بعض العمليات الحسابية، وهو ما لم يكن خيارًا متاحًا داخل تطبيق Electron الإنتاجي. باختصار: لا يمكن حساب التغيير في قيم التعويض في وقت تشغيل عملية الاستغلال.

من أجل التغلب على مشكلة عدم اتساق قيم التعويض، أعاد Bobby وDylan هندسة الاستغلال بحيث تشغل main.js عملية الاستغلال عدة مرات، مع تجربة مختلف قيم التعويض الممكنة حتى تنجح. وقد جرى ذلك من خلال جعل عملية الكود الأولية تنفذ حلقة تكرارية. أنتجت هذه الحلقة عمليات فرعية من شأنها أن تحاول استغلال قيم تعويض فريدة. إذا فشل الاستغلال، فستتوقف العملية الفرعية. وإذا نجح الاستغلال، فسيُنفذ كود shellcode ويُكتب ملف Mutex قبل نشر خادم C2 في المرحلة الثانية. بمجرد نجاح الاستغلال، ستخرج العملية الأولية من الحلقة وتتوقف إلى الأبد.

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

من الواضح أننا لم نكن نرغب في أن تكون الثغرة واضحة في حال اكتشافنا وتحليل أحدهم لنقطة دخول main.js الخاصة بالتطبيق. ولتجنب ذلك، استخدمنا أداة تشويش JavaScript على كود الثغرة، ما جعلها غير مفهومة تقريبًا للعين البشرية. وبفضل موهبة وتفاني Chris Spehn، الذي يدير مسار التكامل المستمر/التسليم المستمر الخاص بالحمولة في الفريق، تمكنا من تبسيط عملية نشر هذه الحمولة وإعادة تشويش الكود في كل مرة تُنشأ فيها الحمولة، حتى نتمكن من إعادة استخدام التطبيق إلى أجل غير مسمى مع كود ثغرة مختلف في كل مرة. وقد أدى ذلك إلى منع توقيع الحمولة. وقد أثبت ذلك جدواه بشكل خاص، لأنه للأسف، في المرة الأولى التي حاولنا فيها استخدام تلك الإمكانية، جرى اكتشافنا لأن المستخدم أبلغ عن رسالة تصيد احتيالي عبر البريد الإلكتروني 🙁. ومن المثير للاهتمام أنه بينما كان فريق العميل الأزرق يحلل التطبيق الوارد في رسالة البريد الإلكتروني التصيدية، لم يتمكنوا من معرفة الغرض من التطبيق، ولم يتعرفوا على ثغرة V8 المدمجة.

ما زلت لا أفهم تمامًا سبب اعتماد قيم تعويض الدالة JITted على نظام التشغيل، حيث من المفترض أن تكون جميع مكتبات V8 ذات الصلة مجمعة ضمن تطبيق Electron. إذا كان لدى أي شخص أي فكرة عن سبب ذلك، فيُرجى إخباري!

أطلقت Electron ميزة تجريبية للسلامة تتحقق من سلامة جميع ملفات التطبيقات في أثناء التشغيل. وهي متاحة لنظام التشغيل macOS منذ الإصدار 16 ولنظام Windows منذ الإصدار 30. يمكن لمطوري التطبيقات تفعيل اندماج Electron هذا لضمان عدم العبث بأي من ملفات التطبيقات. وفي حال العبث بها، ستتوقف العملية تلقائيًا، ولن يُجرى تنفيذ أي شيء.

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

Bobby Cooke وDylan Tran – المساعدة على تنفيذ الاستغلال

Dylan Tran – إنشاء المخطط

Chris Spehn– دمج هذه الحمولة في مسار التكامل المستمر/التسليم المستمر لدينا (وكل عمليات التطوير الأخرى التي نفذتها للفريق والتي لا تُقدر بالشكر)

jeffssh – الإلهام

j j - لدوره كمخترق V8 محترف والذي ساعدت إثباتات المفهوم الكثيرة التي قدمها عن V8 بشكل كبير