Niektóre serwery Nginx pozostają podatne na technikę Nginx Alias Traversal, która została zaproponowana na konferencji Blackhat w 2018 roku i umożliwia dostęp do plików i katalogów znajdujących się poza katalogiem głównym określonym w dyrektywie „alias”. Problem pojawia się tylko w konfiguracjach z dyrektywą „alias” umieszczoną wewnątrz bloku „lokalizacja”, którego parametr nie kończy się znakiem „/”, natomiast „alias” kończy się znakiem „/”.
Istota problemu polega na tym, że pliki dla bloków z dyrektywą alias podawane są poprzez dołączenie żądanej ścieżki, po porównaniu jej z maską z dyrektywy lokalizacji i wycięciu części ścieżki określonej w tej masce. W przykładzie pokazanej powyżej konfiguracji podatnej na atak osoba atakująca może zażądać pliku „/img../test.txt”, a żądanie to będzie ujęte w masce „/img” określonej w lokalizacji, po czym pozostały ogon „.. /test.txt” zostanie dołączony do ścieżki z dyrektywy aliasów „/var/images/” i ostatecznie zażąda pliku „/var/images/../test.txt”. W ten sposób atakujący mogą uzyskać dostęp do dowolnych plików w katalogu „/var”, a nie tylko do plików w „/var/images/”. Na przykład, aby pobrać dziennik nginx, możesz wysłać żądanie „/img../log/ nginx/access.log”.
W konfiguracjach, w których wartość dyrektywy alias nie kończy się znakiem „/” (na przykład „alias /var/images;”), osoba atakująca nie może przejść do katalogu nadrzędnego, ale może zażądać innego katalogu w /var którego nazwa zaczyna się od tej samej określonej w konfiguracji. Na przykład, żądając „/img.old/test.txt”, możesz uzyskać dostęp do katalogu „var/images.old/test.txt”.
Analiza repozytoriów na GitHubie wykazała, że błędy w konfiguracji nginx, które doprowadziły do problemu, nadal występują w rzeczywistych projektach. Na przykład problem został zidentyfikowany w backendie menedżera haseł Bitwarden i można go było wykorzystać do uzyskania dostępu do wszystkich plików w katalogu /etc/bitwarden (żądania /attachments zostały wysłane z /etc/bitwarden/attachments/), w tym do „sejmu .db”, certyfikat i logi, do uzyskania których wystarczyło wysłać żądania „/attachments../vault.db”, „/attachments../identity.pfx”, „/attachments../logs/api.log ", itp. .P.
Metoda ta działała również z zestawem narzędzi Google HPC Toolkit, który przekierowywał żądania /static do katalogu „../hpc-toolkit/community/front-end/website/static/”. Aby uzyskać bazę danych zawierającą klucz prywatny i dane uwierzytelniające, osoba atakująca może wysłać żądania „/static../.secret_key” i „/static../db.sqlite3”.
Źródło: opennet.ru