How to HACK Nginx

Nginx is being used in the wild since a while now. We all have seen NGINX name somewhere while coding/hacking. NGINX has always been a target for hackers/bug bounty hunters due to a lot of misconfigurations in it, and as a security researcher/bug bounty hunter, hacking a web server always fascinates us. Today we will see how we can ACTUALLY hack a NGINX if it is vulnerable, and try to pick some bucks from it.

Well, if you are new to this topic, and somehow don’t know how NGINX as a server works, here is a description from internet:-

“Nginx is built to offer low memory usage and high concurrency. Rather than creating new processes for each web request, Nginx uses an asynchronous, event-driven approach where requests are handled in a single thread. With Nginx, one master process can control multiple worker processes. The master maintains the worker processes, while the workers do the actual processing. Because Nginx is asynchronous, each request can be executed by the worker concurrently without blocking other requests.”
You can obviously do a lot of stuff with the help of NGINX:-

• Reverse proxy with caching
• IPv6
• Load balancing
• FastCGI support with caching
• WebSockets
• Handling of static files, index files, and auto-indexing

So once we are clear how it works, our topics start..and the point is in which phase misconfigurations happen? Well, there are lot of things which can go other way if we don’t configure it properly. If you will go back in history, NGINX SPDY heap buffer overflow was exploited in 2014. To exploit this, the attacker can execute arbitrary code by specially crafting a request to cause a heap memory buffer overflow. This would gravely affect the web server. Also in 2020, PHP Remote Code Execution Vulnerability was found in NGINX which was severe and it was considered one of the most critical findings in this product ever. You can read more about them on internet. I leave it on you.

Since NGINX is the most common web server which is used these days, a lot of security issues are there too. We are talking about these today:-

• Missing root location
• Alias LFI Misconfiguration
• Raw backend response reading
• Unsafe variable use

1. Missing root location:-

Check the below code snippet:-

`server {
root /etc/nginx;

location /hack.txt {
try_files $uri $uri/ =404;
proxy_pass http://127.0.0.1:1212/;
}
}
`
In NGINX, root directive specifies the root folder. In this example, root file is defined as /etc/nginx, it means that we can go ahead look upto nginx and files within it. So here if you will send a simple request like GET /nginx.conf it will reveal some sensitive info such as configuration of nginx and other stuff. Since “/” can handle any request, we can send a sensitive endpoint through it. In some cases it is possible to reach other configuration files and access logs.

2. Alias LFI Misconfiguration:-

It is always recommended to check “location” statements under NGINX configuration. If you find something like:-

location /imgs {
alias /path/images/
}

You can go ahead and perform a LFI here. How? Expand it to /imgs../secret.txt and it will transform to /path/images/../secret.txt. You can read more about it here:- LFI/Path traversal.

3. Raw backend response reading:-

With Nginx’s proxy_pass, there’s the possibility to intercept errors and HTTP headers created by the backend. This is very useful if you want to hide internal error messages and headers so they are instead handled by Nginx. Nginx will automatically serve a custom error page if the backend answers with one.
Imagine there is an application like this:-

And it has following directives in NGINX:-

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

So if we send a simple GET request, our response will be something like this:-

HTTP/1.1 500 Internal Server Error
Server: nginx/1.10.3
Content-Type: text/html
Content-Length: 15
Connection: close

But what if we try to send an invalid request and check what happens next? Something like this:-

GET /? XTTP/1.1
Host: 127.0.0.1
Connection: close

If its vulnerable we should get a response with secret info:-

XTTP/1.1 500 Error
Content-Type: text/html
Secret-Header: secret

4. Unsafe variable use:-

A vulnerable NGINX configuration will look like this:-

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

The new line characters for HTTP requests are \r (Carriage Return) and \n (Line Feed). URL-encoding the new line characters results in the following representation of the characters %0d%0a. When these characters are included in a request like http://localhost/%0d%0aHacker:%20test to a server with the misconfiguration, the server will respond with a new header named HACKER 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: 200
Connection: keep-alive
Location: https://abcd.com/
Hacker: test

- proxy_pass and internal directives:-

The proxy_pass directive can be used to redirect internally requests to other servers internal or external. The internal directive is used to make it clear to Nginx that the location can only be accessed internally.

These were some common attack scenarios which arise in NGINX. There are obviously a lot of buffer overflows reported in this product, and it is always recommended to check everything which you can do on a particular server. Since NGINX is used as a load balancer as well, DOS is also possible there. However, the more they update the product, old vulns are getting vanished there. Since it is being used a lot, chances are new vulnerabilities will arise.

I hope you got something from this blog. Old folks know a lot of things, which are mentioned in this blog, are already available in this blog, so not a lot for those guys. But if you are new, you will surely get some good knowledge from it. I hope it helps you to learn a couple of things.

Now ready to hack.