Some servers using nginx remain vulnerable to the Nginx Alias Traversal technique, which was introduced at the Blackhat conference in 2018 and allows access to files and directories located outside the root directory specified in the 'alias' directive. The issue manifests only in configurations where the 'alias' directive is placed inside a 'location' block and its parameter does not end with a character '/', while 'alias' does end with '/'.
The essence of the problem is that files for blocks with the alias directive are served through appending the requested path after matching it with the mask from the location directive and trimming the specified part of the path in that mask. For the illustrated vulnerable configuration, an attacker could request the file '/img../test.txt', and this request would fall under the specified location mask '/img', after which the remaining tail '../test.txt' would be appended to the path from the alias directive '/var/images/' and, ultimately, the file '/var/images/../test.txt' would be requested. Thus, attackers could access any files in the '/var' directory, not just files in '/var/images/', for instance, to download the nginx log, they could send a request for '/img../log/nginx/access.log'.
In configurations where the value of the alias directive does not end with the character '/' (for example, 'alias /var/images;'), an attacker cannot traverse to the parent directory but can request another directory in /var, the beginning of whose name matches that specified in the configuration. For example, by requesting '/img.old/test.txt', access can be gained to the directory 'var/images.old/test.txt'.
Analysis of repositories on GitHub has shown that the configuration errors leading to this issue still occur in real projects. For instance, the issue was identified in the backend of the Bitwarden password manager and could be exploited to access all files in the /etc/bitwarden directory (requests to /attachments were served from /etc/bitwarden/attachments/), including the stored password database 'vault.db', certificates, and logs, which could be accessed by sending requests like '/attachments../vault.db', '/attachments../identity.pfx', '/attachments../logs/api.log', etc.
The method also worked with the Google HPC Toolkit, where requests to /static were redirected to the directory '../hpc-toolkit/community/front-end/website/static/'. To obtain the database with the secret key and credentials, an attacker could send the requests '/static../.secret_key' and '/static../db.sqlite3'.
Source: opennet.ru
