Некоторые серверы с nginx остаются уязвимы для техники Nginx Alias Traversal, которая была предложена на конференции Blackhat ещё в 2018 году и позволяет получить доступ к файлам и каталогам, размещённым вне корневого каталога, заданного в директиве "alias". Проблема проявляется только в конфигурациях с директивой "alias", размещённой внутри блока "location", параметр которой не завершается на символ "/", в то время как "alias" завершается на "/".
Суть проблемы в том, что файлы для блоков с директивой alias отдаются через прикрепление запрошенного пути, после его сопоставления с маской из директивы location и вырезания заданной в этой маске части пути. Для показанного выше примера уязвимой конфигурации атакующий может запросить файл "/img../test.txt" и этот запрос подпадёт под указанную в location маску "/img", после чего остающийся хвост "../test.txt" будет прикреплён к пути из директивы alias "/var/images/" и в итоге будет запрошен файл "/var/images/../test.txt". Таким образом, атакующим может получить доступ к любым файлам в каталоге "/var", а не только к файлам в "/var/images/", например, для загрузки лога nginx можно отправить запрос "/img../log/nginx/access.log".
В конфигурациях, в которых значение директивы alias не завершается символом "/" (например, "alias /var/images;"), атакующий не может перейти в родительский каталог, но имеет возможность запросить другой каталог в /var, начало имени которого совпадает с указанным в конфигурации. Например, запросив "/img.old/test.txt" можно получить доступ к каталогу "var/images.old/test.txt".
Анализ репозиториев на GitHub показал, что приводящие к проблеме ошибки в настройке nginx до сих пор встречаются в реальных проектах. Например, наличие проблемы было выявлено в серверной части менеджера паролей Bitwarden и могло использоваться для доступа ко всем файлам в каталоге /etc/bitwarden (запросы /attachments отдавались из /etc/bitwarden/attachments/), включая хранимую там БД с паролями "vault.db", сертификат и логи, для получения которых достаточно было отправить запросы "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log" и т.п.
Метод также сработал с Google HPC Toolkit, в котором запросы /static перенаправлялись в каталог "../hpc-toolkit/community/front-end/website/static/". Для получения БД с закрытым ключом и учётными данными атакующий мог отправить запросы "/static../.secret_key" и "/static../db.sqlite3".
Суть проблемы в том, что файлы для блоков с директивой alias отдаются через прикрепление запрошенного пути, после его сопоставления с маской из директивы location и вырезания заданной в этой маске части пути. Для показанного выше примера уязвимой конфигурации атакующий может запросить файл "/img../test.txt" и этот запрос подпадёт под указанную в location маску "/img", после чего остающийся хвост "../test.txt" будет прикреплён к пути из директивы alias "/var/images/" и в итоге будет запрошен файл "/var/images/../test.txt". Таким образом, атакующим может получить доступ к любым файлам в каталоге "/var", а не только к файлам в "/var/images/", например, для загрузки лога nginx можно отправить запрос "/img../log/nginx/access.log".
В конфигурациях, в которых значение директивы alias не завершается символом "/" (например, "alias /var/images;"), атакующий не может перейти в родительский каталог, но имеет возможность запросить другой каталог в /var, начало имени которого совпадает с указанным в конфигурации. Например, запросив "/img.old/test.txt" можно получить доступ к каталогу "var/images.old/test.txt".
Анализ репозиториев на GitHub показал, что приводящие к проблеме ошибки в настройке nginx до сих пор встречаются в реальных проектах. Например, наличие проблемы было выявлено в серверной части менеджера паролей Bitwarden и могло использоваться для доступа ко всем файлам в каталоге /etc/bitwarden (запросы /attachments отдавались из /etc/bitwarden/attachments/), включая хранимую там БД с паролями "vault.db", сертификат и логи, для получения которых достаточно было отправить запросы "/attachments../vault.db", "/attachments../identity.pfx", "/attachments../logs/api.log" и т.п.
Метод также сработал с Google HPC Toolkit, в котором запросы /static перенаправлялись в каталог "../hpc-toolkit/community/front-end/website/static/". Для получения БД с закрытым ключом и учётными данными атакующий мог отправить запросы "/static../.secret_key" и "/static../db.sqlite3".
