mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-27 07:01:09 +00:00
312 lines
19 KiB
Markdown
312 lines
19 KiB
Markdown
# Nginx
|
||
|
||
<details>
|
||
|
||
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||
|
||
* Travaillez-vous dans une **entreprise de cybersécurité** ? Voulez-vous voir votre **entreprise annoncée dans HackTricks** ? Ou voulez-vous avoir accès à la **dernière version de PEASS ou télécharger HackTricks en PDF** ? Consultez les [**PLANS D'ABONNEMENT**](https://github.com/sponsors/carlospolop) !
|
||
* Découvrez [**La famille PEASS**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFT**](https://opensea.io/collection/the-peass-family)
|
||
* Obtenez le [**swag officiel PEASS & HackTricks**](https://peass.creator-spring.com)
|
||
* **Rejoignez le** [**💬**](https://emojipedia.org/speech-balloon/) [**groupe Discord**](https://discord.gg/hRep4RUj7f) ou le [**groupe Telegram**](https://t.me/peass) ou **suivez** moi sur **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Partagez vos astuces de piratage en soumettant des PR au** [**repo hacktricks**](https://github.com/carlospolop/hacktricks) **et au** [**repo hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
||
|
||
</details>
|
||
|
||
<figure><img src="../../.gitbook/assets/image (1) (1) (2) (4).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
[**DragonJAR Security Conference es un evento internacional de ciberseguridad**](https://www.dragonjarcon.org/) avec plus d'une décennie qui se tiendra les 7 et 8 septembre 2023 à Bogotá, Colombie. C'est un événement de contenu technique de haut niveau où les dernières recherches en espagnol sont présentées, attirant des hackers et des chercheurs du monde entier.\
|
||
Inscrivez-vous dès maintenant en suivant le lien ci-dessous et ne manquez pas cette grande conférence !:
|
||
|
||
{% embed url="https://www.dragonjarcon.org/" %}
|
||
|
||
## Emplacement racine manquant <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 directive root spécifie le dossier racine pour Nginx. Dans l'exemple ci-dessus, le dossier racine est `/etc/nginx`, ce qui signifie que nous pouvons accéder aux fichiers dans ce dossier. La configuration ci-dessus n'a pas de localisation pour `/ (location / {...})`, seulement pour `/hello.txt`. En raison de cela, la directive `root` sera définie globalement, ce qui signifie que les requêtes vers `/` vous amèneront au chemin local `/etc/nginx`.
|
||
|
||
Une requête aussi simple que `GET /nginx.conf` révélerait le contenu du fichier de configuration Nginx stocké dans `/etc/nginx/nginx.conf`. Si la racine est définie sur `/etc`, une requête `GET` vers `/nginx/nginx.conf` révélerait le fichier de configuration. Dans certains cas, il est possible d'accéder à d'autres fichiers de configuration, journaux d'accès et même à des informations d'identification chiffrées pour l'authentification de base HTTP.
|
||
|
||
## Mauvaise configuration LFI avec Alias <a href="#alias-lfi-misconfiguration" id="alias-lfi-misconfiguration"></a>
|
||
|
||
Dans la configuration Nginx, recherchez les déclarations "location", si l'une d'entre elles ressemble à :
|
||
```
|
||
location /imgs {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
Il existe une vulnérabilité LFI car:
|
||
```
|
||
/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 forward requests to.
|
||
|
||
## 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 the backend servers and the load balancing algorithm to use.
|
||
|
||
## 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.
|
||
|
||
## 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 secure Nginx is essential for effective web application deployment and maintenance.
|
||
```
|
||
/path/images/../flag.txt
|
||
```
|
||
La configuration correcte sera la suivante :
|
||
```
|
||
location /imgs/ {
|
||
alias /path/images/;
|
||
}
|
||
```
|
||
**Donc, si vous trouvez un serveur Nginx, vous devriez vérifier cette vulnérabilité. De plus, vous pouvez la découvrir si vous constatez que la force brute des fichiers/répertoires se comporte de manière étrange.**
|
||
|
||
Plus d'informations: [https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/](https://www.acunetix.com/vulnerabilities/web/path-traversal-via-misconfigured-nginx-alias/)
|
||
|
||
Tests 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
|
||
```
|
||
## Restriction de chemin non sécurisée <a href="#utilisation-de-variable-non-sécurisée" id="utilisation-de-variable-non-sécurisée"></a>
|
||
|
||
Consultez la page suivante pour apprendre comment contourner les directives telles que :
|
||
```plaintext
|
||
location = /admin {
|
||
deny all;
|
||
}
|
||
|
||
location = /admin/ {
|
||
deny all;
|
||
}
|
||
```
|
||
## Utilisation non sécurisée des variables <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
|
||
|
||
Un exemple de configuration Nginx vulnérable est le suivant :
|
||
```
|
||
location / {
|
||
return 302 https://example.com$uri;
|
||
}
|
||
```
|
||
Les caractères de nouvelle ligne pour les requêtes HTTP sont \r (retour chariot) et \n (saut de ligne). L'encodage URL des caractères de nouvelle ligne donne la représentation suivante des caractères `%0d%0a`. Lorsque ces caractères sont inclus dans une requête comme `http://localhost/%0d%0aDetectify:%20clrf` vers un serveur avec une mauvaise configuration, le serveur répondra avec un nouvel en-tête nommé `Detectify` car la variable $uri contient les caractères de nouvelle ligne décodés.
|
||
```
|
||
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
|
||
```
|
||
En savoir plus sur les risques d'injection CRLF et de fractionnement de réponse sur [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/).
|
||
|
||
### Toute variable
|
||
|
||
Dans certains cas, les données fournies par l'utilisateur peuvent être traitées comme une variable Nginx. Il n'est pas clair pourquoi cela peut se produire, mais ce n'est pas si rare ou facile à tester comme le montre ce [rapport H1](https://hackerone.com/reports/370094). Si nous recherchons le message d'erreur, nous pouvons voir qu'il se trouve dans le [module de filtre SSI](https://github.com/nginx/nginx/blob/2187586207e1465d289ae64cedc829719a048a39/src/http/modules/ngx\_http\_ssi\_filter\_module.c#L365), révélant ainsi que cela est dû à SSI.
|
||
|
||
Une façon de tester cela est de définir une valeur d'en-tête referer :
|
||
```
|
||
$ curl -H ‘Referer: bar’ http://localhost/foo$http_referer | grep ‘foobar’
|
||
```
|
||
Nous avons scanné cette mauvaise configuration et trouvé plusieurs instances où un utilisateur pouvait afficher la valeur des variables Nginx. Le nombre d'instances vulnérables trouvées a diminué, ce qui pourrait indiquer qu'elles ont été corrigées.
|
||
|
||
## Lecture brute de la réponse du backend
|
||
|
||
Avec `proxy_pass` de Nginx, il est possible d'intercepter les erreurs et les en-têtes HTTP créés par le backend. Cela est très utile si vous souhaitez masquer les messages d'erreur et les en-têtes internes afin qu'ils soient gérés par Nginx. Nginx servira automatiquement une page d'erreur personnalisée si le backend en renvoie une. Mais que se passe-t-il si Nginx ne comprend pas qu'il s'agit d'une réponse HTTP ?
|
||
|
||
Si un client envoie une requête HTTP invalide à Nginx, cette requête sera transmise telle quelle au backend, qui répondra avec son contenu brut. Ensuite, Nginx ne comprendra pas la réponse HTTP invalide et la transmettra simplement au client. Imaginez une application uWSGI comme celle-ci :
|
||
```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!"]
|
||
```
|
||
Et avec les directives suivantes dans 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) servira une réponse personnalisée si le backend renvoie un code de statut supérieur à 300. Dans notre application uWSGI ci-dessus, nous enverrons une `Erreur 500` qui sera interceptée par Nginx.
|
||
|
||
[proxy\_hide\_header](http://nginx.org/en/docs/http/ngx\_http\_proxy\_module.html#proxy\_hide\_header) est assez explicite ; il masquera tout en-tête HTTP spécifié du client.
|
||
|
||
Si nous envoyons une requête `GET` normale, Nginx renverra :
|
||
```
|
||
HTTP/1.1 500 Internal Server Error
|
||
Server: nginx/1.10.3
|
||
Content-Type: text/html
|
||
Content-Length: 34
|
||
Connection: close
|
||
```
|
||
Mais si nous envoyons une requête HTTP invalide, telle que :
|
||
```
|
||
GET /? XTTP/1.1
|
||
Host: 127.0.0.1
|
||
Connection: close
|
||
```
|
||
Nous obtiendrons la réponse suivante :
|
||
```
|
||
XTTP/1.1 500 Error
|
||
Content-Type: text/html
|
||
Secret-Header: secret-info
|
||
|
||
Secret info, should not be visible!
|
||
```
|
||
## merge\_slashes défini sur off
|
||
|
||
La directive [merge\_slashes](http://nginx.org/en/docs/http/ngx\_http\_core\_module.html#merge\_slashes) est définie par défaut sur "on", ce qui est un mécanisme pour compresser deux ou plusieurs barres obliques en une seule, donc `///` deviendrait `/`. Si Nginx est utilisé en tant que reverse-proxy et que l'application qui est proxy est vulnérable à une inclusion de fichier local, l'utilisation de barres obliques supplémentaires dans la requête pourrait laisser place à une exploitation. Cela est décrit en détail par [Danny Robinson et Rotem Bar](https://medium.com/appsflyer/nginx-may-be-protecting-your-applications-from-traversal-attacks-without-you-even-knowing-b08f882fd43d).
|
||
|
||
Nous avons trouvé 33 fichiers de configuration Nginx avec `merge_slashes` défini sur "off".
|
||
|
||
## default n'est pas spécifié pour la directive map
|
||
|
||
Il semble que ce soit un cas courant lorsque **`map` est utilisé pour un certain type de contrôle d'autorisation**. Un exemple simplifié pourrait ressembler à :
|
||
```
|
||
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";
|
||
}
|
||
...
|
||
}
|
||
```
|
||
[Selon le manuel](https://nginx.org/en/docs/http/ngx\_http\_map\_module.html):
|
||
|
||
> valeur par défaut\
|
||
> définit la valeur résultante si la valeur source ne correspond à aucune des variantes spécifiées. Lorsque la valeur par défaut n'est pas spécifiée, la valeur résultante par défaut sera une chaîne vide.
|
||
|
||
Il est facile d'oublier la valeur `par défaut`. Ainsi, **un malfaiteur peut contourner ce "contrôle d'autorisation"** en accédant simplement à un **cas inexistant dans `/map-poc`** comme `https://targethost.com/map-poc/another-private-area`.
|
||
|
||
## Spoofing DNS Nginx
|
||
|
||
Selon cet article: [http://blog.zorinaq.com/nginx-resol**ver-vulns/**](http://blog.zorinaq.com/nginx-resolver-vulns/) **Il pourrait être possible de falsifier les enregistrements DNS** pour Nginx si vous **connaissez le serveur DNS utilisé par Nginx** (et que vous pouvez intercepter d'une manière ou d'une autre la communication, donc cela **n'est pas valable si 127.0.0.1** est utilisé) et le **domaine qu'il demande**.
|
||
|
||
Nginx peut spécifier un serveur DNS à utiliser avec:
|
||
```
|
||
resolver 8.8.8.8;
|
||
```
|
||
## Directives `proxy_pass` et `internal`
|
||
|
||
La directive **`proxy_pass`** peut être utilisée pour **rediriger les requêtes internes vers d'autres serveurs**, internes ou externes.\
|
||
La directive **`internal`** est utilisée pour indiquer clairement à Nginx que **la localisation ne peut être accédée que de manière interne**.
|
||
|
||
L'utilisation de ces directives **n'est pas une vulnérabilité, mais vous devriez vérifier comment elles sont configurées**.
|
||
|
||
## proxy\_set\_header Upgrade & Connection
|
||
|
||
Si le serveur nginx est configuré pour transmettre les en-têtes Upgrade et Connection, une [**attaque d'h2c Smuggling**](../../pentesting-web/h2c-smuggling.md) pourrait être effectuée pour accéder à des points de terminaison protégés/internes.
|
||
|
||
{% hint style="danger" %}
|
||
Cette vulnérabilité permettrait à un attaquant d'**établir une connexion directe avec le point de terminaison `proxy_pass`** (`http://backend:9999` dans ce cas) dont le contenu ne sera pas vérifié par nginx.
|
||
{% endhint %}
|
||
|
||
Exemple de configuration vulnérable pour voler `/flag` à partir de [ici](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" %}
|
||
Notez que même si `proxy_pass` pointait vers un **chemin** spécifique tel que `http://backend:9999/socket.io`, la connexion sera établie avec `http://backend:9999`, vous pouvez donc **contacter n'importe quel autre chemin à l'intérieur de ce point de terminaison interne. Il n'est donc pas important qu'un chemin soit spécifié dans l'URL de proxy\_pass.**
|
||
{% endhint %}
|
||
|
||
## Essayez par vous-même
|
||
|
||
Detectify a créé un référentiel GitHub où vous pouvez utiliser Docker pour configurer votre propre serveur de test Nginx vulnérable avec certaines des mauvaises configurations discutées dans cet article et essayer de les trouver vous-même !
|
||
|
||
[https://github.com/detectify/vulnerable-nginx](https://github.com/detectify/vulnerable-nginx)
|
||
|
||
## Outils d'analyse statique
|
||
|
||
### [GIXY](https://github.com/yandex/gixy)
|
||
|
||
Gixy est un outil d'analyse de la configuration Nginx. L'objectif principal de Gixy est de prévenir les mauvaises configurations de sécurité et d'automatiser la détection des failles.
|
||
|
||
### [Nginxpwner](https://github.com/stark0de/nginxpwner)
|
||
|
||
Nginxpwner est un outil simple pour rechercher les mauvaises configurations courantes et les vulnérabilités de Nginx.
|
||
|
||
## Références
|
||
|
||
* [**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 (1) (1) (2) (4).png" alt=""><figcaption></figcaption></figure>
|
||
|
||
[**DragonJAR Security Conference es un evento internacional de ciberseguridad**](https://www.dragonjarcon.org/) 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/" %}
|
||
|
||
<details>
|
||
|
||
<summary><a href="https://cloud.hacktricks.xyz/pentesting-cloud/pentesting-cloud-methodology"><strong>☁️ HackTricks Cloud ☁️</strong></a> -<a href="https://twitter.com/hacktricks_live"><strong>🐦 Twitter 🐦</strong></a> - <a href="https://www.twitch.tv/hacktricks_live/schedule"><strong>🎙️ Twitch 🎙️</strong></a> - <a href="https://www.youtube.com/@hacktricks_LIVE"><strong>🎥 Youtube 🎥</strong></a></summary>
|
||
|
||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
|
||
|
||
</details>
|