Reverse proxies offer several advantages in web architecture and application deployment. They sit in front of web servers, forward requests and help increase security, performance, and reliability. Reverse proxies can help implement security validations and IP whitelisting, add HTTP security response headers, implement HTTPS connectivity, implement caching, implement network load balancing that spreads heavy loads into several backend servers, and more.
However, with great power comes great responsibility: Reverse proxies increase the attack surface of organizations, and one new attacking technique threatens the number one most popular reverse proxy, Nginx. This attack is called Frontend Server Hijacking or FrontJacking for short, and it was presented at the most recent Hack in Paris and OWASP Dublin global event conferences.
What is FrontJacking?
FrontJacking is a hacking technique that combines CRLF injection, HTTP request header injection, and XSS. This technique exploits a web interface deployed in a shared hosting environment and published via a poorly configured Nginx reverse proxy. The vulnerable configuration allows attackers to inject a new host header, hijack the execution flow and the frontend reverse proxy server, and replace the website’s accessed backend server with an attacker-controlled server. This basically allows attackers to show malicious content to the unsuspecting user.
For example, a regular Nginx reverse proxy configuration looks like this:
The backend server address is 52.27.77.148 and the requests are passed to it.
However, one can also create a very similar configuration with the $uri and $document_uri variables:
These variables are supposed to concatenate query parameters into the request sent to the backend server, but surprisingly they are not necessary, as the regular configuration shown above without any variables is behaving the same.
So it looks as if these configurations are identical, but in fact, the last two configurations have a hidden flaw: Using the $uri and $document_uri variables makes the request that is sent to the backend server vulnerable to CRLF injection. CRLF or new-line injection enables attackers to inject new line characters combination and add a new request header to the request. Consequently, attackers can inject a new host header. In shared hosting, the host header controls which backend server would be accessed. This enables attackers to hijack the execution flow and redirect it to an attacker-controlled server.
Examples of FrontJacking
Here, instead of accessing the localhost server, a new host header is injected resulting in accessing the example.com server:
Here is another real-life demo in GitHub pages. The real green-looking website is located at https://omritest.tk:
A (fake) malicious website was created at the address https://omriinbar-cyesec.github.io:
The attack then redirects an unsuspecting user using the malicious address containing the FrontJacking payload:
https://omritest.tk/%20HTTP/1.1%0d%0aHost:%20omriinbar-cyesec.github.io%0d%0a%0d%0a
This address is URL decoded in the reverse proxy server:
The IP address of omritest.tk is that of the shared hosting server, but the hostname itself is pointing to the malicious website. The result is that the malicious website is presented under the vulnerable website’s address:
This vulnerability has already been found in hundreds of websites in the wild, including some shared hosting and landing pages providers.
What makes it even more dangerous is that it enables attackers to execute any reflected XSS and phishing-related payloads while bypassing any defensive mechanisms including CSP (Content Security Policy), HttpOnly cookie attributes, CORS (Cross Origin Resource Sharing) and HTTPS certificate validation. The only mechanism that partially helps in some cases is Web Application Firewall (WAF).
Conclusions
FrontJacking is a new dangerous attacking technique that exploits the common web architecture of a self-managed Nginx server with a shared hosting service, combined with a poor Nginx configuration. Contacting Nginx developers resulted in them answering that this issue is not going to be fixed, so developers and DevOps engineers should be aware of it and avoid the usage of the $uri and $document_uri variables in Nginx’s configuration.
If you wish to learn more about this attack and how to prevent it, check out this SecureFlag blog post.
CYE always strives to find cutting-edge attack techniques in our customers’ systems and in general, as part of penetration tests and red teaming activities. Contact us to learn more.
