Уязвимость конфигураций Nginx с некорректными настройками блока alias

Некоторые серверы с 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».

Источник: opennet.ru