Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book

Czym jest podatność Path Traversal?

03 sierpnia 2017, 12:45 | Teksty | komentarzy 9

Atak Path Traversal przeprowadza się w sytuacji, gdy podatna aplikacja pozwala na niekontrolowany dostęp do plików oraz katalogów, do których w normalnych warunkach użytkownik nie powinien mieć dostępu. Wektorem ataku są parametry przekazywane do aplikacji, reprezentujące ścieżki do zasobów, na których mają zostać wykonane określone operacje – odczyt, zapis, listowanie zawartości katalogu. Manipulacja ścieżką odbywa się np. poprzez dodawanie ciągu znaków „../”.

W literaturze przedmiotu można spotkać się z innymi określeniami tej samej podatności: Directory Traversal lub „dot dot slash attack”. Powodzenie ataku determinuje zarówno brak, lub niewystarczająca walidacja danych wejściowych do aplikacji, jak i błędy konfiguracyjne – niepoprawne uprawnienia do plików i katalogów. Udana próba wykorzystania podatności skutkuje możliwością odczytania zawartości katalogów oraz plików, do których atakujący nie powinien mieć dostę­pu (np. pliki konfiguracyjne, zawierające dane dostępowe do zewnętrznych usług). Atak nie jest charakterystyczny dla jednej grupy technologii (np. PHP). Path Traversal często stanowi element innych ataków, np. LFI (Local File Inclusion).

Logika podatności

Standardowy przykład kodu podatnego na Path Traversal prezentuje Listing nr 1.

<?php
readfile("document/" . $_GET["file"]);

Do funkcji readfile przekazywana jest wartość parametru file, pobieranego bezpośrednio z adresu URL. Wykorzystanie takiego kodu powoduje, że manipulując wartością parametru file, możliwe jest odczytanie dowolnego pliku z serwera, na którym uruchomiona jest podatna aplikacja. Jedynym ograniczeniem będą uprawnienia, z jakimi uruchomiony jest demon serwera WWW. Podobne przykłady kodu można przygotować dla każdej innej technologii oraz języka programowania.

Zagrożenia

Występowanie w aplikacji podatności Path Traversal, wiąże się z kilkoma zagro­żeniami. Najważniejsze z nich zostały omówione poniżej.

Ujawnienie nadmiarowych informacji

Dzięki udanemu atakowi z wykorzystaniem podatności na Path Traversal, możliwe jest m.in. wylistowanie zawartości dowolnego katalogu. Atakujący uzyskuje wówczas dodatkowe informacje o architekturze aplikacji (struktura plików oraz katalogów). Mogą być one przydatne np. do odkrycia elementów testowanego systemu, które znajdują się w tzw. „głębokim ukryciu”.

Innym potencjalnym scenariuszem ataku, jest odczytanie zwartości plików zawierających historię wykonywanych komend na serwerze (np. .bash_history). Uzyskanie dostępu do tego typu plików, może prowadzić do ujawnienia danych dostępowych do lokalnych, jak i zewnętrznych usług (np. hasła do serwera bazy danych).

Ujawnienie plików konfiguracyjnych

Mimo, że istnieje wyraźne podobieństwo do poprzedniego punktu, należy w osobnym akapicie wspomnieć o potencjalnym dostępie do plików konfiguracyjnych. Zagrożenie to może być szczególnie ważne w przypadku, gdy atakujący uzyska dostęp do informacji o usługach, które dostępne są z zewnątrz.

Ciekawym przykładem jest podatność pozwalająca na wylistowanie informacji o vhostach serwera Apache. Domyślnie, atakujący może nie posiadać wiedzy o innych aplikacjach uruchomionych na serwerze – poprzez wylistowanie takiej konfiguracji, uzyska informacje o innych elementach systemu – zwiększy się w ten sposób potencjalna powierzchnia ataku.

Zdalne wykonanie kodu

Podatności związane z Path Traversal nie ograniczają się tylko do możliwości odczytu plików. Jeżeli aplikacja w niepoprawny sposób waliduje dane podczas wgrywania plików na serwer, w teorii może dojść do sytuacji, w której atakujący będzie miał wpływ na ścieżkę zapisu pliku na serwerze. To z kolei, w zależności od konfiguracji serwera, może wprost doprowadzić do sytuacji, w której możliwe będzie umieszczenie pliku w dowolnym miejscu drzewa katalogów. W tym miejscu należy oczywiście uwzględniając ograniczenia związane z uprawnieniami, na jakich wykonywana jest operacja zapisu.

Szersze spojrzenie na problem

Path Traversal czasami występuje nie tylko w parametrze przekazywanym do aplikacji (lub nagłówkach), ale także w samym adresie URL. W ten sposób, przechodząc pod adres podobny do podanego niżej, możliwe jest odczytanie dowolnego pliku z serwera.

http://vuln-app/../../../../etc/passwd

Powodem takiej podatności, może być zarówno błąd serwera WWW, jak i nieodpowiednio wdrożony routing aplikacji. Należy pamiętać o tym, że podatności na omawianego ataku, nie można łączyć
tylko z aplikacjami WWW. Atak ten możliwy jest do przeprowadzenia wszędzie tam, gdzie w niepoprawny sposób waliduje się dane wejściowe, które później służą do odczytu plików lub katalogów.Jak zostało wspominane, Path Traversal może być częścią innego ataku. Przykładem może być podatność XXE (XML External Entity Processing) występująca w aplikacji, gdzie przekazując odpowiednio spreparowaną ścieżkę zawierającą Path Traversal, możliwe jest odczytanie zawartości katalogu lub wybranego pliku.

Przykłady podatności

Bazy agregujące dane o podatnościach w oprogramowaniu, są pełne informacji o lukach pozwalających na przeprowadzenie ataku Path Traversal. Należy zaznaczyć fakt, że ta klasa podatności jest znana od lat, mimo to nadal publikowane są informacje o nowych błędach występujących w aplikacjach dotyczących tej klasy podatności.

GlassFish Server

W sierpniu 2015 roku, opublikowano informację o Path Traversal w popularnych serwerze aplikacji GlassFish. Przejście pod odpowiednio spreparowany adres URL powodowało, że możliwe było odczytanie dowolnego pliku z dysku, na którym uruchomione było to oprogramowanie.

GET /theme/%c0%ae%c0%ae%c0%af%c0%ae%c0%ae%c0%af%c0%ae%c0%ae%c0%af%
c0%ae%c0%ae%c0%af%c0%ae%c0%ae%c0%af%c0%ae%c0%ae%c0%af%c0%ae%c0%ae%
c0%af%c0%ae%c0%ae%c0%af%c0%ae%c0%ae%c0%af%c0%ae%c0%ae%c0%afetc%c0%
afpasswd HTTP/1.1
Host: 127.0.0.1:4848
Accept: */*
Accept-Language: en
Connection: close

W odpowiedzi aplikacja zwracała zawartość pliku /etc/passwd:

HTTP/1.1 200 OK
Server: GlassFish Server Open Source Edition 4.1 
X-Powered-By: Servlet/3.1 JSP/2.3 (GlassFish Server Open Source Edition 4.1
Java/Oracle Corporation/1.7)
Last-Modified: Tue, 13 Jan 2015 10:00:00 GMT
Date: Tue, 10 Jan 2015 10:00:00 GMT
Connection: close
Content-Length: 1087
root:!:16436:0:99999:7:::
daemon:*:16273:0:99999:7:::
bin:*:16273:0:99999:7:::
sys:*:16273:0:99999:7:::
sync:*:16273:0:99999:7:::
[...]

Co ważne, podatność ta dotyczyła zarówno serwera uruchomionego w środowisku Linux, jak i Windows.

ColoradoFTP 1.3

Path Traversal nie jest jedynie domeną aplikacji WWW. Dość często, przypadłość ta pojawia się w serwerach FTP. Przykładowo, w oprogramowaniu ColoradoFTP – dodając odpowiedni ciąg znaków – można było uzyskać dostęp do plików spoza głównego katalogu serwera. Natomiast wykonanie komendy z poniższego listingu, spowoduje wgranie pliku binarnego do katalogu system32:

ftp> put nc.exe \\\..\\..\\..\\Windows\\system32\\nc.exe

Testowanie

Podobnie jak każda inna podatność w aplikacjach (np. SQL Injection, XSS), Path Traversal może wystąpić w dowolnym elemencie oprogramowania lub funkcji. Nie ma miejsca, które można pominąć podczas weryfikacji, niemniej występują funkcje, które w szczególny sposób narażone są na Path Traversal:

  • pobieranie plików z serwera,
  • wczytywanie konfiguracji aplikacji (style, szablony, język interfejsu),
  • wgrywanie plików na serwer.

Podstawową metodą testowania, jaką można wykorzystać, jest zastosowanie zwykłego proxy HTTP, np. Burp Suite. Manipulując zapytaniem – dodając ciąg znaków „../” do parametrów reprezentujących ścieżki do plików oraz katalogów, możemy próbować wyszukiwać podatności:

Rysunek 1. Manipulacja parametrami przekazywanymi do aplikacji.

Automatyzacja

Podatności na Path Traversal można szukać ręcznie lub powierzyć skanerom automatycznym. Przykładem prostego narzędzia jest dotdotpwn – skrypt, który przeprowadza podstawowy fuzzing i na podstawie analizy odpowiedzi aplikacji jest w stanie ustalić, czy testowana aplikacja jest podatna.

root@kali:~# dotdotpwn -m http-url -u http://localhost/pt/?file=upload/TRAVERSAL
-k "root:" -b -q
[+] Report name: Reports/localhost_09-27-2016_02-56.txt
[========== TARGET INFORMATION ==========]
[+] Hostname: localhost
[+] Protocol: http
[+] Port: 80
[=========== TRAVERSAL ENGINE ===========]
[+] Creating Traversal patterns (mix of dots and slashes)
[+] Multiplying 6 times the traversal patterns (-d switch)
[+] Creating the Special Traversal patterns
[+] Translating (back)slashes in the filenames
[+] Adapting the filenames according to the OS type detected (generic)
[+] Including Special sufixes
[+] Traversal Engine DONE ! - Total traversal tests created: 19680
[=========== TESTING RESULTS ============]
[+] Ready to launch 3.33 traversals per second
[+] Press Enter to start the testing (You can stop it pressing Ctrl + C)
[+] Replacing "TRAVERSAL" with the traversals created and sending
. .
[*] Testing URL: http://localhost/pt/?file=upload/../../../../../../etc/passwd
<- VULNERABLE
[+] Fuzz testing finished after 0

Omijanie filtrów

Jako, że Path Traversal nie jest nową podatnością w świecie bezpieczeństwa IT, większość oprogramowania klasy IDS wykrywa tego typu ataki. Oprogramowanie takie jak IPS czy WAF, stara się aktywnie przeciwdziałać próbom wykorzystania podatności, poprzez blokowanie zapytań zawierających znane ciągi znaków („../” – jego wariacje oraz powielone wystąpienia). W takim przypadku, podatność w aplikacji nadal może istnieć, jednak testujący „odbija” się jedynie od dodatkowej warstwy zabezpieczającej. Tego typu filtry, działają zawsze na bazie czarnych list (ang. Blacklist), w tabeli zaprezentowano podstawowe formy omijania takich filtrów.

Payload Reprezentacja
%2e%2e%2f ../
%2e%2e/ ../
..%2f ../
%2e%2e%5c ..\
%252e%252e%255c ..\
..%255c ..\
..%c0%af ..\
..%c1%9c ..\

Ochrona

Podstawową formą ochrony przed omawianą podatnością, jest odpowiednia walidacja danych wejściowych. Jeżeli to możliwe, zaleca się również wykorzystanie mechanizmów polegające na identyfikacji plików na dysku, np. poprzez unikalne identyfikatory (UUID). Dodatkowo, należy pamiętać o weryfikacji uprawnień do plików (np. odpowiednie uprawnienia, z jakimi uruchomiony jest serwer WWW).

Blokowanie ataku poprzez podmianę tekstu

W aplikacjach WWW, można spotkać się z zabezpieczeniem polegającym na wyszukiwaniu w ścieżce do pliku, wystąpienia ciągu „../”. Zabezpieczenie polega na usunięciu takich ciągów z tekstu reprezentującego nazwę pliku, lub ścieżkę do niego. Jest to dość niefortunne rozwiązanie, ponieważ poprzez prostą manipulację, zabezpieczenie jest łatwe do pokonania. Przekazując do aplikacji poniższy ciąg znaków, tylko jego środkowa część zostanie usunięta:

....//

Usunięcie takiego ciągu ze ścieżki nie uchroni przed podatnością, ponieważ dalej będzie znajdował się w niej ciąg „../”.

Modelowanie zagrożeń

Jeżeli nasza aplikacja wykonuje operacje na plikach lub katalogach, równocze­śnie wykorzystując w tym procesie dane pochodzące z niezaufanych źródeł, warto odpowiedzieć na kilka pytań:

  • Czy dane wykorzystywane przy operacjach na plikach oraz katalogach, są w odpowiedni sposób walidowane?
  • Czy funkcje umożliwiające wgrywanie plików na serwer, nie pozwalają na manipulację ścieżką, pod którą zostanie zapisany plik?
  • Czy wykorzystywane komponenty aplikacji (np. zewnętrzne skrypty) zostały sprawdzone pod kątem podatności na Path Traversal?

Podsumowanie

Atak Path Traversal z pewnością nie jest nowinką, dodatkowo – podobnie jak w przypadku większości podatności – ochrona przed nim sprowadza się do wdrożenia odpowiedniej walidacji danych wejściowych do aplikacji. Bazy gromadzące informacje o błędach w aplikacjach pokazują jednak, że z pewnością nie jest to podatność, o której można już zapomnieć. Nowe aplikacje wciąż pozwalają na skuteczne przeprowadzenie tego ataku, a w konsekwencji – na nieuprawniony dostęp do zasobów, a nawet zdalne wykonanie kodu.

 

Marcin Piosek, analityk bezpieczeństwa IT, realizuje audyty bezpieczeństwa oraz testy penetracyjne w firmie Securitum.

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

  1. 42

    Ostatni listing:
    …..//
    ma chyba 1 kropkę za dużo:
    ….//

    Odpowiedz
    • piochu

      Słuszna uwaga, poprawione.

      Odpowiedz
  2. Anioły Nieba

    Po „nr” nie stawiamy kropki.

    Odpowiedz
    • piochu

      Poprawione :)

      Odpowiedz
  3. Rafał Pokrywka

    Chyba jedna spacja za dużo… „równocze śnie”

    Odpowiedz
  4. Adam

    Przecież wystarczy po znalezieniu „../” i dojściu do końca tekstu przeszukać tekst ponownie (i tak aż do momentu gdy już nie znaleziono tej frazy). I wówczas „….//” zostanie usunięte i dłuższe wariacje też.

    Odpowiedz
    • Michał

      No ale jakie to niewydajne obliczeniowo

      Odpowiedz
    • Cayu

      Panowie, przecież od tego są wyrażenia regularne :)
      Np. w JavaScript:
      str = str.replace(/\.\.+\/+/g, „”);
      Podobnie w PHP z funkcją preg_replace().
      I nie trzeba przeszukiwać parę razy…

      Odpowiedz
      • Darek

        To i ja odezwę się po latach. Wyrażenia regularne również zabierają zasoby obliczeniowe. Przeszukiwanie wielokrotne może wymagać podobnej mocy obliczeniowej co regex. Więc na jedno wychodzi w jaki sposób to sprawdzamy.

        Odpowiedz

Odpowiedz