W kopii firmowej strony klienta znalazłem wtyczkę, która robotom wyszukiwarek podsuwała stronę ze spamem hazardowym, a atakującemu dawała dostęp do plików serwera. Była tak pomyślana, żeby zwykły odwiedzający niczego nie zauważył. Usunąłem infekcję, zaktualizowałem oprogramowanie i przygotowałem sprawdzoną paczkę do wdrożenia na wyczyszczony serwer.
Problem
Klient przekazał mi kopię plików i bazy danych swojej firmowej strony na WordPressie z informacją, że strona została zainfekowana. Zadanie obejmowało analizę, usunięcie infekcji, uruchomienie strony na kopii i przygotowanie bezpiecznego wdrożenia. Całą pracę wykonałem na odizolowanej kopii lokalnej, bez ingerencji w działający serwer.
Na tym samym koncie hostingowym działała druga witryna klienta, której naprawę opisuję w osobnym case study. Od początku zakładałem więc, że strony mogą być powiązane, ale każdą analizowałem osobno.
Co ustaliłem
Zacząłem od rozpoznania: WordPress w starszej wersji, własny motyw i ponad dwadzieścia wtyczek, z których część od dawna nie była aktualizowana. Pliki rdzenia i wszystkich wtyczek pochodzących z oficjalnego repozytorium porównałem z sumami kontrolnymi publikowanymi przez WordPress.org. Nie znalazłem w nich żadnych zmian.
Źródłem problemu okazała się dodatkowa wtyczka udająca narzędzie administracyjne. Przeanalizowałem jej kod bez uruchamiania i ustaliłem, że:
- przekierowywała roboty wyszukiwarek na podstawioną stronę reklamującą hazard online, podczas gdy zwykli odwiedzający widzieli normalną witrynę (tzw. cloaking),
- umieszczała w katalogu głównym plik weryfikacyjny, który pozwala przypisać witrynę do obcego konta w narzędziach dla webmasterów,
- zawierała menedżer plików pozwalający przeglądać, zmieniać i wysyłać pliki na serwer.
Zapis w bazie danych pokazał, że wtyczkę aktywowano z panelu WordPressa około pół roku przed zgłoszeniem, a do tego potrzebne są uprawnienia administratora. W chwili analizy pliki wtyczki miały już zmienione rozszerzenia, więc ktoś je wcześniej unieszkodliwił. Nie zostały jednak usunięte, a w bazie pozostał ślad instalacji. W ukrytej liście fraz w stopce motywu znalazłem też dwa wpisy związane z hazardem; nie udało się ustalić, kto je dodał.
Nie miałem dostępu do logów serwera, dlatego drogi wejścia nie da się wskazać z pewnością. Dziennik wtyczki bezpieczeństwa zawierał ponad 1400 nieudanych prób logowania w ciągu niespełna dwóch miesięcy, także na nazwę rzeczywistego administratora, a konta nie miały weryfikacji dwuetapowej. Za najbardziej prawdopodobne uznałem przejęcie hasła administratora. Nie wykluczam jednak luki w którejś z nieaktualnych wtyczek.
Co zrobiłem
- Przed jakąkolwiek zmianą wykonałem kopie plików i bazy poza katalogiem udostępnianym przez serwer.
- Złośliwe pliki przeniosłem do kwarantanny zamiast je kasować, żeby zachować materiał do analizy.
- Usunąłem ślad wtyczki z bazy, unieważniłem wszystkie sesje logowania i wygenerowałem nowe klucze zabezpieczające.
- Zaktualizowałem WordPressa i wszystkie wtyczki, a po aktualizacji ponownie sprawdziłem sumy kontrolne.
- Nieużywane wtyczki wyłączyłem (bez usuwania), a edycję plików z poziomu panelu zablokowałem.
- Zmieniłem adres logowania do panelu. Dotychczasowy był już znany z zewnątrz, co widać było w dzienniku błędów 404.
- Przygotowałem konfigurację, która sama rozpoznaje środowisko. Dzięki temu tę samą paczkę można testować lokalnie i wgrać na serwer produkcyjny.
Podczas testów wyszła rzecz łatwa do przeoczenia. Po aktualizacji wtyczka bezpieczeństwa sama przepisała w pliku konfiguracyjnym serwera regułę ochrony obrazów tak, że wskazywała adres kopii lokalnej. Po wdrożeniu zdjęcia na stronie przestałyby się wyświetlać. Poprawiłem regułę i dodałem skrypt, który przed każdym wdrożeniem wychwytuje ten i podobne problemy.
Rezultat
Na kopii lokalnej wszystkie 147 opublikowanych adresów (strony, wpisy i karty oferty) odpowiadało poprawnie, panel administracyjny działał, a ponowne skanowanie plików i bazy nie wykazało śladów infekcji. Klient dostał paczkę plików i eksport bazy, sprawdzone próbnym importem do pustej bazy danych.
Ważne zastrzeżenie: wszystkie testy wykonałem na kopii. Wdrożenie na serwer produkcyjny i kontrola strony po wdrożeniu to osobny krok. Pełnej wysyłki formularzy nie dało się sprawdzić lokalnie, bo zabezpieczenie antyspamowe jest przypisane do domeny produkcyjnej.
Klient otrzymał listę działań na po wdrożeniu: zmianę wszystkich haseł i kluczy, usunięcie obcej weryfikacji w narzędziach dla webmasterów, włączenie weryfikacji dwuetapowej i przegląd kont administratorów. Wskazałem też przypadkowy tekst doklejany do stron przez konfigurację menedżera tagów. To nie była infekcja, ale wymaga poprawki w jego panelu.
Wnioski
- Unieszkodliwienie złośliwego pliku to nie to samo co usunięcie infekcji. Ślady w plikach i bazie przetrwały tu miesiące.
- Setki prób logowania i brak weryfikacji dwuetapowej to realne ryzyko. Każde konto administratora powinno mieć silne hasło i 2FA, a lista kont powinna być regularnie przeglądana.
- Aktualizacje trzeba sprawdzać już po wykonaniu. Wtyczki potrafią zmienić konfigurację serwera w sposób, który ujawniłby się dopiero na produkcji.
- Bez logów serwera przyczyny włamania często nie da się potwierdzić. Warto zadbać o ich przechowywanie, zanim będą potrzebne.
Podejrzewasz, że Twój WordPress został zainfekowany?
Analizuję kopię strony, usuwam złośliwy kod, aktualizuję i zabezpieczam witrynę, a potem przygotowuję bezpieczne wdrożenie — bez eksperymentów na działającej stronie. Napisz do mnie, a zaproponuję plan działania. Zobacz też, na czym polega odwirusowanie strony WordPress.
