Nginx
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Obtén la perspectiva de un hacker sobre tus aplicaciones web, red y nube
Encuentra e informa sobre vulnerabilidades críticas y explotables con un impacto real en el negocio. Utiliza nuestras más de 20 herramientas personalizadas para mapear la superficie de ataque, encontrar problemas de seguridad que te permitan escalar privilegios y usar exploits automatizados para recopilar evidencia esencial, convirtiendo tu arduo trabajo en informes persuasivos.
Al configurar el servidor Nginx, la directiva root juega un papel crítico al definir el directorio base desde el cual se sirven los archivos. Considera el siguiente ejemplo:
En esta configuración, /etc/nginx se designa como el directorio raíz. Esta configuración permite el acceso a archivos dentro del directorio raíz especificado, como /hello.txt. Sin embargo, es crucial notar que solo se define una ubicación específica (/hello.txt). No hay configuración para la ubicación raíz (location / {...}). Esta omisión significa que la directiva raíz se aplica globalmente, permitiendo que las solicitudes a la ruta raíz / accedan a archivos bajo /etc/nginx.
Una consideración crítica de seguridad surge de esta configuración. Una simple solicitud GET, como GET /nginx.conf, podría exponer información sensible al servir el archivo de configuración de Nginx ubicado en /etc/nginx/nginx.conf. Establecer la raíz en un directorio menos sensible, como /etc, podría mitigar este riesgo, sin embargo, aún podría permitir el acceso no intencionado a otros archivos críticos, incluidos otros archivos de configuración, registros de acceso e incluso credenciales encriptadas utilizadas para la autenticación básica HTTP.
En los archivos de configuración de Nginx, se justifica una inspección minuciosa de las directivas "location". Una vulnerabilidad conocida como Local File Inclusion (LFI) puede ser introducida inadvertidamente a través de una configuración que se asemeje a la siguiente:
Esta configuración es propensa a ataques LFI debido a que el servidor interpreta solicitudes como /imgs../flag.txt como un intento de acceder a archivos fuera del directorio previsto, resolviendo efectivamente a /path/images/../flag.txt. Este defecto permite a los atacantes recuperar archivos del sistema de archivos del servidor que no deberían ser accesibles a través de la web.
Para mitigar esta vulnerabilidad, la configuración debe ajustarse a:
Más información: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/
Pruebas de Accunetix:
Consulta la siguiente página para aprender cómo eludir directivas como:
Variables vulnerables $uri y $document_uri y esto se puede solucionar reemplazándolas con $request_uri.
Una expresión regular también puede ser vulnerable como:
location ~ /docs/([^/])? { … $1 … } - Vulnerable
location ~ /docs/([^/\s])? { … $1 … } - No vulnerable (verificando espacios)
location ~ /docs/(.*)? { … $1 … } - No vulnerable
Una vulnerabilidad en la configuración de Nginx se demuestra con el siguiente ejemplo:
Los caracteres \r (Retorno de Carro) y \n (Salto de Línea) significan caracteres de nueva línea en las solicitudes HTTP, y sus formas codificadas en URL se representan como %0d%0a. Incluir estos caracteres en una solicitud (por ejemplo, http://localhost/%0d%0aDetectify:%20clrf) a un servidor mal configurado resulta en que el servidor emita un nuevo encabezado llamado Detectify. Esto sucede porque la variable $uri decodifica los caracteres de nueva línea codificados en URL, lo que lleva a un encabezado inesperado en la respuesta:
Aprenda más sobre los riesgos de la inyección CRLF y la división de respuestas en https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.
Además, esta técnica está explicada en esta charla con algunos ejemplos vulnerables y mecanismos de detección. Por ejemplo, para detectar esta mala configuración desde una perspectiva de caja negra, podría usar estas solicitudes:
https://example.com/%20X - Cualquier código HTTP
https://example.com/%20H - 400 Bad Request
Si es vulnerable, la primera devolverá "X" como cualquier método HTTP y la segunda devolverá un error ya que H no es un método válido. Así que el servidor recibirá algo como: GET / H HTTP/1.1 y esto desencadenará el error.
Otros ejemplos de detección serían:
http://company.tld/%20HTTP/1.1%0D%0AXXXX:%20x - Cualquier código HTTP
http://company.tld/%20HTTP/1.1%0D%0AHost:%20x - 400 Bad Request
Algunas configuraciones vulnerables encontradas presentadas en esa charla fueron:
Nota cómo $uri se establece tal como está en la URL final.
Nota cómo nuevamente $uri está en la URL (esta vez dentro de un parámetro)
Ahora en AWS S3
Se descubrió que los datos proporcionados por el usuario podrían ser tratados como una variable de Nginx bajo ciertas circunstancias. La causa de este comportamiento sigue siendo algo elusiva, sin embargo, no es raro ni sencillo de verificar. Esta anomalía fue destacada en un informe de seguridad en HackerOne, que se puede ver aquí. Una investigación adicional sobre el mensaje de error llevó a la identificación de su ocurrencia dentro del módulo de filtro SSI del código de Nginx, señalando a Server Side Includes (SSI) como la causa raíz.
Para detectar esta mala configuración, se puede ejecutar el siguiente comando, que implica establecer un encabezado referer para probar la impresión de variables:
Scaneos para esta mala configuración en los sistemas revelaron múltiples instancias donde las variables de Nginx podían ser impresas por un usuario. Sin embargo, una disminución en el número de instancias vulnerables sugiere que los esfuerzos para corregir este problema han tenido cierto éxito.
Nginx ofrece una característica a través de proxy_pass que permite la interceptación de errores y encabezados HTTP producidos por el backend, con el objetivo de ocultar mensajes de error internos y encabezados. Esto se logra mediante Nginx sirviendo páginas de error personalizadas en respuesta a errores del backend. Sin embargo, surgen desafíos cuando Nginx encuentra una solicitud HTTP inválida. Tal solicitud se reenvía al backend tal como se recibe, y la respuesta cruda del backend se envía directamente al cliente sin la intervención de Nginx.
Considere un escenario de ejemplo que involucra una aplicación uWSGI:
Para gestionar esto, se utilizan directivas específicas en la configuración de Nginx:
proxy_intercept_errors: Esta directiva permite que Nginx sirva una respuesta personalizada para las respuestas del backend con un código de estado mayor a 300. Asegura que, para nuestro ejemplo de aplicación uWSGI, una respuesta de 500 Error sea interceptada y manejada por Nginx.
proxy_hide_header: Como su nombre indica, esta directiva oculta los encabezados HTTP especificados del cliente, mejorando la privacidad y la seguridad.
Cuando se realiza una solicitud GET válida, Nginx la procesa normalmente, devolviendo una respuesta de error estándar sin revelar ningún encabezado secreto. Sin embargo, una solicitud HTTP no válida elude este mecanismo, lo que resulta en la exposición de respuestas en bruto del backend, incluidos encabezados secretos y mensajes de error.
Por defecto, la directiva merge_slashes de Nginx está configurada en on, lo que comprime múltiples barras diagonales en una URL en una sola barra. Esta característica, aunque agiliza el procesamiento de URL, puede ocultar inadvertidamente vulnerabilidades en aplicaciones detrás de Nginx, particularmente aquellas propensas a ataques de inclusión de archivos locales (LFI). Los expertos en seguridad Danny Robinson y Rotem Bar han destacado los riesgos potenciales asociados con este comportamiento predeterminado, especialmente cuando Nginx actúa como un proxy inverso.
Para mitigar tales riesgos, se recomienda desactivar la directiva merge_slashes para aplicaciones susceptibles a estas vulnerabilidades. Esto asegura que Nginx reenvíe solicitudes a la aplicación sin alterar la estructura de la URL, evitando así enmascarar problemas de seguridad subyacentes.
Para más información, consulta a Danny Robinson y Rotem Bar.
Como se muestra en este informe, hay ciertos encabezados que, si están presentes en la respuesta del servidor web, cambiarán el comportamiento del proxy de Nginx. Puedes revisarlos en la documentación:
X-Accel-Redirect: Indica a Nginx que redirija internamente una solicitud a una ubicación especificada.
X-Accel-Buffering: Controla si Nginx debe almacenar en búfer la respuesta o no.
X-Accel-Charset: Establece el conjunto de caracteres para la respuesta al usar X-Accel-Redirect.
X-Accel-Expires: Establece el tiempo de expiración para la respuesta al usar X-Accel-Redirect.
X-Accel-Limit-Rate: Limita la tasa de transferencia para las respuestas al usar X-Accel-Redirect.
Por ejemplo, el encabezado X-Accel-Redirect causará una redirección interna en Nginx. Así que tener una configuración de Nginx con algo como root / y una respuesta del servidor web con X-Accel-Redirect: .env hará que Nginx envíe el contenido de /.env (Path Traversal).
En la configuración de Nginx, la directiva map a menudo juega un papel en el control de autorización. Un error común es no especificar un valor predeterminado, lo que podría llevar a un acceso no autorizado. Por ejemplo:
Sin un default, un usuario malicioso puede eludir la seguridad accediendo a un URI indefinido dentro de /map-poc. El manual de Nginx aconseja establecer un valor predeterminado para evitar tales problemas.
El spoofing de DNS contra Nginx es factible bajo ciertas condiciones. Si un atacante conoce el servidor DNS utilizado por Nginx y puede interceptar sus consultas DNS, puede falsificar registros DNS. Sin embargo, este método es ineficaz si Nginx está configurado para usar localhost (127.0.0.1) para la resolución de DNS. Nginx permite especificar un servidor DNS de la siguiente manera:
proxy_pass y Directivas internalLa directiva proxy_pass se utiliza para redirigir solicitudes a otros servidores, ya sea internamente o externamente. La directiva internal asegura que ciertas ubicaciones solo sean accesibles dentro de Nginx. Aunque estas directivas no son vulnerabilidades por sí mismas, su configuración requiere un examen cuidadoso para prevenir lapsos de seguridad.
Si el servidor nginx está configurado para pasar los encabezados Upgrade y Connection, se podría realizar un ataque de Smuggling h2c para acceder a puntos finales protegidos/internos.
Esta vulnerabilidad permitiría a un atacante establecer una conexión directa con el endpoint proxy_pass (http://backend:9999 en este caso) cuyo contenido no será verificado por nginx.
Ejemplo de configuración vulnerable para robar /flag de aquí:
Nota que incluso si el proxy_pass estaba apuntando a una ruta específica como http://backend:9999/socket.io, la conexión se establecerá con http://backend:9999, por lo que puedes contactar cualquier otra ruta dentro de ese endpoint interno. Así que no importa si se especifica una ruta en la URL de proxy_pass.
Detectify ha creado un repositorio de GitHub donde puedes usar Docker para configurar tu propio servidor de prueba Nginx vulnerable con algunas de las configuraciones incorrectas discutidas en este artículo y ¡intentar encontrarlas tú mismo!
https://github.com/detectify/vulnerable-nginx
Gixy es una herramienta para analizar la configuración de Nginx. El objetivo principal de Gixy es prevenir configuraciones de seguridad incorrectas y automatizar la detección de fallos.
Nginxpwner es una herramienta simple para buscar configuraciones incorrectas y vulnerabilidades comunes de Nginx.
Obtén la perspectiva de un hacker sobre tus aplicaciones web, red y nube
Encuentra y reporta vulnerabilidades críticas y explotables con un impacto real en el negocio. Usa nuestras más de 20 herramientas personalizadas para mapear la superficie de ataque, encontrar problemas de seguridad que te permitan escalar privilegios y usar exploits automatizados para recopilar evidencia esencial, convirtiendo tu arduo trabajo en informes persuasivos.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
