hacktricks/network-services-pentesting/pentesting-web/nginx.md

# Nginx

<details>

<summary><strong>Aprende hacking en AWS de cero a héroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Otras formas de apoyar a HackTricks:

* Si quieres ver a tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF**, consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Consigue el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de github de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>

<figure><img src="/.gitbook/assets/image (2).png" alt=""><figcaption></figcaption></figure>

**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 <a href="#missing-root-location" id="missing-root-location"></a>
```
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 <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>

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
```
```markdown
# 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/](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 <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>

Consulta la siguiente página para aprender cómo sortear directivas como:
```plaintext
location = /admin {
deny all;
}

location = /admin/ {
deny all;
}
```
```markdown
{% 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/](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](https://hackerone.com/reports/370094). Si buscamos el mensaje de error, podemos ver que se encuentra en el [módulo de filtro SSI](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx_http_ssi_filter_module.c#L365), 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:
```python
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](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#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](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#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](http://nginx.org/en/docs/http/ngx\_http\_core\_module.html#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](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).

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](https://nginx.org/en/docs/http/ngx_http_map_module.html):

> 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/](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**](../../pentesting-web/h2c-smuggling.md) 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í](https://bishopfox.com/blog/h2c-smuggling-request):
```
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](https://github.com/detectify/vulnerable-nginx)

## Herramientas de análisis estático

### [GIXY](https://github.com/yandex/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](https://github.com/stark0de/nginxpwner)

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

## Referencias

* [**https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/**](https://blog.detectify.com/2020/11/10/common-nginx-misconfigurations/)
* [**http://blog.zorinaq.com/nginx-resolver-vulns/**](http://blog.zorinaq.com/nginx-resolver-vulns/)
* [**https://github.com/yandex/gixy/issues/115**](https://github.com/yandex/gixy/issues/115)

<figure><img src="/.gitbook/assets/image (2).png" alt=""><figcaption></figcaption></figure>

**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/" %}

<details>

<summary><strong>Aprenda hacking de AWS de cero a héroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>

Otras formas de apoyar a HackTricks:

* Si desea ver su **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulte los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtenga el [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Únase al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **sígame** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Comparta sus trucos de hacking enviando PRs a los repositorios de GitHub de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).

</details>