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

19 KiB
Raw Blame History

Nginx

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

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

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

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/

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

Consultez la page suivante pour apprendre comment contourner les directives telles que :

location = /admin {
deny all;
}

location = /admin/ {
deny all;
}

Utilisation non sécurisée des variables

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

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

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

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:

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

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 courantes et les vulnérabilités de Nginx.

Références

DragonJAR Security Conference es un evento internacional de ciberseguridad 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/" %}

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