18-01-2019 / Od 0 do pentestera

NGINX

NGINX to szybki i wydajny serwer HTTP. Przy jego pomocy można bardzo szybko wystawić naszą stronę w Internecie.

Ale czy wiesz jak go prawidłowo i bezpiecznie skonfigurować?

Dzisiaj kilka przykładów błędnych konfiguracji, które mogą narazić nas na atak.

W tym odcinku zakładam już, że masz zainstalowany serwer i wyświetla on przykładową stronę po wejściu na localhost.

Zaczniemy od dyrektywy alias.

Dyrektywa alias

Może być ona stosowana do mapowania innej lokalizacji.

Popatrzmy na przykład.

Przy pomocy składni location definiujemy, że jeżeli użytkownik wejdzie na nasz serwer przy pomocy adresu, który rozpoczyna się od ciągu znaków frytki to zostanie mu wyświetlona treść z katalogu /home/test/nginx.

Aby to przetestować, stworzyłem w tym katalogu plik 1.html.

Po przejściu do adresu /frytki/1.html mogę zobaczyć jego treść.

Ale jest jedno "ale" - czy zauważyłeś że po słowie kluczowym "frytki" nie dodałem kończącego "/"?

Co to zmienia? Dzięki temu jesteśmy podatni na atak Path Traversal - czyli możliwość wyświetlenia plików z innej lokalizacji niż ta, którą byśmy sobie życzyli.

Aby to udowodnić stworzę plik 2.html w katalogu /home/test.

Teraz wystarczy wejść na lokalizację używając podwójnej kropki po słowie frytki.

http://localhost/frytki../2.html

Jak widzisz wyświetliłem zawartość pliku 2.html pomimo tego iż nie znajduje się on w katalogu, który został zdefiniowany w dyrektywie alias.

Aby poprawić ten błąd należy zawsze kończyć adresy slashem "/".

Drugi przykład to automatyczne ustawianie odpowiednich nagłówków bezpieczeństwa w odpowiedziach serwera.

W naszym przypadku ustawiam nagłówek X-Frame-Options tak, aby uniknąć ataku Clickjacking.

add_header

Dzięki funkcjonalności add_header, w każdej odpowiedzi serwera znajduje się prawidłowy nagłówek.

Ale czy aby na pewno?

Załóżmy, że w lokalizacji XSS chcę, aby do standardowych nagłówków dodawany był dodatkowy - odpowiedzialny za ochronę przed atakami XSS w przeglądarce.

Używając więc instrukcji add_header dodaję dodatkowy nagłówek.

Logicznym jest, że serwer powinien sumować te nagłówki - a więc w odpowiedzi powinien znajdować się nagłówek z pola nadrzędnego i dodatkowy - z pola podrzędnego.

NGINX działa jednak inaczej i wyświetla nam jedynie nagłówki z pola podrzędnego - co w niektórych sytuacjach może prowadzić do poważnych błędów.

Tak jak tutaj - gdzie nasza strona nie jest już chroniona przed atakami Clickjacking.

Trzeci przykład pokazuje jak działa porównywanie ciągów znaków.

Załóżmy że pod adresem admin.local znajduje się panel administratora, który może być używany jedynie przez osobę korzystającą z jednego, statycznego adresu IP.

Tworzymy więc dwie konstrukcje if:

Konstrukcja if

W pierwszej sprawdzamy czy użytkownik odwiedza witrynę admin.local.

W drugiej natomiast, czy jego adres IP jest różny od 10.10.10.10.

Jeśli oba warunki są spełnione - oznacza to, że chce on odwiedzić panel administratora nie będąc do tego upoważnionym.

Zwracamy więc nagłówek 403 i kończymy dalsze wykonywanie pliku konfiguracyjnego.

Pewno zastanawiasz się co to za dziwna konstrukcja ze zmienną block.

Wynika to z faktu iż NGINX nie obsługuje konstrukcji if z dwoma warunkami - stąd takie obejście problemu.

I rzeczywiście - nasza konfiguracja działa prawidłowo.

Jeżeli próbujemy wejść na podaną domenę otrzymujemy błąd 403 - nie zgadza się bowiem nasz adres IP.

Jak obejść to zabezpieczenie?

Do porównywania znaków użyliśmy tyldy - a ona nie rozróżnia wielkości liter.

Wystarczy więc, że zamiast odwiedzać stronę admin.local, spróbujemy wejść na ADMIN.LOCAL pisane z dużych liter - tak właśnie udało nam się obejść zabezpieczenia.

Żadanie

Czwarty błąd jest związany z wyrażeniami regularnymi.

Wielokrotnie przestrzegałem, iż jeżeli ich używamy należy mieć się na baczności.

W tym wypadku jeżeli zapytanie pochodzi od domeny admin.local - zwracamy odpowiednie nagłówki CORS - tak aby możliwe było wykonywanie zapytania AJAX do tej domeny.

Do sprawdzania nagłówka origin używamy wyrażenia regularnego.

Wyrażenia regularne

Czy potrafisz odnaleźć błąd? Prześledźmy to wyrażenie wspólnie.

Musi zaczynać się ono od http://admin a następnie kropka.

W wyrażeniach kropka oznacza dowolny jeden znak - tutaj jednak mamy do czynienia z normalną kropką - ponieważ została ona poprzedzona backslashem.

Tylko, że sprawdzamy tutaj tylko początek nagłówka - brakuje bowiem znaku dolara - który oznacza koniec ciągu znaków.

Możliwe jest zatem stworzenie takiej domeny, która będzie zaczynała się od admin.local a równocześnie będzie subdomeną innej domeny.

Dla przykładu to wyrażenie będzie działało również dla admin.local.szurek.pl - umożliwiając tym samym zapytania AJAX również z tej domeny.

Origin

Dlatego też pamiętaj aby nie zapominać o znaku dolara.

Ostatni przykład na dzisiaj - będący jednocześnie najbardziej skomplikowanym.

Możemy ustawić serwer w taki sposób, aby obsługiwał pliki PHP.

Są one wtedy wysyłane do odpowiedniego interpretera.

W Internecie można znaleźć wiele tutoriali - nie wszystkie jednak są prawidłowe.

Popatrzmy na ten przykład - w katalogu /usr/share/nging/html/test.php umieściłem przykładowy plik zwracający bieżący czas.

Jak widać wszystko działa jak należy.

Spróbujemy zatem zmienić nazwę tego pliku na test.png.

Oczywiście takie coś nie zadziała - ponieważ NGINX obsługuje tylko pliki z rozszerzeniem php.

Ale czy na pewno?

Teraz użyjemy innego adresu URL.

http://localhost/test.png/cokolwiek.php

Na jego początku jest nazwa naszego obrazka, następnie "/", a potem nazwa nieistniejącego pliku php.

NGINX przekaże ten ciąg do wywołania przez PHP ponieważ kończy się on ciągiem znaków .php.

PHP jednakże spróbuje wykonać pierwszy pasujący plik jako PHP - z powodu opcji cgi.fix_pathinfo.

Błąd ten był na tyle częsty iż w najnowszych wersjach PHP podany wyżej atak nie zadziała1.

cgi.fix_pathinfo

Jest to spowodowane zmianą w konfiguracji limit_extensions, która definiuje jakie pliki mogą być rozpoznawane jako PHP.

Te i inne błędy rozpoznaje mało znane narzędzie gixy2, które jest w stanie skontrolować pliki konfiguracyjne.

GIXY

Sprawdź czy i Ty nie jesteś podatny.

Icon made by Freepik from www.flaticon.com

Newsletter

Wyrażam zgodę na przetwarzanie moich danych osobowych przez Kacpra Szurka w celu otrzymywania newslettera za pomocą e-maila, informacji o promocjach, nowościach, produktach blogowych i usługach własnych oraz innych, polecanych osób, zgodnie z polityką prywatności.