Niektóre serwery z 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 umieszczonych poza głównym katalogiem określonym w dyrektywie „alias”. Problem występuje tylko w konfiguracjach z dyrektywą „alias” umieszczoną wewnątrz bloku „location”, której argument nie kończy się znakiem „/”, podczas gdy „alias” kończy się na „/”.
Sedno problemu polega na tym, że pliki dla bloków z dyrektywą alias są przekazywane przez dołączenie żądanego ścieżki, po jej dopasowaniu do wzorca z dyrektywy location i odcięciu części ścieżki określonej w tym wzorze. Dla pokazanej powyżej przykładzie podatnej konfiguracji, atakujący może zażądać pliku „/img../test.txt”, a to żądanie podlega wzorcowi wskazanemu w location „/img”, po czym pozostały ogon „../test.txt” zostanie dołączony do ścieżki z dyrektywy alias „/var/images/” i w efekcie zostanie zażądany plik „/var/images/../test.txt”. W ten sposób atakujący może uzyskać dostęp do dowolnych plików w katalogu „/var”, a nie tylko do plików w „/var/images/”, na przykład aby pobrać log nginx, można 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;”), atakujący nie może przejść do katalogu nadrzędnego, ale może zażądać innego katalogu w /var, którego początek nazwy pokrywa się z określonym w konfiguracji. Na przykład, żądając „/img.old/test.txt” można uzyskać dostęp do katalogu „var/images.old/test.txt”.
Analiza repozytoriów na GitHubie pokazała, że prowadzące do problemu błędy w konfiguracji nginx wciąż występują w rzeczywistych projektach. Na przykład, wykryto problem w backendzie menedżera haseł Bitwarden, który mógł być wykorzystywany do uzyskania dostępu do wszystkich plików w katalogu /etc/bitwarden (żądania /attachments były przekazywane z /etc/bitwarden/attachments/), w tym przechowywanej tam bazy danych z hasłami „vault.db”, certyfikatu i logów, do których wystarczyło wysłać żądania „/attachments../vault.db”, „/attachments../identity.pfx”, „/attachments../logs/api.log” i tym podobne.
Metoda ta również zadziałała z Google HPC Toolkit, w którym żądania /static były przekierowywane do katalogu „../hpc-toolkit/community/front-end/website/static/”. Aby uzyskać bazę danych z kluczem prywatnym i danymi uwierzytelniającymi, atakujący mógł wysłać żądania „/static../.secret_key” oraz „/static../db.sqlite3.”
Źródło: opennet.ru
