Jeśli po otrzymaniu jednego z moich powiadomień o bezpieczeństwie zaktualizowałeś wtyczkę lub swój system CMS, to dobrze. To był ten najważniejszy krok i dla wielu stron jedyny potrzebny.

Aktualizacja zamyka lukę od tej chwili. Nie powie Ci jednak, czy ktoś znalazł tę lukę, zanim ją zamknąłeś. Ta strona to praktyczne samodzielne sprawdzenie, zajmujące około 30 minut, które pozwoli Ci samemu odpowiedzieć na to pytanie. Napisałem ją dla właścicieli stron, którzy nie mają przygotowania z zakresu bezpieczeństwa ani budżetu na ten cel. To ogólne wskazówki, a nie ustalenie dotyczące Twojej strony: z zewnątrz widzę tylko, jaką wersję oprogramowania zgłasza strona, i nic ponadto.

Krok 1: Sprawdź, co ta luka mogła faktycznie umożliwić

Nie każda podatność zasługuje na taką samą reakcję. Znajdź swoje powiadomienie na stronie z powiadomieniami i sprawdź, do której klasy się zalicza (każda strona powiadomienia podaje to blisko początku):

  • Przejęcie konta lub wykonanie kodu (atakujący mógł uzyskać dostęp administratora albo uruchomić własny kod): przejdź całą poniższą listę kontrolną.
  • Odczyt danych (atakujący mógł odczytać informacje z Twojej bazy danych, ale nie mógł zmienić strony): skup się na krokach 2 i 5. Pytanie brzmi, jakie dane były przechowywane, a nie czy Twoja strona została zmieniona.
  • Węższe problemy (luki wymagające określonej konfiguracji albo sięgające wyłącznie ekranu administratora): strona powiadomienia dla Twojego komponentu mówi, co ewentualnie warto sprawdzić. Często sama aktualizacja wystarczy.

Krok 2: Ustal swoje okno narażenia

Okres, który ma znaczenie, wyznaczają dwie daty:

  1. Kiedy luka otworzyła się na Twojej stronie. Zwykle jest to dzień, w którym zainstalowałeś wersję, której dotyczy problem. Jeśli nie znasz tej daty, rozsądnym zamiennikiem jest data biuletynu CVE przywołanego w powiadomieniu (odnośnik znajdziesz na każdej stronie powiadomienia): od publikacji atakujący też już wiedzieli.
  2. Kiedy zaktualizowałeś. Dzień, w którym ją zamknąłeś.

Wszystko poniżej dotyczy tego okna. Jeśli jest krótkie, powiedzmy zaktualizowałeś w ciągu dnia lub dwóch od publikacji biuletynu, ryzyko jest realne, ale niewielkie. Jeśli okno liczy się w miesiącach, potraktuj tę listę kontrolną poważnie.

Krok 3: Sprawdź, kto ma dostęp do Twojej strony

Atakujący, któremu udało się wejść, prawie zawsze zostawia sobie drogę powrotną. Sprawdź po kolei:

  • Konta administratorów. W WordPressie: Użytkownicy, następnie filtruj według Administrator. W Joomli: Użytkownicy, następnie Menedżer użytkowników. Poszukaj kont, których sam nie zakładałeś. Zastrzeżenie: niektóre luki (na przykład ta w Simple Membership) pozwalają atakującemu przejąć istniejące konto zamiast tworzyć nowe, więc samo to sprawdzenie niczego nie dowodzi. Właśnie dlatego zmiana danych uwierzytelniających z kroku 4 ma znaczenie nawet wtedy, gdy lista użytkowników wygląda czysto.
  • Niedawno dodane wtyczki, motywy lub rozszerzenia, których sam nie instalowałeś.
  • Zaplanowane zadania (WordPress: pokazuje je wtyczka WP Crontrol; wiele backdoorów instaluje się ponownie właśnie z zaplanowanego zadania).
  • Hasła aplikacji (WordPress: Użytkownicy, Profil, Hasła aplikacji), czyli dyskretny sposób na zachowanie dostępu przez API po zmianie hasła.

Krok 4: Zmień dane uwierzytelniające

Jeśli Twoje powiadomienie należało do klasy przejęcia konta lub wykonania kodu, a okno narażenia trwało dłużej niż kilka dni, zmień je nawet wtedy, gdy krok 3 niczego nie wykazał:

  • Hasła do wszystkich kont administratorów.
  • Klucze tajne i sole w pliku wp-config.php (WordPress). To wylogowuje wszystkich, łącznie z atakującym, który ma wykradzioną sesję; świeże wartości poda oficjalny generator. W Joomli odpowiednikiem jest wartość $secret w pliku configuration.php.
  • Hasła do panelu hostingu oraz do FTP/SFTP, jeśli są stare albo współdzielone z kimś jeszcze.

Kosztuje to dziesięć minut i zamyka drogę wykradzionym sesjom oraz złamanym skrótom haseł, niezależnie od tego, czy do włamania w ogóle doszło.

Krok 5: Przeskanuj i sprawdź pliki

  • Uruchom skanowanie antywirusowe swojego dostawcy hostingu, jeśli panel je oferuje (większość hostingów współdzielonych tak), albo skorzystaj z renomowanego darmowego skanera. W przypadku WordPressa darmowe skanowanie Wordfence porównuje Twoje pliki z oficjalnymi kopiami.
  • Przyjrzyj się niedawno zmodyfikowanym plikom z okresu wokół i po początku Twojego okna narażenia, zwłaszcza plikom PHP w katalogach z przesłanymi plikami. Tam praktycznie nigdy nie powinno być kodu PHP.
  • Jeśli Twój dostawca hostingu przechowuje logi dostępu, przejrzyj to okno pod kątem żądań do podatnego komponentu z adresów, których nie rozpoznajesz. Brak śladów niewiele tu dowodzi, bo logi się nadpisują, ale trafienie rozstrzyga sprawę.

Jeśli samodzielne sprawdzenie coś wykaże

Niczego jeszcze nie usuwaj. Najpierw wykonaj pełną kopię zapasową, plików i bazy danych, tak aby to, co się wydarzyło, dało się jeszcze zbadać. Potem, w kolejności od najtańszego:

  1. Twój dostawca hostingu. Większość oferuje usługę usuwania złośliwego oprogramowania albo przynajmniej potwierdzi, co widzą ich własne skanery. Dla większości małych stron to właściwy pierwszy telefon.
  2. Specjalista. Jeśli strona obsługuje dane klientów lub płatności albo skan wykrył backdoora, warto zapłacić komuś za ustalenie, do czego uzyskano dostęp; w wielu krajach od tej odpowiedzi zależą obowiązki wynikające z przepisów o ochronie danych.
  3. Rozwiązanie ostateczne, które zawsze działa: przywróć kopię zapasową sprzed okna narażenia albo zainstaluj CMS i wtyczki od nowa z oficjalnych źródeł, zachowując wyłącznie swoje treści. Następnie zaktualizuj i zmień wszystko, o czym mowa powyżej.

Jeśli nie masz pewności, na co patrzysz, możesz też po prostu odpowiedzieć na wiadomość e-mail z powiadomieniem. Czytam każdą odpowiedź, a wskazanie komuś właściwego kierunku jest częścią powodu, dla którego w ogóle wysyłam te powiadomienia. Nie sprzedaję usługi czyszczenia stron i ta strona nie jest ofertą handlową; zobacz zasady ujawniania.

Jeśli zaktualizowałeś jeszcze zanim dotarła moja wiadomość

Obowiązuje ta sama logika: powiadomienie oznacza, że Twoja strona niedawno zgłaszała wersję, której dotyczy problem, więc okno narażenia istniało, nawet jeśli teraz jest już zamknięte. Kroki od 2 do 4 nadal odpowiadają na pytanie, które ma znaczenie.