juanschallibaum/cve-2024-38473-nuclei-templatePlantilla de Nuclei para detectar servidores Apache vulnerables a CVE-2024-38473
Plantilla de Nuclei diseñada para detectar servidores Apache vulnerables a CVE-2024-38473. Primero identifica servidores que ejecutan Apache < 2.4.60 con la configuración predeterminada de PHP-FPM. Luego, realiza fuzzing para encontrar posibles archivos PHP protegidos por ACLs que podrían ser omitidos debido a esta vulnerabilidad.
Para usar esta plantilla de Nuclei, necesitas clonar el repositorio. Puedes hacerlo ejecutando el siguiente comando:
git clone https://github.com/juanschallibaum/CVE-2024-38473-Nuclei-Template
Navega al directorio del repositorio clonado:
cd CVE-2024-38473-Nuclei-Template
Ejecutar la plantilla de Nuclei en un solo host:
nuclei -t CVE-2024-38473.yaml -u http://example.com
Ejecutar la plantilla de Nuclei contra una lista de hosts:
nuclei -t CVE-2024-38473.yaml -l hosts.txt
Ejecutar la plantilla de Nuclei en un solo host especificando un archivo .html o .php válido:
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
Ejecutar Nuclei de esta manera puede producir una mayor tasa de detección. También puedes incluir URLs en este formato dentro del archivo de hosts para ejecutar la plantilla contra esa lista.
Para probar fácilmente la vulnerabilidad CVE-2024-38473, puedes configurar un entorno vulnerable usando Docker. Sigue estos pasos para verificar rápidamente la efectividad de la plantilla de Nuclei:
Asegúrate de que el demonio de Docker esté en ejecución: Verifica que el demonio de Docker esté corriendo en tu sistema. Puedes iniciarlo con el siguiente comando si aún no lo está:
sudo systemctl start docker
Ejecutar el contenedor Docker: Dentro del directorio del repositorio, usa el siguiente comando Docker para iniciar un contenedor con una configuración vulnerable de Apache y PHP-FPM:
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
Probar la vulnerabilidad:
Manualmente: Abre tu navegador web y navega a http://localhost:8787 para interactuar con el servidor Apache que se ejecuta en el contenedor Docker. Accede a http://localhost:8787/info.php para probar la vulnerabilidad. Este archivo está protegido por una ACL y, si la omisión de la ACL es exitosa, verás la salida de phpinfo():
Usando la plantilla de Nuclei: Ejecuta el siguiente comando de Nuclei para probar el servidor con la plantilla:
nuclei -t CVE-2024-38473.yaml -u http://localhost:8787
El 8 de agosto de 2024, el investigador de seguridad Orange Tsai presentó una charla en Black Hat USA 2024 titulada: Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!. En esta presentación, reportó múltiples vulnerabilidades que afectan a Apache HTTP Server. Explicó que Apache tiene una arquitectura altamente modular, compuesta por cientos de módulos, cada uno realizando su función mientras lee y escribe en una estructura compartida llamada request_rec, que consta de casi 100 campos.
La causa raíz de las vulnerabilidades reportadas por el investigador de seguridad radica en la inconsistencia en cómo los diferentes módulos de Apache tratan los diversos campos de la estructura compartida. Por ejemplo, mod_authz_core trata el campo r->filename como un archivo, mientras que mod_proxy lo trata como una URL, lo que genera discrepancias que resultan en una amplia gama de vulnerabilidades.
En su presentación, Orange Tsai define un tipo de ataque llamado "Filename Confusion". Aunque este ataque tiene una superficie de ataque variada, CVE-2024-38473, que cubrimos en esta plantilla, se refiere a cómo podemos aplicar el ataque "Filename Confusion" para omitir las ACL de Apache y obtener acceso a archivos restringidos.
El problema surge cuando el módulo de autenticación de Apache, mod_authz_core, trata el atributo r->filename como un archivo, mientras que mod_proxy lo trata como una URL. Debido a esto, las instalaciones de Apache con PHP-FPM en su configuración predeterminada se ven afectadas por esta vulnerabilidad. Imagina que un servidor que ejecuta Apache y PHP-FPM tiene una ACL configurada como la siguiente para proteger el acceso al archivo admin.php con credenciales:
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
Debido a la vulnerabilidad, es posible omitir ACL como la anterior que implican proteger un archivo individual. De hecho, esto se puede hacer tan fácilmente como enviando la siguiente solicitud: http://server/admin.php%3fooo.php.
Para entender esto en profundidad, es importante considerar que cuando Apache procesa una solicitud como la anterior, el módulo mod_authz_core lee el valor admin.php?fooo.php del campo r->filename de la estructura compartida. Trata este valor como el nombre del archivo solicitado y, al compararlo con la ACL, no coincide porque admin.php?fooo.php es diferente de admin.php.
Luego, dado que admin.php?fooo.php termina en .php, la solicitud es manejada por PHP-FPM. PHP-FPM elimina todo lo que sigue al ? en el nombre de archivo recibido de Apache antes de procesarlo, tratándolo como una URL en lugar de un archivo. Como resultado, PHP-FPM procesará admin.php directamente. Debido a que la verificación de ACL se superó anteriormente, el atacante puede acceder a admin.php sin autenticación.
La plantilla de Nuclei actual no solo tiene como objetivo descubrir archivos protegidos por fuerza bruta, sino que también incluye lógica para identificar cuándo un servidor tiene una configuración vulnerable de Apache < 2.4.60 con PHP-FPM, incluso si no se detectan casos de archivos protegidos por ACL. En el flujo básico, primero intenta identificar si el servidor tiene una configuración vulnerable y, luego, si es positivo, intenta identificar archivos comunes que puedan estar protegidos por ACL.
La idea detrás de la detección de configuraciones vulnerables con Apache < 2.4.60 y PHP-FPM se basa en dos premisas básicas:
En una configuración vulnerable, si file.php existe en el servidor, entonces la solicitud a http://server/file.php%3fooo.php devolvería el mismo código de estado 200 y la misma longitud de cuerpo que la solicitud a http://server/file.php (porque después de que PHP-FPM elimina %3fooo.php, el archivo solicitado sería el mismo).
En una configuración vulnerable, si file.html existe en el servidor, entonces la solicitud a http://server/file.html%3fooo.php devolvería 403 Acceso Denegado. Esto se debe a que PHP-FPM intentaría cargar un archivo con extensión .html en lugar de .php, lo cual no está permitido por defecto.
El flujo de la plantilla consta de 7 grupos de solicitudes. Deben ejecutarse en orden y deben cumplir las respectivas condiciones de coincidencia para pasar al siguiente grupo de solicitudes. Esto ayuda a minimizar la cantidad de solicitudes enviadas en vano cuando ya se sabe que las condiciones no se cumplen.
La plantilla envía una solicitud a index.phpooo.php%3fooo.php, que es un archivo inexistente. La idea es filtrar falsos positivos en casos donde index.php%3fooo.php devuelve un código de estado 200 y el mismo cuerpo que index.php, incluso cuando PHP-FPM no está configurado. Esto podría ocurrir, por ejemplo, cuando hay reglas que reescriben cualquier archivo solicitado o archivos que comienzan con "index" a index.php, como:
RewriteRule . /index.php [L]
RewriteRule ^index\.php(.*)$ index.php [L]
RewriteRule ^index(.*)$ index.php [L]
Esta solicitud debería devolver un código de estado 200 si el servidor tiene reglas como las mencionadas anteriormente, o un código de estado 404 en casos normales donde PHP-FPM podría estar configurado. Si esta solicitud no devuelve un código de estado 404, la plantilla dejará de procesar este host.
La plantilla envía una solicitud a foo.phpooo.php%3fooo.php, que es un archivo inexistente. La idea es filtrar falsos positivos en casos donde index.html%3fooo.php devuelve un código de estado 403, incluso cuando PHP-FPM no está configurado. Esto podría ocurrir, por ejemplo, cuando hay reglas que prohíben el carácter %3f en cualquier parte de la URL o que restringen el acceso a archivos que terminan en .php. Ejemplos de tales reglas incluyen:
<FilesMatch "\.php$">
Require all denied
</FilesMatch>
RewriteCond %{REQUEST_URI} (%3f)
RewriteRule ^(.*)$ - [F]
Esta solicitud debería devolver un código de estado 403 si el servidor tiene reglas como las mencionadas anteriormente, o un código de estado 404 en casos normales donde PHP-FPM podría estar configurado. Si esta solicitud no devuelve un código de estado 404, la plantilla dejará de procesar este host.
La plantilla envía solicitudes para identificar algunos archivos disponibles en el servidor. Primero, intenta identificar si index.php está disponible. Luego, verifica index.html e index.htm. Finalmente, prueba el archivo presente en la URL proporcionada por el usuario si existe. Si se ejecuta Nuclei especificando un archivo válido en la URL, puede mejorar la eficacia de la detección en casos donde los archivos índice clásicos no existen.
La plantilla envía una solicitud a un archivo inexistente para filtrar los últimos falsos positivos en casos donde index.php%3fooo.php devuelve un código de estado 200 y el mismo cuerpo que index.php, incluso cuando PHP-FPM no está configurado. Algunos servidores web, especialmente aquellos que no son Apache, ignoran todo lo que sigue al %3f. Por lo tanto, si enviamos index.php%3fooo.php, el servidor lo trata como index.php. Para filtrar estos casos, la plantilla envía una solicitud a index.php%3fooo.html (si index.php se encontró en el servidor) o index.html%3fooo.html (si index.html se encontró en el servidor). Dado que termina en .html, en casos normales donde PHP-FPM podría estar configurado, no sería procesado por PHP-FPM y se trataría como un archivo estático que lógicamente no existe, lo que resulta en un código de estado 404. Sin embargo, devolvería un código de estado 200 en los casos que queremos filtrar, donde todo lo que sigue al %3f se ignora. Si esta solicitud no devuelve un código de estado 404, la plantilla dejará de procesar este host.
La plantilla envía una solicitud para identificar la configuración vulnerable. Hay 2 casos, de los cuales al menos una de las condiciones de coincidencia debe cumplirse:
Caso 1: En la Solicitud #3, se encontró index.php. En este caso, si Apache < 2.4.60 y PHP-FPM está habilitado con la configuración predeterminada, debería eliminar la parte %3fooo.php y cargar index.php, lo que resulta en una respuesta 200 con la misma longitud que la obtenida en la Solicitud #3. Si se usa mod_php u otro manejador, trataría index.php%3fooo.php como el nombre de archivo completo y devolvería un 404. Para que este caso coincida, la solicitud debe devolver 200 y un cuerpo con la misma longitud que la respuesta de la Solicitud #3.
Caso 2: En la Solicitud #3, se encontró index.html. En este caso, si Apache < 2.4.60 y PHP-FPM está habilitado con la configuración predeterminada, debería eliminar la parte %3fooo.php e intentar cargar index.html, lo que devolvería un 403 Acceso Denegado, ya que PHP-FPM estaría intentando cargar un archivo con una extensión no permitida. Si se usa mod_php u otro manejador, trataría index.php%3fooo.php como el nombre de archivo completo y devolvería un 404. Para que este caso coincida, la solicitud debe devolver 404.
Si la plantilla ha llegado a este punto, indica que el servidor tiene una configuración vulnerable. En consecuencia, la plantilla envía solicitudes para hacer fuzzing en busca de posibles archivos protegidos que devuelvan un código de estado 403 o que requieran autenticación y devuelvan un código de estado 401. Por defecto, intenta identificar solo un puñado de los nombres de archivo más comunes y potencialmente protegidos. Sin embargo, puedes descomentar una línea para usar una lista de palabras personalizada con 350 posibles nombres de archivo PHP.
La plantilla envía una solicitud para validar que el archivo protegido identificado en la Solicitud #6 devuelve un código de estado 200 con la omisión.
Si se cumple alguna condición de coincidencia de la Solicitud #5, indica que el servidor está ejecutando Apache < 2.4.60 con la configuración predeterminada de PHP-FPM. Esto significa que si hay una ACL protegiendo un archivo individual, puede ser omitida. Sin embargo, muchas veces estas configuraciones vulnerables pueden detectarse sin identificar ningún archivo protegido. Por defecto, la plantilla usa la lista de palabras wordlists/potential_protected_php_files_10.php para hacer fuzzing en busca de archivos protegidos. Esta lista incluye los 10 nombres de archivo PHP más probables de estar protegidos por ACL. Alternativamente, hay disponible una lista de palabras más grande con 350 entradas: wordlists/potential_protected_php_files_350.php. Para cambiar a la lista más grande, comenta la lista de 10 entradas y descomenta la lista de 350 entradas en la sección YAML de la Solicitud #6 de la plantilla, de la siguiente manera:
#fuzz: wordlists/potential_protected_php_files_10.txt
fuzz: wordlists/potential_protected_php_files_350.txt
El uso de la lista de palabras más grande puede aumentar las posibilidades de encontrar archivos PHP protegidos. Sin embargo, la lista de palabras potential_protected_php_files_350.txt puede contener nombres de archivo PHP poco comunes y puede carecer de nombres de archivo PHP más comunes que podrían estar protegidos por ACL. Por lo tanto, cualquier mejora o adición a la lista de palabras es bienvenida. Además, se pueden emplear listas de palabras personalizadas aún más grandes para una exploración más profunda.
Ten en cuenta que las ACL omitibles pueden estar configuradas para diferentes hosts virtuales, en archivos .htaccess en cualquier directorio de la aplicación, no solo en el directorio raíz. Por lo tanto, para maximizar la probabilidad de identificar archivos protegidos por ACL, se recomienda realizar un reconocimiento exhaustivo de directorios y subdominios, y ejecutar la plantilla contra todas las URLs identificadas con diferentes subdominios y directorios.
Actualmente, el flujo de la Solicitud #6 se detiene después de identificar el primer archivo protegido por ACL. Sin embargo, podría haber más. Esto sucede porque no he encontrado una forma de hacer fuzzing de múltiples archivos con Nuclei, almacenar los resultados y luego usarlos en una solicitud de seguimiento para verificar si la omisión realmente otorga acceso a los archivos protegidos. Por lo tanto, cualquier sugerencia sobre cómo se puede modificar la plantilla para identificar múltiples archivos protegidos y validar que de hecho se pueden omitir también es bienvenida.
Todo el crédito por reportar las vulnerabilidades y llevar a cabo la destacada investigación es para Orange Tsai. Su extenso trabajo sobre las vulnerabilidades de Apache HTTP Server, incluida CVE-2024-38473, ha contribuido significativamente a mejorar la conciencia de seguridad. Yo, Juan Schallibaum, soy el único responsable de crear esta plantilla de Nuclei para facilitar las pruebas y la detección de CVE-2024-38473.
El uso de esta plantilla de Nuclei para atacar objetivos sin consentimiento mutuo previo es ilegal. Es responsabilidad del usuario final cumplir con todas las leyes locales, estatales y federales aplicables. Los desarrolladores no asumen ninguna responsabilidad por el mal uso, daños o consecuencias legales derivados del uso de esta plantilla. Asegúrate siempre de tener permiso explícito antes de realizar cualquier prueba de seguridad.