Browser-Pwning

توثيق مناسب ومنظم جيداً للبدء في اختراق كروم واختراق v8

هيكل المستند

كيف تم تنظيم هذا المستند

1. الدافع
2. المادة الدراسية الفعلية

الدافع

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

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

سبب آخر لاختياري v8 كهدف هو أنه يُستخدم عبر متصفحات متعددة.

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

لسوء الحظ، بينما كانت الثغرة المستغلة في v8 ستؤدي إلى تنفيذ كود، لن نتمكن من تنفيذ أي كود بسبب صندوق الحماية (sandbox)، وبالتالي سنحصل على تنفيذ كود في سياق العارض (renderer)، وهو ما لن يسمح لنا بتنفيذ كود على الجهاز. لهذا سنحتاج إلى استغلال آخر لصندوق الحماية، وبالتالي سنحتاج إلى سلسلة كاملة لاستغلال النظام.

وبالتالي نحدد الأهداف التالية لنكون قادرين على البدء في اختراق المتصفحات:

• تعلّم، ورسم خريطة، وإتقان البنى الداخلية المستخدمة بواسطة محرك V8 والنقاط الرئيسية في بنية كروم
• تعلّم وإتقان الإجراءات الأساسية اللازمة لاستغلال المتصفحات

تعلّم، ورسم خريطة، وإتقان البنى الداخلية المستخدمة بواسطة محرك V8 والنقاط الرئيسية في بنية كروم

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

• بنية V8
• بنية Chromium
• بنية Blink

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

ترتيبها وأسماؤها كما يلي:

أول عملية تسمى content process. ماذا تفعل هذه العملية؟

• تُعرف بأنها عملية بدء التشغيل.
• وهي أيضاً العملية الرئيسية.
• وهي المسؤولة عن بدء العملية الرئيسية الفعلية التي تسمى browser process.

الآن بعد أن عرفنا باختصار ماذا تفعل، حان الوقت للتعمق أكثر:

• إذن الطريقة التي يعمل بها Chromium على ويندوز على الأقل، هي أنه يترجم الملفات إلى dll، وبعد ذلك يقوم بتحميلها في الذاكرة. لذا فإن المنطق الأساسي لمتصفح Chromium موجود في chromium.dll.
  هذا مؤكد أيضاً بالكود
  .
  هذا مأخوذ من chrome_exe_main_win.cc وإذا كنت فضولياً لقراءة الكود كاملاً فهو موجود في chromium/src/chrome/app. حسناً، بالمتابعة في التنفيذ نرى أنه يستدعي MakeMainDllLoader() لاستدعاء فئة تحميل الـ dll، بعد ذلك يشغّل "اللودر" أي يقوم بتحميل chrome.dll، وإذا كان ضرورياً يعيد تشغيله مع أسطر الأوامر اللازمة. لتحليل الـ Loader بشكل أعمق، نحتاج إلى فهم كوده، الموجود في نفس الدليل، في الملف mail_dll_loader_win.cc. عند التمرير حتى نهاية الملف، نرى الاستدعاء إلى MakeMainDllLoader الذي يقوم بدوره باستدعاء ChromeDllLoader أو ChromiumDllLoader بناءً على الإصدار الذي لديك.
  
  يمكننا أن نرى أن ChromiumDllLoader هو فئة ترث من MainDllLoader. نرى من التعريف أن ما تفعله هذه الفئة ببساطة هو تحميل الـ dll بناءً على الوسائط الممررة إلى سطر الأوامر ونوع العملية
  .
  من خلال تحليل طريقة Launch يمكننا فهم بعض الأشياء التي تحدث قبل بدء تشغيل chrome.dll: يمكننا أن نفهم من هذا التعليق أن "// Launching is a matter of loading the right dll and calling the entry point. // Derived classes can add custom code in the OnBeforeLaunch callback." أن إطلاق chrome هو مسألة تحميل مجموعة من ملفات الـ dll التي تقوم بالعمل الفعلي. ثانياً، يأخذ الوسائط الممررة إلى سطر الأوامر ويقوم أيضاً بتهيئة خدمات صندوق الحماية.
  .
  أولاً يتحقق مما إذا كان المتصفح هو من يستدعي تهيئة صندوق الحماية، ثم يتحقق مما إذا كانت العملية التي استدعت تهيئة صندوق الحماية قد استُدعيت كخدمة طباعة سحابية. كما يتحقق مما إذا كان --no-sandbox قد مُرر إلى الملف التنفيذي، وهو ما يخبر الملف التنفيذي أساساً بعدم العمل داخل صندوق حماية. يتحقق مما إذا كان أي من هذه الخيارات مضبوطاً، وإذا كان أي منها صحيحاً، يستدعي صندوق الحماية مع الخيارات المعنية. ثم في النهاية نصل إلى
  
  وهو ما نهتم به، وهذا يمثل الغلاف لاستدعاء chrome_main.