AutoGenerateXalanPayload

مقدمة

هذه أداة توليد تلقائي للـ payload مستندة إلى ثغرة cve-2022-34169، وتستهدف ثغرة الفائض في xalan الخاص بـ JDK. نظرًا لأن إصدارات JDK المختلفة تتطلب payloads فائض مختلفة، فقد ظهرت هذه الأداة للتوليد التلقائي؛ يكفي تشغيل هذا المشروع بإصدارات مختلفة من JDK لتوليد ملفات xslt استغلالية مختلفة.

تعليمات الاستخدام

انسخ select.bak.xslt إلى select.xslt، وعدّل الأمر الذي تريد تنفيذه

ثم شغّل java -jar AutoGenerateXalanPayload.jar. ستُطرح بعض الأخطاء أثناء العملية، ويمكن تجاهلها. بعد اكتمال تشغيل البرنامج، سيكون select.xslt الناتج هو الـ payload المناسب لتنفيذ أمر الفائض في xalan وفقًا لإصدار JDK هذا.

فكرة التعديل

https://mp.weixin.qq.com/s/xxAtjFvk9RxWiY-pwGf8Ow

مقارنة إصدارات JDK

نظرًا لتعدد الإصدارات الفرعية لـ JDK، استخدمت أسلوب التنصيف لمقارنة إصدارات jdk1.6 إلى jdk1.8. لنأخذ اختبار إصدار 1.7 كمثال: أختبر أولًا أعلى إصدار فرعي من jdk1.7 وأحصل على xslt، وأفترض أن محتوى هذا الـ xslt من النوع A. ثم أختبر أدنى إصدار فرعي من jdk1.7 وأحصل على xslt. إذا كان هذا الـ xslt مطابقًا تمامًا لما يولده أعلى إصدار فرعي من 1.7، فهذا يعني أن جميع الإصدارات من الأدنى إلى الأعلى في jdk1.7 تشترك في payload واحد من النوع A. أما إذا لم يتطابق، فآخذ الإصدار الوسيط من jdk1.7 وأختبره، وهكذا أواصل التنصيف. هذه أسرع طريقة اختبار توصلت إليها، فهي لا تتطلب تثبيت جميع الإصدارات واختبارها مع تغطيتها جميعًا. إليك مثالًا من النتائج المختبرة أدناه: Jdk-8u301 هو payload من النوع A، وJdk-8u202 هو payload من النوع A، إذن Jdk-8u221 هو الإصدار الوسيط بينهما، أليس من غير المعقول أن يكون payload من النوع B؟

فيما يلي النتائج التي توصلت إليها من الاختبارات، والتي تُظهر وجود ستة أنواع من الـ payload بين jdk1.6 وjdk1.8.

المراجع

https://blog.noah.360.net/xalan-j-integer-truncation-reproduce-cve-2022-34169/