Nginx servers are still vulnerable to "Alias ​​Traversal"

Nginx Alias ​​Traversal

Nginx Alias ​​​​Traversal is still a critical problem for many projects

Recently the news broke that some nginx servers are still vulnerable to The technique "Nginx Alias ​​Traversal», which was proposed at the Blackhat conference in 2018 and allows access to files and directories located outside of the root directory specified in the aliases directive.

The essence of the problem is that files for blocks with the alias directive are provided by attaching the requested path, after matching it to the mask of the location directive and slicing off the part of the path specified in this mask.

The problem appears only in configurations with an "alias" directive, as in the Nginx configuration, there is a directive called 'location' which can describe how access to a particular URL should be handled, and is often used to assign URLs to files on the server.

In the pattern that uses this location in combination with the alias, it is critical when the two conditions of 'do not put a slash at the end of the URL specified by the location' and 'put a slash at the end of the path specified by the alias' are met. alias ' are met. Vulnerability is said to occur.

At the BlackHat 2018 conference, Orange Tsai presented his research on breaking URL parsers. Among other impressive finds, she demonstrated a technique discovered in a 2016 HCTF CTF challenge, created by @iaklis.

For the technique to be applicable, the following conditions must be met:

The location directive must not have a forward slash in its path;
An alias directive must be present within the location context and must end with a forward slash.

For the example of a vulnerable configuration shown above, an attacker can request the file "/img../test.txt" and this request will match the mask specified in the location "/img", after which the queue The remaining "../test.txt" will be appended to the alias directive path "/var/images/" and as a result the file "/var/images/../test.txt" will be requested.

Therefore, attackers can access any file in the "/var" directory, not just files in "/var/images/", for example, to download the nginx log, you can send the request "/img ../log/nginx /access.log”.

An analysis from repositories on GitHub showed that the errors in the nginx configuration leading to the problem are still in real projects.

For example, a problem was found in the Bitwarden password manager backend and could be used to access all files in the /etc/bitwarden directory (requests for /attachments were issued from /etc/bitwarden/ attachments/), including the database stored there with passwords "vault.db", certificate and logs, for which it was enough to send requests "vault.db", "identity.pfx", "api.log", etc.

It is mentioned that the severity of this vulnerability can fluctuate significantly depending on the project, from a negligible impact to a critical one. The extent of its impact is primarily determined by whether the exposed directory contains sensitive data that may facilitate further attacks or result in the disclosure of private information.

As a starting point in our search for this vulnerability, we chose to explore the popular GitHub repositories that were showing this issue. Identifying this specific vulnerability in environments with access to the source code becomes significantly more feasible, mainly due to two main factors:

Detection – Using simple code analysis tools, such as regular expression searches, allows us to effectively identify potentially vulnerable Nginx configuration files within these projects.
Exploitation: Knowing the exact target directory that has been assigned an alias allows us to set up a local instance, examine the aliased directories using a local shell, and determine which files can be accessed through the vulnerability.

It is worth mentioning that the method also worked with the Google HPC Toolkit, where requests were redirected to the directory of interest to obtain a database with a private key and credentials, an attacker could send "secret_key" and "db.sqlite3" queries.

Finally, if you are interested in being able to know more about it, you can consult the details In the following link.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.