Конфигурационна уязвимост на Nginx с неправилни настройки за блокиране на псевдоними

Някои сървъри с nginx остават уязвими към техниката Nginx Alias ​​​​Traversal, която беше предложена на конференцията Blackhat през 2018 г. и позволява достъп до файлове и директории, разположени извън основната директория, посочена в директивата „alias“. Проблемът се появява само в конфигурации с директива "alias", поставена в блока "location", чийто параметър не завършва със знака "/", докато "alias" завършва с "/".

Същността на проблема е, че файловете за блокове с директива за псевдоним се дават чрез прикачване на искания път, след съпоставяне с маската от директивата за местоположение и изрязване на частта от пътя, посочен в тази маска. За примера на уязвима конфигурация, показан по-горе, атакуващият може да поиска файла "/img../test.txt" и тази заявка ще съответства на маската, посочена в местоположението "/img", след което оставащата опашка "../ test.txt" ще бъде прикачен към пътя от директивата за псевдоним "/var/images/" и в резултат на това ще бъде поискан файлът "/var/images/../test.txt". По този начин нападателите имат достъп до всякакви файлове в директорията "/var", а не само файлове в "/var/images/", например, за да изтеглите дневника на nginx, можете да изпратите заявката "/img../log/ nginx/ access.log".

В конфигурации, в които стойността на директивата за псевдоним не завършва със знак "/" (например "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" и т.н. .P.

Методът работи и с Google HPC Toolkit, където /статичните заявки бяха пренасочени към директорията „../hpc-toolkit/community/front-end/website/static/“. За да получи база данни с частен ключ и идентификационни данни, атакуващият може да изпрати заявки „/static../.secret_key“ и „/static../db.sqlite3“.

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