j00sean/cve-2022-44666شرح فني وإثبات مفهوم لثغرة CVE-2022-44666، وهي ثغرة تهريب سمة href في عنصر تحكم syslink في جهات اتصال Windows، مما يتيح تنفيذ التعليمات البرمجية عن بُعد عبر ملفات VCF/.contact مصمَّمة خصيصًا ومعالج بروتوكول LDAP.
هذه قصة عن 0day أخرى منسية تم الكشف عنها بالكامل منذ أكثر من 4 سنوات بواسطة [John Page (aka hyp3rlinx)][R.1]. لفهم التقرير، عليك أن تضع في اعتبارك أنني غبي :-) وغبائي يدفعني لاتخاذ مسارات أطول لحل مشكلات بسيطة، لكنه أيضًا يقودني لاستكشاف طرق أخرى لاستغلال بعض الثغرات. لماذا أقول هذا؟ لأنني لم أتمكن من فهم بسرعة أن طريقة إنشاء ملف .contact هي ببساطة الانتقال إلى مجلد جهات الاتصال لإنشاء جهة الاتصال، وبدلاً من ذلك، استخدمت هذه المعلومات لإنشاء ملف VCF أولاً، ثم ظننت خطأً أن هذا نوع من المتغيرات. كان ذلك أيضًا لأن عقلي لا يستطيع فهم أن بعض 0days تُنسى لفترة طويلة ¯\(ツ)/¯ بعد القيام بذلك وبعد ردود 'لن يتم الإصلاح' من [MSRC][R.2] و [ZDI][R.3]، تم إجراء مزيد من التحقيقات لزيادة درجة الخطورة، وصولًا أخيرًا إلى ملفات .contact ومعالج بروتوكول url 'ldap' في ويندوز.
بينما كنت أقرأ كود الاستغلال لـ [هذه الثغرة][R.4] والتي تم إصدارها بالفعل كـ 0day ومن الممكن العثور على [تقرير ZDI][R.5].
تحديث 2022/07/21: بعد الإبلاغ عن هذه الحالة إلى MS، أشار إليّ فريق MSRC بحق أن جهات اتصال ويندوز ليس البرنامج الافتراضي لفتح ملفات VCF.
لا يزال البحث الإضافي يظهر أن البرنامج الافتراضي لملفات VCF على Win7 ESU و WinServer2019 هو جهات اتصال ويندوز (wab.exe)، وإلا يتم استخدام MS People (PeopleApp.exe). فيما يلي جدول كامل لهذا الاختبار:
على أي حال، لا يزالون يجادلون بأن هناك بعض الهندسة الاجتماعية متضمنة مثل فتح ملف VCF مصمم خصيصًا والنقر على بعض الروابط لاستغلال الثغرة، لذلك لا يفي بمعايير MSRC لتحديث أمني.
تحديث 2022/07/25: حسنًا، بعد مزيد من البحث، إنها نفس الثغرة. لقد تمكنت أخيرًا من العثور على إثبات مفهوم لملف .contact. من الممكن بالفعل تحليل ملف .contact بشكل صحيح باستخدام كيانات HTML. لاحظ أن هذا يحل المشكلة السابقة (تحديث 2022/07/21) ويتم فتح تنسيق الملف هذا (.contact) بواسطة جهات اتصال ويندوز، البرنامج الافتراضي لهذا الامتداد، حتى عند تثبيت MS أوفيس في النظام. كل ما يحتاجه هو ارتباط ملف أولي إذا لم يتم بعد، لكن البرنامج الوحيد المثبت افتراضيًا للقيام بذلك هو جهات اتصال ويندوز.
تحديث 2022/07/25: قادني هذا البحث الإضافي إلى نقطة كنت أحاول الوصول إليها منذ فترة: استخدام معالج بروتوكول url لفتح بيانات اتصال مصممة خصيصًا لاستغلال الثغرة. تمكنت أخيرًا من جعلها تعمل بفضل مخطط ldap uri، والذي يرتبط افتراضيًا بتطبيق جهات اتصال ويندوز، لذلك بمجرد إعداد خادم LDAP ضار وتقديم بيانات الحمولة تحت سمات mail أو url أو wwwhomepage، يزداد تأثير الاستغلال لأنه الآن ليس من الضروري النقر المزدوج على ملف VCF/Contact ضار، بل يمكننا توصيل ذلك باستخدام بروتوكولات url.
تحديث 2023/02/08: كبادرة حسن نية من MSRC، تم إدراج [John Page (aka hyp3rlinx)][R.1] في صفحة الشكر لاكتشاف [CVE-2022-44666][R.10].
التقرير هو في الأساس نفس الروابط أعلاه، لكنني قمت بتحسين الهندسة الاجتماعية المتضمنة قليلاً. في الواقع، أول شيء قمت به هو تحسين طريقة رؤية الروابط، كما لو كانت ثغرة XSS، إنها في الواقع حقن HTML لذا من الممكن إغلاق عنصر الرابط الأول وإدراج رابط جديد. ثم أردت إخفاء رؤية عناصر HTML تلك، لذا مجرد تعيين 'innerHTML' طويل بقدر الإمكان سيكون كافيًا لإخفائها (بسبب وجود حدود للأحرف).
هذه هي الحمولة النهائية المستخدمة:```html URL;WORK:">CLICKMEEEEE...
لمشاهدة ما يحدث، قم بتشغيل procmon وإعداد هدف وهمي لخاصية href مثل هذا:```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/foo.exe">CLICKMEEEEE...</a>
بمجرد النقر على الرابط، يُلاحظ إخراج كهذا في برنامج procmon:
