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

17 KiB
Raw Blame History

Nginx

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

DragonJAR Security Conference est un événement international de cybersécurité 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.
Inscrivez-vous dès maintenant sur le lien suivant et ne manquez pas cette grande conférence !:

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

Emplacement racine manquant 

server {
        root /etc/nginx;

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

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

Dans la configuration Nginx, recherchez les déclarations "location", si l'une d'entre elles ressemble à :

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

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

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.

Plus d'informations: 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

Utilisation non sécurisée de variables

Un exemple de configuration Nginx vulnérable est :

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 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

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/.

N'importe quelle 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 on peut le voir dans ce rapport H1. 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.

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 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é.

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 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 ?

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 :

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 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.

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 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.

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 le cas commun 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-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.

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 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.

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 passer les en-têtes Upgrade et Connection, une attaque d'h2c Smuggling 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:

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 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. {% 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

Outils d'analyse statique

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

Nginxpwner est un outil simple pour rechercher les mauvaises configurations et les vulnérabilités courantes de Nginx.

Références

DragonJAR Security Conference es un evento internacional de ciberseguridad 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!:

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

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