Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/nginx.md

18 KiB
Raw Blame History

Nginx

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

DragonJAR Security Conference es un evento internacional de ciberseguridad con más de una década que se celebrará el 7 y 8 de septiembre de 2023 en Bogotá, Colombia. Es un evento de gran contenido técnico donde se presentan las últimas investigaciones en español que atrae a hackers e investigadores de todo el mundo.
¡Regístrate ahora en el siguiente enlace y no te pierdas esta gran conferencia!:

{% embed url="https://www.dragonjarcon.org/" %}

Falta la ubicación raíz 

server {
root /etc/nginx;

location /hello.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:8080/;
}
}

La directiva root especifica la carpeta raíz para Nginx. En el ejemplo anterior, la carpeta raíz es /etc/nginx, lo que significa que podemos acceder a los archivos dentro de esa carpeta. La configuración anterior no tiene una ubicación para / (location / {...}), solo para /hello.txt. Debido a esto, la directiva root se establecerá de forma global, lo que significa que las solicitudes a / te llevarán a la ruta local /etc/nginx.

Una solicitud tan simple como GET /nginx.conf revelaría el contenido del archivo de configuración de Nginx almacenado en /etc/nginx/nginx.conf. Si la raíz se establece en /etc, una solicitud GET a /nginx/nginx.conf revelaría el archivo de configuración. En algunos casos, es posible acceder a otros archivos de configuración, registros de acceso e incluso credenciales cifradas para la autenticación básica de HTTP.

Configuración incorrecta de Alias LFI

Dentro de la configuración de Nginx, busca las declaraciones "location", si alguna se parece a:

location /imgs {
alias /path/images/;
}

Existe una vulnerabilidad de LFI debido a:

/imgs../flag.txt

Nginx

Nginx is a popular web server that is commonly used to serve static content, reverse proxy, and load balance web applications. It is known for its high performance, scalability, and reliability.

Configuration Files

Nginx uses configuration files to define how it should handle incoming requests. The main configuration file is typically located at /etc/nginx/nginx.conf. Additional configuration files can be included using the include directive.

Virtual Hosts

Nginx supports virtual hosts, allowing multiple websites to be hosted on a single server. Each virtual host is defined in a separate configuration file, typically located in the /etc/nginx/conf.d/ directory. Virtual hosts can be used to serve different websites based on the domain name or IP address.

Reverse Proxy

Nginx can be used as a reverse proxy to forward requests to backend servers. This is useful for load balancing, caching, and improving performance. The proxy_pass directive is used to specify the backend server to which requests should be forwarded.

Load Balancing

Nginx can also be used as a load balancer to distribute incoming requests across multiple backend servers. It supports various load balancing algorithms, such as round-robin, least connections, and IP hash. The upstream directive is used to define a group of backend servers, and the proxy_pass directive is used to forward requests to the backend servers.

SSL/TLS Termination

Nginx can terminate SSL/TLS connections, allowing it to handle HTTPS requests. It can also be used to offload SSL/TLS processing from backend servers, improving performance. The ssl_certificate and ssl_certificate_key directives are used to specify the SSL/TLS certificate and private key, respectively.

Security Considerations

When configuring Nginx, it is important to consider security best practices. This includes properly securing the server, implementing access controls, and protecting sensitive information. Regularly updating Nginx and its modules is also important to address any security vulnerabilities.

Conclusion

Nginx is a powerful web server that offers a wide range of features and capabilities. Understanding how to configure and use Nginx effectively can greatly enhance the performance, scalability, and security of web applications.

/path/images/../flag.txt

La configuración correcta será:

location /imgs/ {
alias /path/images/;
}

Entonces, si encuentras algún servidor Nginx, debes verificar esta vulnerabilidad. Además, puedes descubrirla si notas que la fuerza bruta de archivos/directorios se comporta de manera extraña.

Más información: https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/

Pruebas de Accunetix:

alias../ => HTTP status code 403
alias.../ => HTTP status code 404
alias../../ => HTTP status code 403
alias../../../../../../../../../../../ => HTTP status code 400
alias../ => HTTP status code 403

Restricción de ruta insegura

Verifica la siguiente página para aprender cómo evadir directivas como:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Uso inseguro de variables

Un ejemplo de una configuración vulnerable de Nginx es:

location / {
return 302 https://example.com$uri;
}

Los caracteres de nueva línea para las solicitudes HTTP son \r (retorno de carro) y \n (salto de línea). La codificación de URL de los caracteres de nueva línea resulta en la siguiente representación de los caracteres %0d%0a. Cuando estos caracteres se incluyen en una solicitud como http://localhost/%0d%0aDetectify:%20clrf a un servidor con la configuración incorrecta, el servidor responderá con una nueva cabecera llamada Detectify, ya que la variable $uri contiene los caracteres de nueva línea decodificados de la URL.

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.19.3
Content-Type: text/html
Content-Length: 145
Connection: keep-alive
Location: https://example.com/
Detectify: clrf

Aprende más sobre los riesgos de la inyección de CRLF y la división de respuestas en https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Cualquier variable

En algunos casos, los datos proporcionados por el usuario pueden ser tratados como una variable de Nginx. No está claro por qué esto puede estar sucediendo, pero no es tan raro o fácil de probar como se ve en este informe de H1. Si buscamos el mensaje de error, podemos ver que se encuentra en el módulo de filtro SSI, revelando así que esto se debe a SSI.

Una forma de probar esto es establecer un valor de encabezado referer:

$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’

Escaneamos esta configuración incorrecta y encontramos varias instancias donde un usuario podría imprimir el valor de las variables de Nginx. El número de instancias vulnerables encontradas ha disminuido, lo que podría indicar que esto fue parcheado.

Lectura de respuesta en bruto del backend

Con proxy_pass de Nginx, existe la posibilidad de interceptar errores y encabezados HTTP creados por el backend. Esto es muy útil si desea ocultar mensajes de error y encabezados internos para que sean manejados por Nginx en su lugar. Nginx automáticamente servirá una página de error personalizada si el backend responde con una. Pero, ¿qué sucede si Nginx no entiende que es una respuesta HTTP?

Si un cliente envía una solicitud HTTP inválida a Nginx, esa solicitud se reenviará tal cual al backend, y el backend responderá con su contenido en bruto. Luego, Nginx no entenderá la respuesta HTTP inválida y simplemente la reenviará al cliente. Imagina una aplicación uWSGI como esta:

def application(environ, start_response):
start_response('500 Error', [('Content-Type',
'text/html'),('Secret-Header','secret-info')])
return [b"Secret info, should not be visible!"]

Y con las siguientes directivas en Nginx:

http {
error_page 500 /html/error.html;
proxy_intercept_errors on;
proxy_hide_header Secret-Header;
}

proxy_intercept_errors servirá una respuesta personalizada si el backend tiene un estado de respuesta mayor a 300. En nuestra aplicación uWSGI anterior, enviaremos un Error 500 que será interceptado por Nginx.

proxy_hide_header es bastante autoexplicativo; ocultará cualquier encabezado HTTP especificado del cliente.

Si enviamos una solicitud GET normal, Nginx devolverá:

HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 34
Connection: close

Pero si enviamos una solicitud HTTP inválida, como:

GET /? XTTP/1.1
Host: 127.0.0.1
Connection: close

Obtendremos la siguiente respuesta:

XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret-info

Secret info, should not be visible!

merge_slashes establecido en off

La directiva merge_slashes está establecida en "on" de forma predeterminada, lo cual es un mecanismo para comprimir dos o más barras diagonales en una sola, por lo que /// se convertiría en /. Si Nginx se utiliza como un proxy inverso y la aplicación que se está proxyando es vulnerable a la inclusión local de archivos, el uso de barras diagonales adicionales en la solicitud podría dejar espacio para explotarla. Esto se describe en detalle por Danny Robinson y Rotem Bar.

Encontramos 33 archivos de configuración de Nginx con merge_slashes establecido en "off".

default no está especificado para la directiva map

Parece ser un caso común cuando map se utiliza para algún tipo de control de autorización. Un ejemplo simplificado podría ser:

http {
...
map $uri $mappocallow {
/map-poc/private 0;
/map-poc/secret 0;
/map-poc/public 1;
}
...
}

server {
...
location /map-poc {
if ($mappocallow = 0) {return 403;}
return 200 "Hello. It is private area: $mappocallow";
}
...
}

Según el manual:

valor por defecto
establece el valor resultante si el valor de origen no coincide con ninguno de los variantes especificados. Cuando no se especifica un valor por defecto,
el valor resultante por defecto será una cadena vacía.

Es fácil olvidarse del valor default. Por lo tanto, un malhechor puede evadir este "control de autorización" simplemente accediendo a un caso inexistente dentro de /map-poc como https://targethost.com/map-poc/another-private-area.

Suplantación de DNS en Nginx

Según esta publicación: http://blog.zorinaq.com/nginx-resolver-vulns/ Podría ser posible suplantar registros DNS en Nginx si conoces el servidor DNS que Nginx está utilizando (y puedes interceptar de alguna manera la comunicación, por lo que esto no es válido si se utiliza 127.0.0.1) y el dominio que está solicitando.

Nginx puede especificar un servidor DNS para usar con:

resolver     8.8.8.8;

Directivas proxy_pass e internal

La directiva proxy_pass se puede utilizar para redirigir internamente las solicitudes a otros servidores internos o externos.
La directiva internal se utiliza para dejar claro a Nginx que la ubicación solo se puede acceder internamente.

El uso de estas directivas no es una vulnerabilidad, pero se debe verificar cómo están configuradas.

proxy_set_header Upgrade & Connection

Si el servidor nginx está configurado para pasar los encabezados Upgrade y Connection, se podría realizar un ataque de h2c Smuggling para acceder a puntos finales protegidos/internos.

{% hint style="danger" %} Esta vulnerabilidad permitiría a un atacante establecer una conexión directa con el punto final proxy_pass (http://backend:9999 en este caso) cuyo contenido no será verificado por nginx. {% endhint %}

Ejemplo de configuración vulnerable para robar /flag de aquí:

server {
listen       443 ssl;
server_name  localhost;

ssl_certificate       /usr/local/nginx/conf/cert.pem;
ssl_certificate_key   /usr/local/nginx/conf/privkey.pem;

location / {
proxy_pass http://backend:9999;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
}

location /flag {
deny all;
}

{% hint style="warning" %} Ten en cuenta que incluso si proxy_pass apunta 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 punto final interno. Por lo tanto, no importa si se especifica una ruta en la URL de proxy_pass. {% endhint %}

Pruébalo tú mismo

Detectify ha creado un repositorio en GitHub donde puedes usar Docker para configurar tu propio servidor de prueba vulnerable de Nginx con algunas de las configuraciones incorrectas discutidas en este artículo y tratar de encontrarlas tú mismo.

https://github.com/detectify/vulnerable-nginx

Herramientas de análisis estático

GIXY

Gixy es una herramienta para analizar la configuración de Nginx. El objetivo principal de Gixy es prevenir la configuración incorrecta de seguridad y automatizar la detección de fallas.

Nginxpwner

Nginxpwner es una herramienta sencilla para buscar configuraciones incorrectas comunes y vulnerabilidades de Nginx.

Referencias

DragonJAR Security Conference es un evento internacional de ciberseguridad con más de una década que se celebrará el 7 y 8 de septiembre de 2023 en Bogotá, Colombia. Es un evento de gran contenido técnico donde se presentan las últimas investigaciones en español que atrae a hackers e investigadores de todo el mundo.
¡Regístrate ahora en el siguiente enlace y no te pierdas esta gran conferencia!:

{% embed url="https://www.dragonjarcon.org/" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥