الصورة: Unsplashكما هو موضح في
مقال سابق حول
CVE-2019-0726 ، يؤدي البحث عن تفاصيل حول ثغرة أمنية معروفة بالفعل إلى اكتشاف ثغرة أمنية جديدة. وفي بعض الحالات ، هناك أكثر من نقطة ضعف جديدة.
نظرت المقالة إلى دالتين من مكتبة dhcpcore.dll: UpdateDomainSearchOption المذكورة بشكل عرضي وتحليل أكثر تفصيلاً لـ DecodeDomainSearchListData الذي تستدعيه. كما يحدث دائمًا عند البحث عن الثغرات الأمنية ، حتى إذا كانت الاستنتاجات المهمة في النهاية تنخفض إلى وظيفة واحدة أو وظيفتين ، في عملية التحليل يجب أن تنظر إلى مقدار أكبر من الشفرة. وفي بعض الأحيان تتشبث العين بالفتات التي لا تتعلق بالمهمة الحالية ، ولكن قد تكون لها أهمية مستقلة أو تكون مفيدة في وقت لاحق. لنفترض أنه في الوقت الحالي لا يوجد وقت للالتفات إليهم ، ولكن هذه التافتات قد تم تأجيلها في القشرة الفرعية ، وإذا كانت هناك فرصة للعودة إليها والتحقق من تخميناتهم ، فإنها تظهر مرة أخرى في وعيهم.
وهذا ما حدث هذه المرة. عند دراسة وظيفة DhcpExtractFullOptions ، المسؤولة عن معالجة جميع الخيارات المحددة في استجابة DHCP من الخادم ، على وجه الخصوص ، استدعاء UpdateDomainSearchOption ، هناك صفيفتان في مجموعة مكونة من 256 عنصرًا يجذب كل منهما الانتباه على الفور:
في هذه الحالة ، لا يمكن ملاحظة وجود أي عمليات تحقق تقيد قيم التكرارات من هذه المصفوفات. نظرًا لأننا في تلك اللحظة كنا نحلل ثغرة أخرى ، فإن هذه المعلومات لم تكن ذات صلة. لذلك ، يبقى فقط تذكر هذا المكان في الكود من أجل العودة إليه لاحقًا.
تحليل
يمر أسبوعان ، ونتذكر مرة أخرى الدالة DhcpExtractFullOptions التي جذبت الانتباه في وقت سابق. ننتقل إلى الأمر في المفكك ، ونمشط الأجزاء البرمجية غير المكتملة سابقًا في الكود ونحاول أن نفهم ما هي المصفوفات الثابتة التي أثارت اهتمامنا.
في بداية تنفيذ الوظيفة ، تكون الصفائف ومكرراتها صفراً:
تقوم الوظيفة بتوزيع كل الخيارات الموجودة في الحزمة المستلمة من خادم DHCP ، وتقوم بجمع المعلومات منها ثم معالجتها. بالإضافة إلى ذلك ، وفقًا لنتائج التحليل ، تكتب أيضًا الحدث المقابل لخدمة ETW (تتبع الأحداث لـ Windows). في حالة تسجيل الدخول ، تشارك المخازن المؤقتة التي تهمنا. جنبا إلى جنب مع الكثير من البيانات الأخرى ، يتم نقلها إلى إجراء EtwEventWriteTransfer. عمل إعداد جميع البيانات للتسجيل ضخم جدًا ولا يهم كثيرًا لضعف المعلومات التي ندرسها ، حتى نتمكن من الاستغناء عن الرسوم التوضيحية.
من المهم تحديد كيفية تعبئة هذه المخازن المؤقتة. تعبئة يحدث في خيارات تحليل حلقة. أولاً ، يتم استدعاء وظيفة تحمل الاسم الناطق ParseDhcpv4Option للخيار الحالي الذي تم استلامه للمعالجة ، والذي إما يملأ حقول كائن dhcp_pointers بناءً على البيانات المستلمة ، أو يدون ملاحظة حول خيار غير مألوف عند مواجهته لمعرّف خيار مع عدم وجود معالج له.
عند العودة من ParseDhcpv4Option ، تتم كتابة قيمة معرف الخيار option_tag الحالي إلى العنصر التالي في مجموعة all_tags ، وهي أول صفائف تهمنا. إذا حققت الدالة خيارًا غير معروف ، وبناءً عليه ، لم تقم بتعيين إشارة is_known_option ، فإن قيمة المعرف تتم كتابتها أيضًا إلى العنصر التالي للصفيف الثاني - unknown_tags. بطبيعة الحال ، تم بالفعل الحصول على أسماء ذات معنى للمتغيرات في هذه المقالة عن طريق تحليل التعليمات البرمجية.
وبالتالي ، يخزن صفيف all_tags علامات جميع الخيارات من الرسالة المستلمة ، ويخزن صفيف unknown_tags العلامات فقط للخيارات غير المألوفة للمحلل اللغوي. في الوقت نفسه ، فإن التحقق من قيم مؤشرات هذه المصفوفات غائب تمامًا. وبالتالي ، يمكن أن تتجاوز قيم هذه الفهارس 256 وتؤدي إلى الكتابة بما يتجاوز الحدود المخصصة على مكدس صفائف الذاكرة. لتعبئة المصفوفة الأولى ، يكفي إرسال حزمة تحتوي على عدد من الخيارات يتجاوز 256 من خادم DHCP ، وينطبق الشيء نفسه على المصفوفة الثانية مع الاختلاف الوحيد وهو أنه يجب إرسال الخيارات التي يتعذر على العميل معالجتها.
استغلال
دعونا الآن نحاول استخدام مثال عملي للتأكد من صحة استنتاجاتنا. بادئ ذي بدء ، نولي الاهتمام لحقيقة أن علامات الخيار تشغل بايت واحد ، في حين أن عناصر الصفيف من النوع int ، أي أنها أربعة بايت. وبالتالي ، لدينا تجاوز سعة نحكم فيه كل بايت رابع ، ويتم إعادة تعيين الباقي إلى صفر عند الكتابة.
للتحقق من افتراضنا ، فإن أسهل طريقة هي الكتابة فوق ملف تعريف الارتباط الأمني على الوظيفة المعنية ، والتي ستلقي استثناءًا يتعلق بالتحقق الأمني. دعنا نحاكي موقفًا يرسل فيه خادم DHCP عددًا كافيًا من الخيارات لإعادة الكتابة. فليكن 0x1a0 (416) خيارات مع معرف 0xaa وحجم صفر. وبالتالي ، يشغل كل خيار وحدتي بايت ، ويبلغ إجمالي حجم الحزمة مع كل الرؤوس 1100-1200 بايت. تقع هذه القيمة ضمن
وحدة الإرسال الكبرى للإيثرنت ، وبالتالي ، هناك سبب للاعتقاد بأن الرسالة لن تكون مجزأة ، مما سيتيح لنا تجنب الآثار الضارة المحتملة.
نرسل الحزمة المشكلة بالطريقة الموصوفة استجابةً لطلب من عميل DHCP ونلاحظ الاستثناء في عملية ملف Svchost.exe المقابلة على جهاز العميل:
كما ترون من تتبع المكدس ، تمت إعادة كتابة ملف تعريف ارتباط المكدس وعنوان المرسل من الوظيفة بواسطة معرفات الخيارات من الحزمة الخاصة بنا.
بالطبع ، سيتطلب إنشاء استغلال عمل لهذا الخطأ الكثير من الجهد من المهاجم. في الأنظمة الحديثة ، يعد تجاوز سعة المخزن المؤقت على المكدس مشكلة عدم حصانة معقدة وكثيفة العمالة بسبب كل آليات الدفاع الحالية. من ناحية أخرى ، يجب ألا ينسى المرء أن كل هذه الآليات إما تحمي من الكتابة فوق عنوان المرسل ومعالجات الاستثناء ، أو تحظر تنفيذ التعليمات البرمجية في مناطق الذاكرة غير المخصصة لهذا الغرض ، أو تتداخل مع التنبؤ بالعنوان. على سبيل المثال ، لا يمكنهم المساعدة بأي طريقة ضد الكتابة فوق تلك المخزنة على المكدس بين المخزن المؤقت الفائض وعنوان إرجاع المتغيرات المحلية. وتحتوي الدالة DhcpExtractFullOptions المعنية على العديد من المتغيرات الخطيرة المحتملة في هذا الفاصل الزمني.
مرة أخرى ، نكتب إلى Microsoft حول الخطأ الذي تم اكتشافه. بعد مراسلات قصيرة وتحليل للتطبيق ، والذي استغرق حوالي أسبوع ، نحصل على إجابة تفيد بأنه يتم إعداد معرف CVE للثغرة الأمنية الموضحة ، ومن المقرر إصدار إصلاح في مارس ، وتم الإبلاغ عن معلومات حول الثغرة الأمنية بالفعل في Microsoft ، من قبل شخص سابق. والحقيقة ، عمومًا ، ليست مفاجئة ، لأن الخطأ يقع حرفيًا على السطح ، كما أن المخازن المؤقتة التي لا تحتوي على اختبارات حدودية للمؤشرات تجذب دائمًا الانتباه أولاً ، ويمكن اكتشافها غالبًا بواسطة أدوات التحليل التلقائي.
في مارس ، كما تم الإعلان ، تم إصدار تحديث لتصحيح الخطأ الموصوف ، والذي تلقى المعرف
CVE-2019-0697 . تبين أن الباحث الذي تم الإبلاغ عنه سابقًا هو Mitch Adair ، وهو نفس موظف Microsoft الذي اكتشف مشكلة عدم حصانة DHCP
CVE-2019-0547 التي تم إصلاحها في يناير.
كتب بواسطة ميخائيل تسفيتكوف ، أخصائي تحليل تطبيق التقنيات الإيجابية.