Уязвимост на конфигурации на 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