Einführung
Am 4. Mai 2022 veröffentlichte F5 einen Sicherheitshinweis, der eine Schwachstelle im iControl REST-System von BIG-IP beschreibt, die es einem Angreifer ermöglichen könnte, die Authentifizierung der Software zu umgehen und beliebige Befehle auszuführen. Diese Sicherheitslücke wurde vom NIST als CVE-2022-1388 eingestuft.
Die anfälligen Versionen dieses Geräts sind wie folgt (und können im Dateisystem des Geräts in "/etc/f5-release" gefunden werden)
- 16.1.0 - 16.1.2
- 15.1.0 - 15.1.5
- 14.1.0 - 14.1.4
- 13.1.0 - 13.1.4
- 12.1.0 - 12.1.6
- 11.6.1 - 11.6.5
These potentially vulnerable devices can be found using a simple Censys search query: (services.http.response.html_title: “BIG-IP®- Redirect”) or services.http.response.html_tags=`<meta name=”description” content=”F5 Networks Configuration Utility.”>`
Zum Zeitpunkt der Erstellung dieses Berichts gab es in der Datenbank Censys etwas mehr als 3.000 Dienste und etwas mehr als 2.500 Hosts/virtuelle Hosts, die diesem Fingerabdruck entsprechen. Die meisten dieser Hosts befinden sich in Asien (38,8 % der Gesamtzahl), während Europa mit über 30 % der Gesamtzahl knapp dahinter liegt.
Es wurde auch berichtet, dass diese Sicherheitslücke aktiv ausgenutzt wird, daher sollten Administratoren ihre Anlagen überprüfen und sofort aktualisieren.
Technische Zusammenfassung
Auf dem BIG-IP-Server laufen mehrere HTTP-Server: Ein Apache-Server für Frontend-Operationen (der an einer öffentlichen Schnittstelle lauscht) und mehrere interne Backend-Webserver, einschließlich eines Jetty-Servers für die iControl REST API. Während die Backend-Dienste nicht öffentlich zugänglich sind, sind mehrere URI-Pfade auf dem Frontend-Server offengelegt, die intern vom Apache-Frontend-Server mit mod_proxy vermittelt werden.
Wenn sich ein Benutzer am Apache-Frontend-Server authentifiziert, wird ein benutzerdefiniertes Apache-Modul namens mod_auth_pam verwendet, um die eingehenden Anmeldeinformationen zu überprüfen. Wenn der Client jedoch einen Header mit dem Namen "X-F5-Auth-Token" enthält, wird die Überprüfung der Anmeldeinformationen auf den Dienst verschoben, der die Anfrage bearbeitet, und es wird davon ausgegangen, dass der nachgeschaltete Dienst das Richtige tut (und ungültige X-F5-Auth-Token-Werte zurückweist).
Der iControl-Backend-Dienst weist jedoch ein recht interessantes logisches Versehen auf. Wenn eine Anfrage über localhost direkt an den Dienst gesendet wird und das "X-F5-Auth-Token" nicht vorhanden ist, wird die Anfrage ohne Validierung zugelassen, solange ein gültiger Benutzername im Autorisierungsabschnitt der Anfrage gefunden wird. Die Idee dahinter (so vermuten wir) ist, dass jede lokale Anfrage von Natur aus vertrauenswürdig sein sollte, da es für einen externen Client keine Möglichkeit gab, den X-F5-Auth-Token-Header auszuschließen (und keine Anmeldedaten einzuschließen), ohne am Frontend über mod_auth_pam abgelehnt zu werden.
Aber was wäre, wenn es einen Weg gäbe, mod_proxy auszutricksen, um das "X-F5-Auth-Token" zu entfernen, bevor die Anfrage an den lokalen Backend-Dienst gesendet wird? Schauen wir uns die HTTP/1.1-Spezifikation, RFC7230, unter Abschnitt 6.1 an, um einen Hinweis zu erhalten:
Diese Aussage bedeutet, dass alle nicht standardmäßigen Token-Werte (close/keep-alive usw.), die in diesem Header gefunden werden, als zu entfernende Header behandelt werden, wenn sie als Proxy fungieren. Wenn also beispielsweise der "Connection"-Header eines Clients den Wert "close,X-F5-Auth-Token" enthält, entfernt ein RFC-konformer Proxy-Server (wie Apache mod_proxy) den X-F5-Auth-Token-Header aus der Anfrage, bevor er sie an das Backend sendet. Und genau auf diese Weise kann ein Angreifer die ursprünglichen Annahmen des Backend-Dienstes aushebeln.
Eine einfache Anfrage für einen Schwachstellentest kann mit dem folgenden curl-Befehl an jeden BIG-IP-Dienst gerichtet werden:
