czyszczenie przejętej strony

Czyszczenie przejętej strony to usunięcie ze strony złośliwego kodu, tylnych furtek (backdoor) i kont napastnika, przywrócenie pierwotnej treści oraz zamknięcie drogi, którą doszło do włamania. Bez ostatniego kroku infekcja zwykle wraca, bo atakujący ponownie korzysta z tej samej luki. CERT Polska opisuje ten proces jako ścieżkę postępowania: od odcięcia serwera, przez analizę i odbudowę, po zmianę wszystkich danych dostępowych ^[1]. Czyszczenie jest częścią szerszego procesu, jakim jest reagowanie na incydenty.

Objawy przejęcia

CERT Polska wymienia typowe skutki przejęcia strony: szkodliwy skrypt w kodzie strony, zwłaszcza w nagłówku lub stopce, fałszywą weryfikację CAPTCHA w stylu ClickFix, podmianę treści (defacement), przekierowania na strony atakujących, SEO spam oraz oznaczenie strony przez wyszukiwarki jako szkodliwej ^[1]. Dokumentacja WordPressa nazywa takie objawy wskaźnikami kompromitacji (IoC). Wymienia wśród nich wpis strony na czarną listę Google lub Binga, wyłączenie strony przez hosting, zgłoszenia od programów antywirusowych czytelników i nieautoryzowane działania, takie jak tworzenie nowych użytkowników ^[2].

Jak przebiega

Kolejność ma znaczenie. Najpierw trzeba zatrzymać atakującego i zachować ślady, dopiero potem usuwać złośliwy kod. Schemat poniżej streszcza zalecenia CERT Polska ^[1].

RYS. 1Postępowanie z przejętą stroną

Odcięcie i ślady. CERT Polska zaleca odcięcie serwera HTTP od sieci, aby uniemożliwić dalszą działalność atakujących, fizycznie, zaporą albo przez tryb serwisowy ^[1]. Bez zwłoki należy zabezpieczyć logi serwera HTTP i logi systemowe ^[1]. Dokumentacja WordPressa radzi zapisać, co i kiedy zauważono oraz jakie zmiany wprowadzano ostatnio, bo to początek raportu z incydentu ^[2]. Zaleca też wykonanie kopii zainfekowanego środowiska przed czyszczeniem, aby w razie awarii mieć punkt odniesienia ^[2].

Analiza. Celem jest znalezienie wektora wejścia. Tabela zbiera miejsca, które wskazują CERT Polska i dokumentacja WordPressa.

Pomocą są skanery złośliwego oprogramowania (malware scanner), zarówno wtyczki, jak i skanery zdalne; dokumentacja WordPressa zaleca łączenie obu rodzajów ^[2]. Zaleca również przeskanowanie komputerów osób z dostępem do strony, bo infekcja często zaczyna się od trojana, który przechwytuje hasła do FTP i panelu ^[2].

Odbudowa. CERT Polska dopuszcza przywrócenie z kopii zapasowej, jeśli znany jest wektor ataku, albo odbudowę od podstaw z czystej instalacji CMS ^[1]. Dokumentacja WordPressa zaleca ponowne wgranie tej samej wersji rdzenia przez FTP lub SFTP zamiast przez panel, bo instalator nadpisuje tylko istniejące pliki, a włamania często dodają nowe ^[2]. Katalogi wp-admin i wp-includes można bezpiecznie zastąpić w całości; wp-content z motywami i wtyczkami wymaga staranniejszego przeglądu ^[2].

W WordPressie

Po odbudowie zmienia się wszystkie dane dostępowe. CERT Polska wymienia hasła do panelu administratora, SSH i FTP, klucze SSH oraz dane logowania użytkowników ^[1]. Dokumentacja WordPressa dodaje wymuszenie zmiany haseł wszystkim użytkownikom, a przede wszystkim administratorom, oraz wymianę kluczy w wp-config.php, która wylogowuje wszystkie aktywne sesje ^[2]; zob. klucze bezpieczeństwa i sole. Hasła zmienia się jeszcze raz po upewnieniu się, że strona jest czysta, a po czyszczeniu aktualizuje się WordPress do najnowszej wersji ^[2].

Na hostingu współdzielonym włamanie mogło objąć więcej niż jedną stronę, dlatego dokumentacja zaleca kontakt z dostawcą hostingu ^[2]. Jeśli wyszukiwarka oznaczyła stronę, po naprawie trzeba poprosić o ponowną weryfikację. W Google Search Console służy do tego raport problemów dotyczących bezpieczeństwa: po usunięciu wszystkich problemów wybiera się prośbę o weryfikację i opisuje wprowadzone poprawki ^[3]. Dla zhakowanych treści i złośliwego oprogramowania weryfikacja trwa od kilku dni do kilku tygodni ^[3]; zob. listę ostrzeżeń przed niebezpiecznymi stronami.

Zapobieganie nawrotom

Czyszczenie bez usunięcia przyczyny kończy się ponowną infekcją. CERT Polska zaleca po incydencie regularne aktualizacje, kopie zapasowe, WAF, 2FA i CAPTCHA, ograniczenie dostępności panelu administratora oraz blokadę wykonywania skryptów PHP w katalogach na przesyłane pliki ^[1]; zob. blokada wykonywania PHP w katalogu uploads. Regularna kopia zapasowa (backup) plików i bazy ułatwia przywrócenie strony po infekcji ^[1].

Dokumentacja WordPressa zaleca też jak najściślejsze uprawnienia plików, luzowane tylko na czas potrzebnego zapisu ^[5], oraz monitorowanie, bo zapobieganie czasem nie wystarcza ^[5]. Atak zawsze zostawia ślady w logach albo w systemie plików, w postaci nowych i zmienionych plików ^[5]; wychwytuje je monitorowanie integralności plików. Stała DISALLOW_FILE_EDIT wyłącza edytor plików motywów i wtyczek, co według dokumentacji daje dodatkową warstwę ochrony, gdy atakujący przejmie konto z wysokimi uprawnieniami ^[6].

define( 'DISALLOW_FILE_EDIT', true );

CERT Polska zaleca też zgłoszenie incydentu do właściwego CSIRT, niezależnie od skali infekcji ^[1].

Historia i przykłady

Źródłem infekcji bywa sama wtyczka. Sekurak 20 grudnia 2017 roku opisał wtyczkę CAPTCHA z około 300 000 instalacji, do której po zmianie właściciela trafiła tylna furtka ^[4]. Kod dawał nieautoryzowany dostęp administracyjny, a wersja 4.4.5 została z niego wyczyszczona ^[4]. Sekurak zalecał zastąpienie wtyczki i sprawdzenie, czy ktoś już skorzystał z dostępu ^[4]. Przykład pokazuje, że samo usunięcie złośliwego pliku nie wystarcza, gdy wektorem jest składnik, który przy następnej aktualizacji może wrócić.