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

18 KiB
Raw Blame History

Nginx

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Configuración disponible al instante para evaluación de vulnerabilidades y pentesting. Realiza un pentest completo desde cualquier lugar con más de 20 herramientas y características que van desde el reconocimiento hasta la elaboración de informes. No reemplazamos a los pentesters: desarrollamos herramientas personalizadas, módulos de detección y explotación para darles más tiempo para profundizar, obtener shells y divertirse.

{% embed url="https://pentest-tools.com/" %}

Falta de ubicación root 

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 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á globalmente, 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 está configurada 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 HTTP.

Configuración errónea 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 LFI porque:

/imgs../flag.txt

# Pentesting Nginx

## Enumeración

La enumeración es el primer paso en el pentesting de servicios web como Nginx. Utiliza herramientas como `Nmap` y `Nikto` para identificar versiones de servicios y posibles vulnerabilidades.

### Versiones

Determinar la versión de Nginx puede ayudar a identificar vulnerabilidades específicas. Usa el comando `nmap -sV <target>` para obtener la versión.

### Configuración por defecto

La configuración por defecto de Nginx puede contener debilidades. Revisa los archivos de configuración en busca de errores comunes como permisos incorrectos o configuraciones inseguras.

## Explotación

Una vez identificadas las vulnerabilidades, el siguiente paso es la explotación. Existen varias técnicas para explotar Nginx.

### Desbordamiento de búfer

Los desbordamientos de búfer pueden causar condiciones de denegación de servicio o ejecución de código remoto. Investiga si la versión de Nginx es susceptible a este tipo de ataque.

### Inyección de comandos

La inyección de comandos puede permitir la ejecución de comandos arbitrarios en el servidor. Busca puntos de entrada como formularios web o parámetros de URL que no estén debidamente sanitizados.

## Post-explotación

Después de obtener acceso, la fase de post-explotación implica acciones como mantener el acceso y extraer datos.

### Mantener el acceso

Para mantener el acceso, los atacantes pueden instalar puertas traseras o utilizar técnicas de persistencia.

### Extracción de datos

La extracción de datos puede incluir la obtención de bases de datos, archivos de configuración y otros datos sensibles.

## Mitigación

La mitigación de riesgos es crucial para protegerse contra ataques a Nginx.

### Actualizaciones

Mantén Nginx actualizado para protegerte contra vulnerabilidades conocidas.

### Configuración segura

Implementa una configuración segura, incluyendo permisos adecuados y el uso de módulos de seguridad.

### Monitoreo

Monitorea los registros y el tráfico de red para detectar actividad sospechosa.

## Herramientas

- `Nmap`: Escaneo de puertos y servicios.
- `Nikto`: Escaneo de vulnerabilidades web.
- `Metasploit`: Marco de trabajo para explotación de vulnerabilidades.

## Conclusión

El pentesting de Nginx requiere un enfoque metódico para identificar y explotar vulnerabilidades. La mitigación efectiva depende de la actualización constante, configuraciones seguras y monitoreo proactivo.

/path/images/../flag.txt

La configuración correcta será:

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

Por lo tanto, si encuentras algún servidor Nginx, debes verificar si tiene esta vulnerabilidad. También puedes descubrirla si notas que el 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 Acunetix:

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

Consulta la siguiente página para aprender cómo sortear directivas como:

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

{% content-ref url="../../pentesting-web/proxy-waf-protections-bypass.md" %}
[proxy-waf-protections-bypass.md](../../pentesting-web/proxy-waf-protections-bypass.md)
{% endcontent-ref %}

## Uso inseguro de variables <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>

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 (Avance de Línea). La codificación 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 mala configuración, el servidor responderá con un nuevo encabezado llamado Detectify ya que la variable $uri contiene los caracteres de nueva línea decodificados por 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 CRLF y la división de respuesta en https://blog.detectify.com/2019/06/14/http-response-splitting-exploitations-and-mitigations/.

Cualquier variable

En algunos casos, los datos suministrados por el usuario pueden ser tratados como una variable de Nginx. No está claro por qué puede estar sucediendo esto, pero no es tan inusual ni fácil de probar como se ve en este informe 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 en busca de esta mala configuración 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 del backend cruda

Con proxy_pass de Nginx, existe la posibilidad de interceptar errores y encabezados HTTP creados por el backend. Esto es muy útil si quieres ocultar mensajes de error internos y encabezados para que en su lugar sean manejados por Nginx. Nginx servirá automáticamente una página de error personalizada si el backend responde con una. Pero, ¿qué pasa 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 crudo. Entonces, 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 al 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

Recibiremos la siguiente respuesta:

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

Secret info, should not be visible!

merge_slashes configurado en off

La directiva merge_slashes está configurada en "on" por defecto, lo cual es un mecanismo para comprimir dos o más barras inclinadas en una, de modo que /// se convertiría en /. Si Nginx se utiliza como un proxy inverso y la aplicación que está siendo proxy es vulnerable a la inclusión de archivos locales, usar barras extras en la solicitud podría dejar espacio para explotarlo. Esto está descrito en detalle por Danny Robinson y Rotem Bar.

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

no se especifica el valor por defecto 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 ninguna de las variantes especificadas. Cuando no se especifica el valor por defecto,
el valor resultante por defecto será una cadena vacía.

Es fácil olvidar el valor default. Así que un malhechor puede eludir este "control de autorización" simplemente accediendo a un caso inexistente dentro de /map-poc como https://targethost.com/map-poc/another-private-area.

DNS Spoofing en Nginx

Según este post: http://blog.zorinaq.com/nginx-resolver-vulns/ Podría ser posible falsificar 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 usa 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 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 deberías 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 contrabando h2c 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 de proxy_pass (http://backend:9999 en este caso) cuyo contenido no va a ser revisado 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" %} Tenga en cuenta que incluso si el proxy_pass apuntaba a un camino específico como http://backend:9999/socket.io la conexión se establecerá con http://backend:9999 por lo que puede contactar cualquier otro camino dentro de ese punto final interno. Por lo tanto, no importa si se especifica un camino en la URL de proxy_pass. {% endhint %}

Pruébelo usted mismo

Detectify ha creado un repositorio de GitHub donde puede usar Docker para configurar su propio servidor de prueba Nginx vulnerable con algunas de las desconfiguraciones discutidas en este artículo y ¡intentar encontrarlas usted 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 desconfiguraciones de seguridad y automatizar la detección de fallos.

Nginxpwner

Nginxpwner es una herramienta simple para buscar desconfiguraciones y vulnerabilidades comunes de Nginx.

Referencias

Configuración inmediatamente disponible para evaluación de vulnerabilidades y pentesting. Ejecute un pentest completo desde cualquier lugar con más de 20 herramientas y características que van desde el reconocimiento hasta la elaboración de informes. No reemplazamos a los pentesters - desarrollamos herramientas personalizadas, módulos de detección y explotación para darles más tiempo para profundizar, obtener shells y divertirse.

{% embed url="https://pentest-tools.com/" %}

Aprenda hacking de AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks: