An expert explains based on actual examples about Nginx's common setting mistakes that have a huge hole in security just by the presence or absence of a slash
Nginx, which appeared in 2004 as a multi-functional web server, is a popular server that will have
Hunting for Nginx Alias Traversals in the wild
https://labs.hakaioffsec.com/nginx-alias-traversal/
In Nginx configuration, there is a directive called 'location' that can describe how access to a particular URL should be handled, and is often used to map URLs to files on the server. For example, if you write as follows, you will be able to access the contents of '/opt/production/assets/' on the server from the URL below '/assets/'.
[code]location /assets/ { # Define access processing for URL '/assets/'
alias /opt/production/assets/; # transfer to server 'assets'
}[/code]
In the pattern that uses this location in combination with alias, it is critical when the two conditions of 'do not put a slash at the end of the URL specified by location' and 'put a slash at the end of the path specified by alias' are met. It is said that vulnerability will occur.
If there is no slash at the end of the location URL, nginx will redirect all URLs starting with '/img' to '/var/images/'. For example, if you access '/img/profile.jpg', it will be transferred to '/var/images//profile.jpg', but consecutive slashes in the path will be ignored and '/var/images/profile.jpg' jpg' data is returned. On the other hand, if you access '/imgprofile.jpg', it will be transferred to '/var/images/profile.jpg' ... and so on, you can access the same data with two URLs.
Furthermore, by accessing the URL '/img..', it is possible to access the data specified by the path '/var/images/..'. Since '/..' in the path refers to the parent directory, '/var/images/..' is the same as '/var/', and you can browse back to directories that should not be open to the public. can. For example, if you access the URL '/img../log/nginx/access.log', you can view the data in '/var/log/nginx/access.log'. Be especially careful when dealing with data that must be kept confidential, such as personal information.
If there is no trailing slash in the alias path specification, accessing the URL '/img..' will only look for the directory named '/var/images..', so the data in the parent directory will be accessed. this is not allowed. However, if confidential data is stored in a directory such as '/var/images_confidential', it will be accessed with the URL '/img_confidential'. After all, you should include a trailing slash in both location and alias.
Mr. Matsumoto seems to have searched GitHub using the following regular expression in order to investigate how much code contains this problem. This regex will search for code with no trailing slash in the location path and a trailing slash in the alias path.
[code]/location \/[_.a-zA-Z0-9-\/]*[^\/][\s]\{[\s\n]*alias \/[_.a-zA- Z0-9-\/]*\/;/[/code]
GitHub said that 1900 files were caught in the search. We can't say that all code is flawed, such as when comments in the code are searched, but there is no doubt that many projects are vulnerable.
Matsumoto cites the open source password manager
I tried using a password manager 'bitwarden' that can be used for free and supports automatic synchronization between devices - GIGAZINE
Bitwarden offers a self-hosting method for those who want to use their own server, and one of the self-hosting methods is a Docker image . At the time of article creation, 100,000 downloads were recorded, and it can be seen that quite a lot of users are using it.
Matsumoto found that the code inside Bitwarden's Docker image contains the following code. The location path is '/attachments' and has no trailing slash, while the alias has a trailing slash. In this state, all files under /etc/bitwarden/ will be accessible.
However, if you don't have any important data stored under /etc/bitwarden/, it's not a serious problem. So, Mr. Matsumoto tried to find out what kind of data was saved. Then I found the following code in the Dockerfile.
[code]ENV BW_DB_FILE='/etc/bitwarden/vault.db'[/code]
If the user uses SQLite as the database, Bitwarden stores the database in '/etc/bitwarden/vault.db'. Therefore, by accessing 'http://<instance>/attachments../vault.db', you can download the entire user's database. Also, many log files and certificate files were also downloaded.
Bitwarden paid a bounty of $ 6000 (about 850,000 yen), the highest amount among the company, for this bug report.
Also, when Mr. Matsumoto was examining the code on GitHub, he discovered that a similar vulnerability was included in a repository called ' Google HPC-Toolkit '. This repository provides tools to facilitate deployments to high performance computing on Google Cloud.
The problem is the part below. Again, location has no trailing slash and alias has a trailing slash.
Through this vulnerability, it is possible to steal the entire SQLite database and Django's private key, and there is a risk of accessing the Google Cloud authentication information stored in the SQLite database. Google paid a bounty of $ 500 (about 70,000 yen) for this bug report.
Nginx configuration requires a thorough understanding and careful implementation, as the presence or absence of slashes can pose serious dangers. In addition, Mr. Matsumoto has released a tool that allows black box testing of this vulnerability from the outside , so if you are interested, please check it out.
Related Posts:
