Remote File Inclusion
Z tego artykułu dowiesz się, jak w praktyce wygląda szukanie błędu typu Remote File Inclusion w kodzie aplikacji na przykładzie Ottoman CMS.
Opiszę realny błąd znaleziony przeze mnie w aplikacji CMS – Ottoman. Błąd pozwalał na zdalne uruchomienie dowolnego kodu na serwerze. Znaleziony błąd zalicza się do klasy Remote File Inclusion i jest jednym z najbardziej poważnych błędów w aplikacjach WWW, pod względem skutków udanego ataku.
Na czym polega błąd w przypadku aplikacji Ottoman CMS.
Aplikacja używa zmiennej o nazwie “default_path” w celu dołączania plików php. Parametr “default_path” występuje w plikach “index.php”, “error.php”, “classes/main_class.php”, “format_css.php”, “js.php”, oraz “rss.php”.
Przyjrzyjmy się fragmentowi błędnie napisanego kodu z pliku rss.php (analogicznie jest w pozostałych plikach).
Linie 13-17 rss.php:
<p style="text-align: justify;">// Avoid remote file inclusion
if (isset($_GET['default_path'])) {
unset($_GET['default_path']);
$default_path = NULL;
}
Jak możemy zauważyć, programista zabezpiecza zmienną “default_path” przed błędami remote file inclusion. Zerowany jest zmienna dostarczana do aplikacji metodą GET. Programiści nie zabezpieczyli jednak pozostałych miejsc, poprzez które można zainicjalizować zmienne. Dla przypomnienia – użytkownik ma do dyspozycji jeszcze zmienne POST COOKIE i SESSION. Ta ostatnia nie jest w tym przypadku użyteczna.
Brak zerowania pozostałych zmiennych nie jest jeszcze samym zagrożeniem. Przyjrzyjmy się fragmentowi kodu, znajdującego się w liniach 19-24:
// Include Required Files
require_once $default_path.'config.php';
require_once $default_path.'format.php';
require_once $default_path.'classes/error_class.php';
require_once $default_path.'classes/validate_class.php';
require_once $default_path.'classes/main_class.php';
Funkcja require_once dołącza do skryptu plik znajdujący się w ścieżce która jest pod zmienną “default_path” oraz jego nazwa kończy się np. na “config.php”. Skrypt nie sprawdza, czy zmienna “default_path” jest wcześniej zainicjowana ani nie zeruje zmiennych POST oraz COOKIE. Jest to poważny błąd.
Jak go można wykorzystać?
Możemy wykorzystać np. zmienną POST do wykonania dowolnego własnego pliku na serwerze obsługującym aplikację OTTOMAN. Do tego celu możemy wykorzystać np. plugin LiveHTTPHeaders, inicjując parametr “default_path”, za który podstawiamy adres własnego serwera, ścieżkę do pliku i umieścimy tam plik o nazwie np. config.php, który będzie zawierał funkcję, np. system(), która pozwala wykonywać polecenia na serwerze. Polecenia do wykonania, przekażemy jako parametr naszego skryptu.
W celu zautomatyzowania ataku i wykonanie mini “shella” możemy napisać prosty skrypt np. w perlu.
Ciekawostka
Przed wykryciem błędu przeze mnie, aplikacja była podatna na RFI za pomocą GET. Błąd pozwalał na wykorzystanie do ataku metody GET, czyli przeprowadzenie ataku z wykorzystaniem jedynie przeglądarki i uruchomieniem ataku przez adres URL.
Po publikacji błędu na GET programiści zabezpieczyli zmienną GET, zapomnieli jednak o zmiennych POST i COOKIE, jak już wcześniej napisałem.
Niepoprawne wdrożenie zabezpieczenia, świadczy o tym, że praca programisty i dobrego specjalisty od bezpieczeństwa jest często trudna i wymaga ciągłego dokształcania się w aspektach zabezpieczeń.
