Weblogic-CVE-2020-2551-To-Internet

CVE-2020-2551 POC للاستخدام على الإنترنت

• اختبار POC (يمكن استخدامه في الاختبارات الخارجية)

  python CVE-2020-2551.py [HOST] [IP]

• محاولة تعديل codebase لتحميل الفئات عن بُعد (فشل)

  python CVE-2020-TEST.py [HOST] [IP]

نظرة عامة على ثغرة CVE-2020-2551 في WebLogic وبناء POC للإنترنت

(نُشر لأول مرة على Anquanke، الرابط الأصلي)

0x00 مفاهيم أساسية

تتطلب دراسة هذه الثغرة بعض المعرفة المسبقة، مثل CORBA و RMI.

باختصار:

CORBA هي مجموعة من المعايير التقنية التي وضعتها OMG للتطبيقات الموزعة، وتستخدم IDL لدعم متعدد اللغات، وتتواصل بين العميل والخادم باستخدام بروتوكول IIOP.

RMI هي تقنية تطبيقات موزعة أخرى، ويمكن استخدام JNDI لتبسيط التطبيق في JAVA، حيث يتواصل العميل مع الخادم باستخدام بروتوكول JRMP، ولكن في weblogic يستخدم RMI بروتوكول T3، وقد تم كشف العديد من الثغرات حول هذا سابقًا.

يجمع RMI-IIOP بين مزايا كل من RMI و CORBA، وينشر تطبيقات RMI عبر بروتوكول IIOP.

وقد ذكرت الوثائق الرسمية أيضًا:

يمكن لكائنات خادم RMI استخدام بروتوكول IIOP والتواصل مع كائنات عميل CORBA المكتوبة بأي لغة.

0x01 RMI-IIOP

بدون ذكر weblogic حاليًا، لننظر أولاً في كيفية كتابة مثال RMI-IIOP:

يمكن الرجوع إلى كود العميل في مقال Java 中 RMI、JNDI、LDAP、JRMP、JMX、JMS那些事儿（上） و مشروع الاختبار ، يمكنك تجميع HelloClient و HelloServer بنفسك، أو استخدام الملفات المترجمة مسبقًا في مشروع الاختبار.

قم بتشغيل خادم الأسماء من سطر الأوامر (مرفق مع Java):

start orbd -ORBInitialPort 1050

قم بتشغيل خادم HelloServer من سطر الأوامر مع تفعيل التصحيح عن بُعد. لمزيد من المعلومات حول كيفية إجراء التصحيح عن بُعد باستخدام IDEA، راجع الطريقة المذكورة في بداية هذه المقالة.

java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005 HelloServer

بالطبع، يمكنك أيضًا تشغيله بدون تصحيح عن بُعد ورؤية النتيجة مباشرةً، فقط قم بالتشغيل:

java HelloServer

قم بتشغيل العميل من سطر الأوامر:

Java HelloClient

عندها ستظهر الآلة الحاسبة. إذا نجح التصحيح عن بُعد، يمكنك رؤية مكدس الاستدعاءات التالي:

تنفيذ الأمر في EvilMessage.readObejct()

ملاحظة جانبية: مقالات حول تثبيت و تصحيح أخطاء WebLogic.

فماذا عن RMI-IIOP في weblogic؟ مقال حول RMI-IIOP في Java يذكر استخدام RMI-IIOP في weblogic، تم إجراء بعض الأبحاث بناءً عليه. يشرح استخدام RMI عبر IIOP في WebLogic عدة طرق لاستخدام عميل RMI-IIOP في Weblogic، بما في ذلك:

1. عميل RMI مستقل (باستخدام JNDI، بدون استخدام أي شيء من weblogic)
2. عميل WebLogic
3. عملاء J2EE
4. عملاء CORBA/IDL

يبدو أن الفرق بين الطريقتين الأوليين هو فقط في إعداد JNDI_FACTORY.

عند دراسة إلغاء تسلسل T3 في weblogic سابقًا، قمت بنشر تطبيق Helloserver على weblogic، والذي يحتوي على طريقة sayhello() يمكن استغلالها. حاولت تعيين نوعي JNDI_FACTORY واستدعاءها، ونجحت الطريقة الثانية في استدعاء sayHello().

ثم قمت بتعديل POC لبروتوكول T3 في weblogic، في الواقع قمت فقط بتغيير RMI إلى IIOP، ووجدت أن سلسلة استغلال jtaTransactionManager قد نفذت بنجاح، وأرسل طلب jrmp إلى jrmplisten المحلي.

لننظر إلى حركة المرور، عند استدعاء طريقة remove()، يتم إرسال طلب remove__java_lang_Object، وتحتوي حركة المرور على بيانات ضارة، ولكن لم يتم العثور على التوقيع aced.

أفترض أنه بعد تحليل خاص من جانب الخادم، يتم إلغاء تسلسل البيانات. بالنظر إلى مكدس الاستدعاءات، يمكن رؤية أن الجزء الثاني من سلسلة التنفيذ مشابه جدًا لسلسلة تنفيذ RMI-IIOP الأصلية. الجزء السابق يبدأ من CDRInputStream.read_value()، وهنا يبدأ من weblogic.InputStream.read_value()، (نقطة read_value تم ذكرها أيضًا في عرض عام 2019).

هنا، سيتم التعامل مع الطلب أولاً بواسطة clusterableServerRef.invoke()، وبناءً على invoker مختلف يتم استدعاء this.invoker.invoke()، ثم يتم استدعاء Mejb_dj5nps_HomeImpl_WLSkel.invoke()، وبما أنه "remove"، يتم الدخول إلى الفرع case 6 واستدعاء IIOPInputStream.readObject()، في طريقة read_value() يتم تحليل بيانات IIOPInputStream ويتم تشغيل إلغاء التسلسل. هذا هو POC باستخدام طريقة remove().

0x02 CVE-2020-2551

ذكر تحليل الأخ Lucifaer في مقالته استخدام طريقة bind() للاستغلال، وهي أيضًا طريقة الاستغلال السائدة على الإنترنت. دعنا نتابع مكدس الاستدعاءات.

كما في السابق، سيتم التعامل مع الطلب أولاً بواسطة clusterableServerRef.invoke()، وبناءً على invoker مختلف يتم استدعاء this.invoker.invoke()، هنا يتم استدعاء CobraServerRef.invoke()، ثم في _NamingContextAnyImplBase._invoke()، نظرًا لأن va1 هو "bind_any"، يتم الدخول إلى الفرع case 0 واستدعاء IIOPInputStream.read_any()، والتي ستستدعي في النهاية IIOPInputStream.read_value() لتشغيل إلغاء التسلسل. ذكرت سابقًا أنه لم يتم رؤية التوقيع aced في حركة المرور، وذلك لأن هناك طريقة تحليل خاصة في IIOPInputStream. شكل hex-value لـ IIOPInputStream كالتالي، والذي يحتوي على اسم الفئة ومعلومات الحقول:

في النهاية، سيتم استدعاء طريقة readObejct() الخاصة بالفئة الضارة.

بالنظر إلى التصحيح، وجدت أنه في نفس الموقع مثل تصحيح استغلال إلغاء تسلسل T3 لعام 2015.

في اختبار تحليل ثغرة CVE-2020-2551 في WebLogic، نرى أن موقع تصفية فئات CVE-2020-2551 أيضًا في فئة weblogic.iiop.Utils.