Co zrobić w dniu, w którym opublikowano lukę we wtyczce WordPress

Niemal każdego dnia publikowana jest nowa luka w jakiejś wtyczce WordPress. Większość nie wymaga niczego poza kolejną rutynową aktualizacją. Kilka wymaga działania dziś: te, które są aktywnie wykorzystywane, nie wymagają logowania albo dotyczą wtyczki działającej na dziesiątkach stron klientów. Ten poradnik to procedura na taki dzień: jak szybko ocenić, czy luka cię dotyczy, jak znaleźć każdą dotkniętą stronę i co zrobić po aktualizacji.

Krok 1: w pięć minut zdecyduj, czy to pilne

Przeczytaj sam komunikat (Patchstack, Wordfence lub WPScan), nie tylko nagłówek. Cztery pytania decydują, jak szybko działasz:

• Czy luka jest wykorzystywana? Komunikat mówiący o zaobserwowanych atakach trafia na sam szczyt twojego dnia.
• Czy wymaga logowania? Luka, którą może wykorzystać anonimowy odwiedzający, jest dużo groźniejsza niż taka, która wymaga konta administratora.
• Co może zrobić atakujący? Wgrywanie plików, wykonywanie kodu czy tworzenie kont administratora jest gorsze niż odbity XSS wymagający kliknięcia.
• Na ilu twoich stronach działa ta wtyczka? Jedna strona to zadanie; czterdzieści stron to projekt z terminem.

Jeśli odpowiedź na dwa pierwsze pytania brzmi tak, traktuj to jako pilne: dotknięte strony dziś, a nie przy następnej rundzie utrzymania.

Krok 2: znajdź każdą dotkniętą stronę

Dla każdej strony potrzebujesz dwóch informacji: czy wtyczka jest zainstalowana (aktywna lub nie) i w jakiej wersji. Nieaktywne wtyczki też się liczą. Podatny kod nadal jest na serwerze i często da się do niego dotrzeć bezpośrednio.

Z WP-CLI zajmuje to kilka sekund na stronę:

wp plugin list --name=ninja-forms --fields=name,status,version

Bez WP-CLI sprawdź Wtyczki w wp-admin albo wersję w pliku readme.txt wtyczki. Zapisz wynik na jednej liście: strona, zainstalowana tak lub nie, wersja, wersja z poprawką. Ta lista to twoja checklista na resztę dnia, a potem dowód dla klienta.

Krok 3: zaktualizuj dotknięte strony, najpierw najbardziej narażone

Zacznij od stron, na których atak zaszkodziłby najbardziej: sklepów internetowych, stron z wieloma formularzami lub kontami użytkowników oraz stron z dużym ruchem. Przed każdą aktualizacją upewnij się, że istnieje świeża kopia zapasowa, którą naprawdę możesz przywrócić.

Aktualizacje bezpieczeństwa są zwykle małe, ale nie zawsze. Niektórzy producenci dostarczają poprawkę w większym wydaniu z innymi zmianami. Jeśli wersja z poprawką to duży skok albo wtyczka obsługuje formularze lub kasę, przetestuj ją najpierw na kopii strony, gdy to możliwe, a potem sprawdź kluczowe podstrony.

Jeśli nie możesz dziś zaktualizować, na przykład dlatego, że poprawki jeszcze nie ma albo aktualizacja coś psuje, zmniejsz ryzyko: wyłącz wtyczkę, jeśli strona może przez dzień obejść się bez niej, albo zablokuj podatny endpoint w zaporze, jeśli komunikat go wskazuje. Powiedz klientowi, co zrobiłeś i dlaczego.

Krok 4: przetestuj to, do czego służy wtyczka

Udana aktualizacja to nie to samo co działająca strona. Po aktualizacji przetestuj to, do czego wtyczka służy. Przy wtyczce formularzy wyślij prawdziwe zgłoszenie testowe i sprawdź, czy e-mail dochodzi. Przy wtyczce sklepu złóż zamówienie testowe aż do płatności. Formularz, który po cichu przestaje wysyłać, może kosztować klienta tydzień zapytań, zanim ktoś to zauważy.

Krok 5: sprawdź, czy strona nie została już zaatakowana

Aktualizacja zamyka lukę. Nie usuwa niczego, co atakujący zostawił wcześniej. Jeśli luka była wykorzystywana przed wgraniem poprawki, sprawdź na każdej dotkniętej stronie:

• konta administratora, których nie rozpoznajesz;
• pliki PHP w folderze uploads, który powinien zawierać tylko media;
• niedawno zmienione pliki we wtyczkach i motywach, których nie aktualizowałeś;
• nieznane zaplanowane zadania lub przekierowania, których nie ustawiałeś.

Jeśli znajdziesz ślady włamania, przywróć kopię zapasową sprzed okresu ataku, od razu zaktualizuj i zmień wszystkie hasła oraz klucze bezpieczeństwa w wp-config.php. Sama poprawka nie wystarczy.

Krok 6: krótko poinformuj klienta

Klienci rzadko czytają wiadomości o bezpieczeństwie, ale zauważają, gdy ich agencja trzyma rękę na pulsie. Wystarczy krótka notka: na czym polegał problem, czy ich strona była dotknięta, co zrobiłeś i kiedy. Niewidoczna praca staje się widoczną wartością, a notka pasuje też do najbliższego raportu z utrzymania.

Następnym razem szybciej

• Prowadź listę, które wtyczki działają na których stronach, żeby krok 2 zajmował minuty.
• Śledź jedno lub dwa źródła komunikatów, nie dziesięć.
• Upewnij się, że każda strona ma kopię zapasową, którą naprawdę choć raz przywróciłeś.
• Uzgodnij z klientami z góry, że pilne aktualizacje bezpieczeństwa odbywają się poza normalnym harmonogramem.

Jak Verploy radzi sobie z lukami we wtyczkach

Verploy pokazuje znane luki we wtyczkach i motywach każdej podłączonej strony, więc od razu widzisz, które strony są dotknięte. Każda aktualizacja jest sprawdzana, a ryzykowne są najpierw testowane na kopii, łącznie z formularzami i kasą. Nocne kopie zapasowe mają test przywracania, a jeśli strona zepsuje się po publikacji, Verploy ją cofa. Więcej o monitorowaniu luk w WordPress.