Jak sprawdzić, czy WordPress jest zainfekowany: objawy i siedem kontroli

Dlaczego nie wystarczy zapytać, czy strona działa

Dobrze napisane złośliwe oprogramowanie nie psuje strony. Popsuta strona zostaje szybko naprawiona, a włamanie wychodzi na jaw. Dlatego większość infekcji, które czyściliśmy, latami działała w tle: strona wyglądała normalnie, formularze wysyłały wiadomości, a w tym czasie serwer kopał kryptowaluty albo pokazywał Google sklep z podróbkami.

Poniżej są objawy, które widzieliśmy na prawdziwych serwerach, i kontrole, które możesz zrobić sam albo zlecić osobie z dostępem do serwera. Opis konkretnych przypadków jest we wpisie trzy zainfekowane WordPressy w jeden dzień.

Objawy, które widać bez zaglądania na serwer

• Dziwne błędy po aktualizacji. W jednym przypadku po aktualizacji WordPressa przestały działać wszystkie zdjęcia, z błędem 500. Aktualizacja niczego nie zepsuła. Zepsuła malware, które przechwytywało żądania do plików.
• Błąd 403 przy logowaniu do panelu. Widzieliśmy regułę serwera, która blokowała wszystkie pliki PHP poza krótką listą, a na tej liście były pliki atakującego.
• Konto administratora, którego nikt nie zakładał, albo konto skasowane ręcznie, które po jakimś czasie wraca.
• Wtyczka o nazwie brzmiącej systemowo, na przykład udająca cache albo „usługę rdzenia”, której nie ma w oficjalnym katalogu wtyczek.
• Wtyczka wyłączona w panelu, która znowu jest aktywna po odświeżeniu strony.
• Dziwne wyniki w Google. Tytuły po japońsku, niemiecku albo o produktach, których nie sprzedajesz, i adresy w Twojej domenie, których nie tworzyłeś.
• Wiadomość od hostingu o podejrzanych plikach, zbyt dużym obciążeniu albo o plikach przeniesionych do kwarantanny. Kwarantanna hostingu to wykrycie, a nie naprawa.
• Ostrzeżenie w Search Console w raporcie problemów z bezpieczeństwem albo ostrzeżenie przeglądarki przy wejściu na stronę.

Każdy z tych objawów osobno może mieć niewinne wyjaśnienie. Dwa naraz to już powód, żeby sprawdzić serwer.

Siedem kontroli, które warto zrobić

1. Lista użytkowników

W panelu wejdź w Użytkowników i przefiltruj administratorów. Każde konto, którego nie rozpoznajesz, jest podejrzane. Nie kasuj go od razu: zapisz nazwę, adres e-mail i datę utworzenia, bo pomogą ustalić, kiedy doszło do włamania.

2. Wtyczki wymuszane

W katalogu wp-content/mu-plugins leżą wtyczki, które ładują się zawsze i nie da się ich wyłączyć z panelu. To ulubione miejsce na backdoory. Na zwykłej stronie ten katalog jest pusty albo zawiera pliki od hostingu. Sprawdź go przez FTP lub SSH, a nie w panelu, bo w jednym z naszych przypadków backdoor ukrywał swój własny wiersz na liście wtyczek wymuszanych.

3. Pliki PHP w katalogu z przesłanymi plikami

W wp-content/uploads powinny być obrazki, dokumenty i filmy. Plik .php w tym katalogu prawie zawsze jest śladem włamania. Uważaj też na obrazki o podejrzanie dużej wadze i dziwnych nazwach: widzieliśmy kopie webshella zapisane jako logo.png i banner.gif, uruchamiane regułą serwera.

4. Pliki konfiguracyjne serwera

Przejrzyj plik .htaccess w katalogu strony i katalog wyżej. Szukaj reguł, które kierują żądania do nieznanych skryptów, obsługują obrazki jak kod PHP albo przekierowują odwiedzających z Google na inne domeny.

5. Sumy kontrolne rdzenia i wtyczek

Jeśli masz dostęp do WP-CLI, polecenia wp core verify-checksums i wp plugin verify-checksums --all porównują pliki na serwerze z oryginałami z repozytorium WordPressa. Każdy zmieniony albo dodatkowy plik dostaje ostrzeżenie. To nie obejmuje wtyczek kupionych poza oficjalnym katalogiem, ale rdzeń i darmowe wtyczki sprawdza w kilka sekund.

6. Ostatnio zmienione pliki i zadania cykliczne

Lista plików PHP zmienionych w ostatnim miesiącu, na przykład find . -name "*.php" -mtime -30, szybko pokazuje, co ktoś dopisał. Sprawdź też zadania cykliczne: te w WordPressie (wp cron event list) i te na koncie hostingowym. W jednym z naszych przypadków webshell co minutę sprawdzał, czy nadal jest na dysku, i pobierał się z powrotem po skasowaniu.

7. Porównanie strony z zewnątrz

Otwórz stronę jako zalogowany administrator i w oknie prywatnym, a potem porównaj kod źródłowy. Na jednej ze stron wersja dla niezalogowanych ważyła o 130 kB więcej, bo zawierała ukryty blok z 58 linkami do 81 obcych domen. Właściciel go nie widział, bo dla zalogowanych ten kod się nie pojawiał. Jak sprawdzić, co widzi Google, opisujemy w osobnym wpisie o cloakingu, czyli różnej treści dla ludzi i dla Google.

Czego nie robić, gdy coś znajdziesz

• Nie zaczynaj od kasowania. Skasowany na ślepo plik zabiera informację o tym, co jeszcze zdążył zainstalować i od kiedy działa. Najpierw odczyt, potem kwarantanna, na końcu usunięcie.
• Nie przywracaj ostatniej kopii zapasowej bez sprawdzenia. Kopia zrobiona po włamaniu zawiera malware. Najpierw trzeba ustalić datę wejścia, potem wybrać kopię sprzed niej.
• Nie licz na samą aktualizację. Aktualizacja zamyka lukę, którą ktoś wszedł, ale nie usuwa tego, co już zostawił.
• Nie sprzątaj z panelu. Panel nie pokazuje plików, w których siedzi problem, a na zainfekowanej stronie sam może być podstawiony.
• Zmień hasła dopiero po usunięciu infekcji, i to wszystkie: do panelu, FTP, bazy danych i hostingu. Nowe hasło wpisane na zainfekowanej stronie może trafić prosto do atakującego.

Kiedy oddać to komuś

Jeśli po tych kontrolach masz choć jeden twardy ślad, na przykład nieznane konto administratora, plik PHP w katalogu z przesłanymi plikami albo obce adresy w Google, infekcja jest prawie na pewno głębsza niż to, co widać. Robimy rozpoznanie i czyszczenie po SSH, z ustaleniem daty i drogi wejścia: odwirusowanie WordPressa i naprawa zhakowanej strony. Jeśli strona jest już czysta, ale nikt jej regularnie nie pilnuje, zajrzyj do opieki nad stroną.