Trzy zainfekowane WordPressy w jeden dzień: co znaleźliśmy na serwerach

Trzy strony, trzy różne infekcje, jeden dzień

To nie był dzień zaplanowany na bezpieczeństwo. Jedna firma zgłosiła, że po aktualizacji „zniknęły zdjęcia”. Druga, że panel administracyjny nagle wyrzuca błąd 403. Trzecia poprosiła o zwykły przegląd. W każdym z tych trzech przypadków na serwerze siedział aktywny kod atakującego, a właściciel strony nie miał o tym pojęcia.

Nazw nie podajemy. Opisujemy mechanizmy, bo to one się powtarzają i to one są warte przeczytania przez każdego, kto ma stronę na WordPressie.

Przypadek pierwszy: aktualizacja nie zepsuła strony, tylko zepsuła malware

Objaw był prozaiczny. Po aktualizacji WordPressa wszystkie zdjęcia przestały się wyświetlać. Nie błąd 404, tylko 500 i to wyłącznie na plikach, które naprawdę istniały. To sygnał, że żądanie do obrazka nie trafia do pliku, tylko przechodzi przez kod PHP, który się wywala.

W panelu wtyczek stały dwie pozycje o nazwach brzmiących jak coś systemowego: jedna udająca wtyczkę cache, druga „usługę rdzenia”. Żadna z nich nie istnieje w oficjalnym repozytorium. Do tego w katalogu wtyczek wymuszanych, czyli takich, których nie da się wyłączyć z panelu, leżał plik ładujący jedną z nich przy każdym żądaniu.

Pod spodem było gorzej. Rozkodowany kod pokazał webshell o wadze 154 kB, ukryty pod nazwą udającą plik sesji WordPressa, z komunikacją do serwera sterującego w Stanach Zjednoczonych i z zapasowym adresem schowanym za siecią dostarczania treści. Mechanizm był prosty i skuteczny:

• co minutę sprawdzał, czy shell nadal jest na dysku, a jeśli go usunąłeś, pobierał go z powrotem,
• wtyczka wyłączona w panelu wracała na listę aktywnych przy każdym wejściu do administracji, bo dopisywał ją plik z katalogu wtyczek wymuszanych,
• wywołanie jednego adresu z odpowiednim parametrem odtwarzało konto administratora, które właściciel wcześniej ręcznie skasował.

Kopie zapasowe shella siedziały w plikach graficznych o nazwach banner.gif, logo.png i avatar.jpg, każdy po około 157 kB. Uruchamiała je reguła w pliku konfiguracyjnym serwera, a druga kopia tej reguły leżała katalog wyżej, poza zasięgiem menedżera plików z panelu hostingu. W katalogu głównym znaleźliśmy też plik z wykradzionymi danymi logowania i skrypt do ataków na inne serwery.

Przypadek drugi: dla ludzi firma techniczna, dla Google sklep z podróbkami

Tu objawem był błąd 403 przy logowaniu do panelu. Przy okazji sprawdziliśmy, co widzi wyszukiwarka, i to była właściwa niespodzianka.

Ten sam adres zwracał dwie różne strony zależnie od tego, kto pyta. Przeglądarka dostawała normalną stronę firmy. Robot Google dostawał podrobiony sklep z zegarkami i odzieżą, ze zdjęciami zaciąganymi z zagranicznych serwisów aukcyjnych. Mapa strony zgłoszona do Google miała 1829 adresów, z czego 1828 było fałszywych, a data ostatniej modyfikacji we wszystkich wpisach była ustawiona na dzień do przodu, żeby zawsze wyglądały świeżo.

Błąd 403 też okazał się dziełem atakującego. W pliku konfiguracyjnym serwera siedziała reguła blokująca wykonanie wszystkich plików PHP poza krótką białą listą, a na tej liście były nazwy webshelli. Oryginalny plik WordPressa leżał obok, odłożony pod inną nazwą.

Na tym samym koncie hostingowym działała koparka kryptowalut: binarka o wadze 8,3 MB podszywająca się pod systemowy plik linkera, kopiąca do publicznej puli, w trzech kopiach, uruchamiana ponownie przy każdym logowaniu do powłoki i celowo ustawiona na najniższy priorytet procesora, żeby nie rzucać się w oczy w statystykach hostingu.

To już nie jest „zainfekowana strona”. To przejęte konto hostingowe, na którym strona jest tylko jednym z uruchomionych programów.

Przypadek trzeci: backdoor, który ukrywał się przed administratorem

Trzecia strona wyglądała idealnie. Wtyczki legalne, użytkownicy w porządku, motyw standardowy, rdzeń aktualny. A jednak.

W katalogu wtyczek wymuszanych leżał plik podający się za narzędzie „pobierające aktualizacje wtyczek ze zdalnego serwera”. Miał dwa mechanizmy ukrywania i oba są warte zapamiętania.

Ukrywał się w panelu. Zakładka z wtyczkami wymuszanymi pokazywała licznik „1”, tabela pod spodem deklarowała dwa elementy, a widoczny był jeden wiersz. Backdoor ustawiał swój własny wiersz na niewidoczny, i to nie w kodzie źródłowym strony, tylko już po jej załadowaniu, więc podejrzenie źródła niczego nie dawało.

Ukrywał się na stronie. Strona pobrana jako anonimowy użytkownik ważyła o 130 kB więcej niż ta sama strona oglądana przez zalogowanego administratora. Te 130 kB to był blok wsunięty w treść i odsunięty poza ekran, zawierający 58 linków do 81 obcych domen: kasyna z kilku krajów i przejęte sklepy. Właściciel nie mógł tego zobaczyć, bo dla niego, jako zalogowanego, ten kod się nie pojawiał. Widział go Googlebot.

Pięć rzeczy, które te przypadki mają wspólne

Różne mechanizmy, różne cele, ta sama lista wniosków.

1. Nikt nie zauważył włamania. W żadnym z trzech przypadków nie zgłosiło go monitorowanie ani właściciel. Wyszło przy okazji: przez zepsute zdjęcia, przez błąd w panelu, przez rutynowy przegląd. Dobrze napisany malware nie psuje strony, bo popsuta strona zostaje naprawiona.
2. Wyłączenie to nie usunięcie. Wtyczki wymuszane ładują się zawsze, niezależnie od tego, co klikniesz w panelu. Dwukrotnie widzieliśmy, jak deaktywowana wtyczka wraca na listę aktywnych w ciągu jednego odświeżenia.
3. Panel administracyjny to najgorsze narzędzie do sprzątania. Nie pokazuje plików, w których siedzi problem, a na zainfekowanej stronie sam może być podstawiony. Czyszczenie robi się po SSH albo po FTP, z odczytem plików przed skasowaniem.
4. Kopia zrobiona po włamaniu to dowód, nie punkt przywracania. Zawiera malware. Do odtworzenia potrzebna jest kopia sprzed infekcji, a żeby wiedzieć, która to, trzeba najpierw ustalić datę wejścia.
5. Kwarantanna hostingu to wykrycie, nie naprawa. Na jednym z serwerów część plików miała już dopisane rozszerzenie oznaczające plik zainfekowany. Hosting zauważył infekcję wcześniej niż ktokolwiek inny i na tym poprzestał.

Jeżeli cokolwiek z tej listy brzmi znajomo, zacznij od ustalenia faktów, a nie od kasowania plików. Robimy takie rozpoznanie i czyszczenie jako osobną usługę: odwirusowanie WordPressa i naprawa zhakowanej strony.

Dlaczego brak aktualizacji jest ryzykiem, ale sama aktualizacja niczego nie załatwia

Drogą wejścia w każdym z tych przypadków był kod dodany do WordPressa: wtyczka, motyw albo publicznie dostępny punkt interfejsu programistycznego. Rdzeń sam w sobie jest pilnowany dobrze, problem robi się tam, gdzie dokłada się kolejne rozszerzenia.

Im dłużej wtyczka nie jest aktualizowana, tym dłużej znana publicznie luka stoi otworem. Atakujący nie szukają konkretnej firmy. Skanują internet pod kątem konkretnej wersji konkretnej wtyczki i wchodzą tam, gdzie zadziała. Twoja strona nie musi być ciekawa, żeby być celem: wystarczy, że jest podatna, bo i tak posłuży do kopania kryptowalut, wysyłania spamu albo pozycjonowania cudzych podróbek.

Ale trzeba powiedzieć też drugą część. Aktualizacja nie czyści strony, która jest już zainfekowana. W pierwszym z opisanych przypadków aktualizacja rdzenia nie usunęła niczego, tylko sprawiła, że malware przestało działać poprawnie. To był łut szczęścia, nie zabezpieczenie.

Aktualizacje w stałym rytmie, kopie poza serwerem i monitorowanie zmian w plikach to rzeczy, które ktoś musi robić regularnie, bo „przy okazji” znaczy nigdy. U naszych klientów robimy to w ramach opieki nad stroną.

Dlaczego my budujemy w Astro, Reakcie i Sanity

Każdy z opisanych ataków potrzebował jednej rzeczy: możliwości wykonania kodu na serwerze, który serwuje stronę. Webshell to plik PHP. Koparka odpalała się z konta powłoki. Podmiana treści dla robota to reguła serwera wskazująca na skrypt. Backdoor był wtyczką, czyli kodem uruchamianym przy każdym wejściu na stronę.

Strona zbudowana w Astro albo w Reakcie i wdrożona jako zestaw plików statycznych nie ma takiego miejsca. Konkretnie:

• Na serwerze nie wykonuje się żaden kod strony. Odwiedzający dostaje gotowy plik HTML z sieci dostarczania treści. Nie ma interpretera, do którego można podrzucić plik.
• Nie ma katalogu z przesłanymi plikami, który potrafi cokolwiek uruchomić. Obrazek jest obrazkiem, nawet jeśli ktoś wklei do niego kod.
• Nie ma ekosystemu wtyczek do pilnowania. Funkcje, których potrzebujemy, piszemy albo bierzemy z bibliotek widocznych w historii zmian, a nie instalujemy jednym kliknięciem z zewnętrznego katalogu.
• Treść siedzi w Sanity, czyli w systemie zarządzania treścią utrzymywanym przez dostawcę, z własnym logowaniem i historią zmian. Pod adresem strony nie ma panelu, który można całą dobę atakować słownikiem haseł.
• Każde wdrożenie idzie z repozytorium. Każda zmiana w kodzie jest różnicą, którą ktoś zatwierdził. Plik, który pojawia się na serwerze sam z siebie, po prostu nie ma jak tam trafić, a najbliższe wdrożenie i tak nadpisałoby stan serwera.
• Cofnięcie zmian to jedno kliknięcie. Poprzednia wersja strony jest wdrożeniem, do którego można wrócić w kilkanaście sekund, bez odtwarzania bazy danych.

To nie jest magiczna odporność. Można źle skonfigurować formularz, wystawić klucz interfejsu programistycznego albo stracić konto przez brak dwuskładnikowego logowania. Ale cała klasa ataków opisanych wyżej, czyli wrzucenie pliku, który wykonuje się przy każdym żądaniu, po prostu nie ma na czym się oprzeć.

Jeśli Twoja strona co chwilę wymaga ratowania, policz, ile kosztuje utrzymywanie jej przy życiu przez rok. Często wychodzi drożej niż przebudowa na nowy fundament, a przy okazji znika cała ta kategoria problemów.

A jeśli WordPress zostaje

Nie każdą stronę trzeba od razu przepisywać. Jeśli WordPress zostaje, to minimum wygląda tak:

• aktualizacje rdzenia, wtyczek i motywów w rytmie tygodniowym, a nie „przy okazji”,
• usunięcie wszystkich wtyczek i motywów, których nie używasz, bo nieaktywny kod też jest kodem leżącym na serwerze,
• dwuskładnikowe logowanie dla każdego konta z uprawnieniami administratora i zero kont zakładanych „na wszelki wypadek”,
• kopie zapasowe trzymane poza serwerem strony, z historią liczoną w tygodniach, a nie w dniach, żeby było do czego wracać po wykryciu infekcji sprzed miesiąca,
• monitorowanie zmian w plikach, bo to jedyna rzecz, która zauważa włamanie, zanim zauważy je Google.

I jedna rzecz z doświadczenia tego jednego dnia: jeżeli podejrzewasz infekcję, nie zaczynaj od kasowania. Najpierw odczyt, potem kwarantanna, dopiero na końcu usunięcie. Skasowany na ślepo plik zabiera ze sobą informację o tym, co jeszcze zdążył zainstalować.

Czym możemy pomóc

Trzy różne sytuacje, trzy różne rozmowy:

• Podejrzewasz, że strona jest zainfekowana. Zaczynamy od rozpoznania: co siedzi na serwerze, od kiedy i jaki ma zasięg. Odwirusowanie WordPressa.
• Strona działa, ale nikt jej nie pilnuje. Aktualizacje, kopie poza serwerem i monitorowanie zmian w plikach w stałym rytmie. Opieka nad stroną.
• Masz dość ratowania tej strony. Przebudowa na architekturę, w której nie ma czego zaatakować. Przebudowa strony albo nowa strona od zera.

Nie wiesz, która z tych dróg jest Twoja? Audyt strony odpowiada na to pytanie liczbami, a nie przeczuciem.