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

271 lines
17 KiB
Markdown
Raw Normal View History

2022-05-08 23:13:03 +00:00
# Nginx
2022-04-28 16:01:33 +00:00
<details>
2023-04-25 18:35:28 +00:00
<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>
2022-04-28 16:01:33 +00:00
2023-06-03 13:10:46 +00:00
* 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 [**The PEASS Family**](https://opensea.io/collection/the-peass-family), notre collection exclusive de [**NFTs**](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).
2022-04-28 16:01:33 +00:00
</details>
2022-04-28 16:01:33 +00:00
<figure><img src="../../.gitbook/assets/image (1) (1) (2) (4).png" alt=""><figcaption></figcaption></figure>
2022-04-28 16:01:33 +00:00
[**DragonJAR Security Conference est un événement international de cybersécurité**](https://www.dragonjarcon.org/) avec plus d'une décennie qui se tiendra les 7 et 8 septembre 2023 à Bogotá, en 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.\
2023-06-03 13:10:46 +00:00
Inscrivez-vous dès maintenant sur le lien suivant et ne manquez pas cette grande conférence !:
2022-04-28 16:01:33 +00:00
{% embed url="https://www.dragonjarcon.org/" %}
2022-04-28 16:01:33 +00:00
2023-06-03 13:10:46 +00:00
## 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/;
}
}
```
2023-06-03 13:10:46 +00:00
La directive racine 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 d'emplacement pour `/ (location / {...})`, seulement pour `/hello.txt`. En raison de cela, la directive `root` sera définie globalement, ce qui signifie que les demandes à `/` vous amèneront au chemin local `/etc/nginx`.
Une demande 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 demande `GET` à `/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.
## Configuration incorrecte de LFI 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/;
}
```
2023-06-03 13:10:46 +00:00
Il y a une vulnérabilité LFI car:
```
/imgs../flag.txt
```
Le contenu suivant provient d'un livre de piratage sur les techniques de piratage. Le contenu suivant provient du fichier network-services-pentesting/pentesting-web/nginx.md. Traduisez le texte anglais pertinent en français et renvoyez la traduction en conservant la syntaxe markdown. Ne traduisez pas les choses comme le code, les noms de techniques de piratage, les mots de piratage, les noms de plateformes cloud/SaaS (comme Workspace, aws, gcp...), le mot 'leak', pentesting et les balises markdown. N'ajoutez également rien d'autre que la traduction et la syntaxe markdown.
```
/path/images/../flag.txt
```
2023-06-03 13:10:46 +00:00
La configuration correcte sera :
```
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.
2023-06-03 13:10:46 +00:00
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
```
2023-06-03 13:10:46 +00:00
## Utilisation non sécurisée de variables <a href="#unsafe-variable-use" id="unsafe-variable-use"></a>
2023-06-03 13:10:46 +00:00
Un exemple de configuration Nginx vulnérable est :
```
location / {
return 302 https://example.com$uri;
}
```
2023-06-03 13:10:46 +00:00
Les caractères de nouvelle ligne pour les requêtes HTTP sont \r (Retour chariot) et \n (Saut de ligne). L'encodage d'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 telle que `http://localhost/%0d%0aDetectify:%20clrf` à 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 de l'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
```
2023-06-03 13:10:46 +00:00
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/).
2023-06-03 13:10:46 +00:00
### N'importe quelle variable
2023-06-03 13:10:46 +00:00
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 on peut le voir dans 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, révélant ainsi que cela est dû à SSI.
2023-06-03 13:10:46 +00:00
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
```
2023-06-03 13:10:46 +00:00
Nous avons scanné cette mauvaise configuration et avons trouvé plusieurs instances où un utilisateur pouvait imprimer la valeur des variables Nginx. Le nombre d'instances vulnérables trouvées a diminué, ce qui pourrait indiquer que cela a été corrigé.
2023-06-03 13:10:46 +00:00
## Lecture brute de la réponse du backend
2023-06-03 13:10:46 +00:00
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 voulez 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 répond avec une telle page. Mais que se passe-t-il si Nginx ne comprend pas qu'il s'agit d'une réponse HTTP ?
2023-06-03 13:10:46 +00:00
Si un client envoie une requête HTTP invalide à Nginx, cette requête sera transmise telle quelle au backend, et le backend 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 :
2022-04-11 23:27:21 +00:00
```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!"]
```
2023-06-03 13:10:46 +00:00
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` servira une réponse personnalisée si le backend a un statut de réponse supérieur à 300. Dans notre application uWSGI ci-dessus, nous enverrons une `Erreur 500` qui sera interceptée par Nginx.
2023-06-03 13:10:46 +00:00
`proxy_hide_header` est assez explicite; il masquera tout en-tête HTTP spécifié du client.
2023-06-03 13:10:46 +00:00
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
```
2023-06-03 13:10:46 +00:00
Mais si nous envoyons une requête HTTP invalide, telle que :
```
GET /? XTTP/1.1
Host: 127.0.0.1
Connection: close
```
2023-06-03 13:10:46 +00:00
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!
```
2023-06-03 13:10:46 +00:00
## 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 proxifiée est vulnérable à l'inclusion de fichiers locaux, 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).
2023-06-03 13:10:46 +00:00
Nous avons trouvé 33 fichiers de configuration Nginx avec `merge_slashes` défini sur "off".
2022-04-11 23:27:21 +00:00
2023-06-03 13:10:46 +00:00
## default n'est pas spécifié pour la directive map
2022-04-11 23:27:21 +00:00
2023-06-03 13:10:46 +00:00
Il semble que le cas commun lorsque **`map` est utilisé pour un certain type de contrôle d'autorisation**. Un exemple simplifié pourrait ressembler à:
2022-04-11 23:27:21 +00:00
```
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):
2022-04-11 23:27:21 +00:00
> valeur par défaut\
2023-06-03 13:10:46 +00:00
> 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.
2022-04-11 23:27:21 +00:00
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`.
2022-04-11 23:27:21 +00:00
2023-06-03 13:10:46 +00:00
## Spoofing DNS Nginx
2022-04-11 23:27:21 +00:00
Selon cet article: [http://blog.zorinaq.com/nginx-resolver-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 que Nginx** utilise (et vous pouvez intercepter la communication d'une manière ou d'une autre, donc cela **n'est pas valable si 127.0.0.1** est utilisé) et le **domaine qu'il demande**.
2022-04-11 23:27:21 +00:00
2023-06-03 13:10:46 +00:00
Nginx peut spécifier un serveur DNS à utiliser avec:
2022-04-11 23:27:21 +00:00
```
resolver 8.8.8.8;
```
2023-06-03 13:10:46 +00:00
## Directives `proxy_pass` et `internal`
2022-04-11 23:27:21 +00:00
La directive **`proxy_pass`** peut être utilisée pour **rediriger les demandes vers d'autres serveurs** internes ou externes.\
La directive **`internal`** est utilisée pour indiquer à Nginx que **l'emplacement ne peut être accédé qu'en interne**.
2022-04-11 23:27:21 +00:00
2023-06-03 13:10:46 +00:00
L'utilisation de ces directives **n'est pas une vulnérabilité, mais vous devriez vérifier comment elles sont configurées**.
2022-06-19 13:37:58 +00:00
## proxy\_set\_header Upgrade & Connection
2023-06-03 13:10:46 +00:00
Si le serveur nginx est configuré pour passer 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.
2022-06-19 13:37:58 +00:00
{% hint style="danger" %}
2023-06-03 13:10:46 +00:00
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.
2022-06-19 13:37:58 +00:00
{% endhint %}
2023-06-03 13:10:46 +00:00
Exemple de configuration vulnérable pour voler `/flag` à partir de [ici](https://bishopfox.com/blog/h2c-smuggling-request):
2022-06-19 13:37:58 +00:00
```
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" %}
2023-06-03 13:10:46 +00:00
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 tout 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.**
2022-06-19 13:37:58 +00:00
{% endhint %}
2023-06-03 13:10:46 +00:00
## Essayez par vous-même
2023-06-03 13:10:46 +00:00
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)
2023-06-03 13:10:46 +00:00
## Outils d'analyse statique
2022-05-08 23:13:03 +00:00
### [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.
2022-04-11 23:27:21 +00:00
2022-07-24 19:52:09 +00:00
### [Nginxpwner](https://github.com/stark0de/nginxpwner)
2023-06-03 13:10:46 +00:00
Nginxpwner est un outil simple pour rechercher les mauvaises configurations et les vulnérabilités courantes de Nginx.
2022-07-24 19:52:09 +00:00
2023-06-03 13:10:46 +00:00
## Références
2022-04-11 23:27:21 +00:00
2022-05-08 23:13:03 +00:00
* [**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)
2022-04-28 16:01:33 +00:00
<figure><img src="../../.gitbook/assets/image (1) (1) (2) (4).png" alt=""><figcaption></figcaption></figure>
2022-04-28 16:01:33 +00:00
2023-06-03 13:10:46 +00:00
[**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á, en Colombie. C'est un événement de contenu technique élevé 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 sur le lien suivant et ne manquez pas cette grande conférence!:
2022-04-28 16:01:33 +00:00
{% embed url="https://www.dragonjarcon.org/" %}
2022-04-28 16:01:33 +00:00
<details>
2022-04-28 16:01:33 +00:00
<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>
2022-04-28 16:01:33 +00:00
2023-06-03 13:10:46 +00:00
* 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 [**The PEASS Family**](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).
2022-04-28 16:01:33 +00:00
</details>