أصدر باحثون من Chaitin Tech في الصين معلومات حول اكتشاف جديد ، كما حددوا ثغرة أمنية في حاوية servlet الشهيرة (Java Servlet و JavaServer Pages و Java Expression Language و Java WebSocket) اباتشي تومكاt (مدرج بالفعل كـ CVE-2020-1938).
هذا الضعف تم تخصيص الاسم الرمزي لها "Ghostcat" ومستوى الخطورة الحرج (9.8 CVSS). المشكلة يسمح في التكوين الافتراضي بإرسال طلب عبر منفذ الشبكة 8009 لقراءة محتوى أي ملف في دليل تطبيق الويب، بما في ذلك رموز مصدر التطبيق وملفات التكوين.
تسمح الثغرة الأمنية أيضًا باستيراد ملفات أخرى إلى رمز التطبيقالذي يسمح تنظيم تنفيذ التعليمات البرمجية على الخادم إذا كان التطبيق يسمح بتحميل الملفات على الخادم.
على سبيل المثال، ما إذا كان تطبيق موقع الويب يسمح للمستخدمين بتحميل الملفات, يمكن للمهاجم أن يشحن الأول ملف يحتوي على كود البرنامج النصي JSP ضار على الخادم (الملف الذي تم تحميله نفسه يمكن أن يكون أي نوع من الملفات ، مثل الصور وملفات النص العادي وما إلى ذلك) ثم قم بتضمين الملف الذي تم تحميله من خلال استغلال الثغرة الأمنية من Ghostcat ، مما قد يؤدي في النهاية إلى تنفيذ التعليمات البرمجية عن بُعد.
يُذكر أيضًا أنه يمكن تنفيذ هجوم إذا كان من الممكن إرسال طلب إلى منفذ شبكة باستخدام برنامج تشغيل AJP. حسب المعطيات الاوليةوجدت الشبكة يقبل أكثر من 1.2 مليون مضيف الطلبات باستخدام بروتوكول AJP.
الثغرة الأمنية موجودة في بروتوكول AJP وليس بسبب خطأ في التنفيذ.
بالإضافة إلى قبول اتصالات HTTP (المنفذ 8080) في Apache Tomcat افتراضيًا من الممكن الوصول إليها إلى تطبيق الويب باستخدام بروتوكول AJP (بروتوكول Apache Jserv ، المنفذ 8009) ، وهو نظير ثنائي لـ HTTP مُحسَّن لأداء أعلى ، يُستخدم بشكل عام عند إنشاء مجموعة من خوادم Tomcat أو لتسريع التفاعل مع Tomcat على وكيل عكسي أو موازن تحميل.
يوفر AJP وظيفة قياسية للوصول إلى الملفات الموجودة على الخادموالتي يمكن استخدامها بما في ذلك استلام الملفات التي لا تخضع للكشف.
ومن المفهوم أن الوصول إلى برنامج AJP مفتوح فقط للخدم المؤتمنينولكن في الواقع ، في تكوين Tomcat الافتراضي ، تم تشغيل برنامج التشغيل على جميع واجهات الشبكة وتم قبول الطلبات بدون مصادقة.
يمكن الوصول إلى أي ملف في تطبيق الويب ، بما في ذلك محتويات WEB-INF و META-INF وأي دليل آخر يتم إرجاعه من خلال استدعاء ServletContext.getResourceAsStream (). يتيح لك AJP أيضًا استخدام أي ملف في الدلائل المتاحة لتطبيق ويب كنص JSP.
كانت المشكلة واضحة منذ إطلاق فرع Tomcat 6.x قبل 13 عامًا. بالإضافة إلى Tomcat نفسه ، تؤثر المشكلة أيضًا على المنتجات التي تستخدمها، مثل Red Hat JBoss Web Server (JWS) و JBoss Enterprise Application Platform (EAP) بالإضافة إلى تطبيقات الويب المستقلة التي تستخدم Spring Boot.
أيضا تم العثور على ثغرة أمنية مماثلة (CVE-2020-1745) على خادم الويب Undertow المستخدمة في خادم تطبيق Wildfly. حاليًا ، أعدت مجموعات مختلفة أكثر من اثني عشر نموذجًا عمليًا لبرمجيات إكسبلويت.
أصدرت Apache Tomcat رسميًا الإصدارات 9.0.31 و 8.5.51 و 7.0.100 لتصحيح هذه الثغرة الأمنية. لتصحيح هذه الثغرة الأمنية بشكل صحيح، يجب عليك أولاً تحديد ما إذا كانت خدمة Tomcat AJP Connector مستخدمة في بيئة الخادم لديك:
- إذا لم يتم استخدام الكتلة أو الوكيل العكسي ، يمكنك تحديد أن AJP لا يتم استخدامه.
- إذا لم يكن الأمر كذلك ، فأنت بحاجة إلى معرفة ما إذا كانت المجموعة أو الخادم العكسي تتواصل مع خدمة Tomcat AJP Connect
كما يذكر أن التحديثات متاحة الآن في توزيعات Linux المختلفة مثل: Debian و Ubuntu و RHEL و Fedora و SUSE.
كحل بديل ، يمكنك تعطيل خدمة Tomcat AJP Connector (ربط مأخذ الاستماع بالمضيف المحلي أو التعليق على السطر باستخدام منفذ الموصل = »8009 ″) ، إذا لم يكن ذلك مطلوبًا ، أو تكوين الوصول المصدق.
إذا كنت تريد معرفة المزيد عنها ، يمكنك الرجوع إليها الرابط التالي.