Schwachstellenbehebung in Apache: Server-Side Request Forgery verhindern (CVE-2021-40438)
Was Sie unbedingt wissen sollten:
Diese Schwachstelle im Apache HTTP Server (httpd) Version 2.4.48 kann zu Server-Side Request Forgery führen und per Remote-Zugriff ausgenutzt werden, wenn ein bestimmtes Modul (mod_proxy) aktiviert ist.
In Version 2.4.51 gibt es bereits einen Patch; in der Cloud gehostete Apache HTTP Serverinstanzen sind – sofern sie relativ aktuell sind – nicht betroffen.
Unsere Next-Gen WAF Kunden sind durch eine Templated Rule vor dieser Sicherheitslücke geschützt.
Unter CVE-2021-40438 versteht man eine Schwachstelle im Apache HTTP Server Version 2.4.48 oder niedriger, die Server-Side Request Forgery (SSRF) zulässt. Durch das Versenden einer speziell darauf ausgelegten Anfrage können Angreifer das mod_proxy-Modul (sofern aktiviert) dazu zwingen, Verbindungen an einen Origin-Server ihrer Wahl weiterzuleiten. So können sie vertrauliche Daten (wie Infrastruktur-Metadaten oder -schlüssel) exfiltrieren oder auf andere interne Server zugreifen (die möglicherweise weniger gut geschützt sind als externe Server).
Was sind die Auswirkungen?
Von dieser Schwachstelle sind nur Apache HTTP Server (auch bekannt als „httpd“) Version 2.4.48 oder niedriger betroffen. Allerdings muss das mod_proxy-Modul aktiviert sein, damit die Server überhaupt anfällig sind. Bevor Angreifer aus dieser Sicherheitslücke also Kapital schlagen können, müssen sie erst einmal Server finden, die diese spezifischen Bedingungen erfüllen.
Leider deuten aber Daten von Shodan darauf hin, dass dies bei über 500.000 Servern der Fall ist. Böswillige Angriffe sind daher nicht gänzlich auszuschließen.
Warum das Ganze so interessant ist
Als Angriffsmethode ist SSRF (über das wir bereits berichtet haben) in den letzten Jahren immer beliebter geworden. Das ist wahrscheinlich auf mehrere Faktoren zurückzuführen: die Effektivität der Sicherheitslücke, die Schwierigkeit bei der Erkennung von SSRF und die Tatsache, dass es immer mehr anfällige Endpoints gibt (die Kehrseite unserer vernetzten Welt). Tatsächlich ist SSRF so weitverbreitet, dass es zu den OWASP Top 10 zählt und mit namhaften Sicherheitsverletzungen in Verbindung gebracht werden kann. Man kann sich SSRF als eine Art böswilliger Reverse Proxy vorstellen, den Angreifer für ihre Zwecke nutzen.
Darüber hinaus haben wir festgestellt, dass eine ganze Reihe von Nutzern mit cPanel auf CentOS ihren Apache Server aufgrund einer anderen vor Kurzem identifizierten Schwachstelle – CVE-2021-41773 – von den neueren Versionen 2.4.49 und 2.4.50 auf 2.4.48 zurückgesetzt haben. Leider bedeutet dieses Downgrade, dass diese Nutzer nun anfällig für den entsprechenden Angriff sind. Einen Path-Traversal- gegen einen SSRF-Angriff einzutauschen ist nicht unbedingt empfehlenswert.
Ja, aber …
Während eine Sicherheitsverletzung für Organisationen mit einer älteren Version von Apache HTTP Server böse ausgehen kann, stellt die Cloud für Angreifer den lukrativsten Vektor dar. Etliche Cloud-Anbieter, darunter Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP), bieten allerdings integrierte Schutzmechanismen.
Deshalb hat diese Schwachstelle vermutlich nur Auswirkungen gegenüber Organisationen, die ihre eigenen httpd-Server betreiben. Organisationen mit selbst gehosteten Apache HTTP Serverinstanzen sollten alle Anwendungen, auf die ihr Apache Server (über GET-Anfragen) Zugriff hat, folglich in ihre Überlegungen zu den potenziellen Auswirkungen der Störung einbeziehen.
Das mod_proxy-Modul implementiert einen Proxy, über den Verbindungen im Apache HTTP Server umgeleitet werden können. Oft dient dieser als Gateway zu Anwendungsservern und bietet die für Proxyserver typischen Vorteile (beispielsweise Loadbalancing).
Der entsprechende Commit, der dieses Problem behebt, lautet r1892814. Auf einem gepatchten Apache Server wird der Code, der die URL (den Proxy-Bestimmungsort) parst, demnach nur getriggert, wenn der unix:-String am Anfang der Proxy-URL steht (Beispiel: [proxy:]unix:path|url). Auf einem nicht gepatchten Server sucht die Parse-Funktion hingegen anstatt nur am Anfang des Strings in der gesamten vom Nutzer bereitgestellten URL nach unix:.
Außerdem scheint es so, als könne der Angreifer die an die Funktion ap_runtime_dir_relative weitergegebenen Variablen kontrollieren. Aus langjähriger Erfahrung mit der Programmiersprache C wissen wir, dass dies möglicherweise zu Pufferüberläufen oder unerwarteten Funktionszuständen führt. Und ein potentieller Crash oder die Gefahr, dass ein Angreifer die Kontrolle übernimmt, ist nie wünschenswert und macht Sec- und Ops-Team grundsätzlich zu schaffen.
Wir können diesen Exploit bewusst herbeiführen, indem wir APR_PATH_MAX zwingen, einen durch Überschreitung der Zeichenlänge (7.701 Zeichen) verursachten Fehlercode auszugeben. Dies können Sie mithilfe des folgenden Befehls testen, der den Server anweist, als Antwort den Buchstaben „A“ so oft in Folge zurückzugeben, bis die Zeichenbeschränkung überschritten ist (herzlichen Dank an dieser Stelle an @_mattata):
curl "http://localhost/?unix:$(python3 -c 'print("A"*7701, end="")')|http://backend_server1:8080/"Eine Schritt-für-Schritt-Anleitung, wie genau diese Schwachstelle ausgenutzt werden kann, finden Sie in diesem Blogpost, in dem der Exploit eines Proof of Concept beschrieben wird.
Was Sie tun sollten
Jeder, der einen Apache HTTP Server Version 2.4.48 oder niedriger verwendet, sollte ihn auf Version 2.4.51 patchen und den mod_proxy-Pfad dabei entweder deaktivieren oder sicherstellen, dass er bis zur Durchführung des Patches deaktiviert ist.
Als Apache HTTP Server Kunde können Sie folgende Schritte ausführen, um die neue Templated Rule zum Schutz vor CVE-2021-40438 anzuwenden.
Wenn Sie zu unseren Next-Gen WAF Kunden gehören und Ihren Apache Server in AWS betreiben, können Sie die von AWS bereitgestellte SSRF Templated Rule aktivieren und sich damit vor allen möglichen SSRF-Angriffen schützen, die speziell in AWS auftreten.
Wählen Sie „Site“ -> „Site Rules“ -> „Templated Rules“.
Gehen Sie zum Menüpunkt „CVE-2021-40438“, wählen Sie ihn aus und klicken Sie anschließend auf „Configure“. Aktivieren Sie die Regel „Block requests from an IP“.
Vergewissern Sie sich, dass die Regel auf der Templated-Rules-Seite als „Enabled“ dargestellt wird.
