Audyt WordPressa? Zacznij od wtyczek

Podsumowanie

Większość audytów bezpieczeństwa WordPressa jest odwrócona: kładą nacisk na aktualizacje rdzenia i raporty skanerów, podczas gdy luki, które naprawdę bolą, żyją we wtyczkach. Biała księga SANS wykazała, że ponad 96% luk w ekosystemie pochodzi z wtyczek stron trzecich, a około 43% nie wymaga uwierzytelnienia. Ten artykuł przeprowadzi Cię przez audyt skoncentrowany na wtyczkach dla małego wewnętrznego zespołu marketingowego, korzystając z historii witryny, która została zhakowana, ponieważ wszyscy skanowali niewłaściwą warstwę. Nauczysz się inwentaryzować i klasyfikować każdą wtyczkę, testować nieuwierzytelnione powierzchnie ataku, ręcznie przeglądać użytkowników i logi oraz przekładać wnioski na język ryzyka zrozumiały dla nietechnicznego szefa. Efektem jest kwartalny rytuał triażu zamiast ćwiczenia odhaczającego pola.

Większość audytów bezpieczeństwa WordPressa to teatr. Spędzasz popołudnie na aktualizacji rdzenia, zmianie hasła administratora i uruchamianiu skanera wtyczek, który z dumą raportuje „Brak krytycznych problemów”. Tymczasem wtyczka, która przyjmowała pliki i była ostatnio aktualizowana trzy lata temu, siedzi cicho w katalogu uploads, czekając na kogoś, kogo nie ma na liście gości.

Liczby to potwierdzają. Biała księga SANS na temat skanowania wtyczek WordPressa wykazała, że ponad 96% luk w ekosystemie WordPressa pochodzi z wtyczek stron trzecich, przy czym motywy stanowią 4%, a rdzeń poniżej 1%. Około 43% tych wad można wykorzystać bez żadnego uwierzytelnienia. Więc gdy Twój audyt poświęca większość energii rdzeniowi, badasz drzewa, podczas gdy pożar lasu zaczyna się w katalogu wtyczek obok.

To nie jest wezwanie do paniki wokół rdzenia. Luki w rdzeniu, takie jak wp2shell RCE, które niedawno doczekały się publicznych exploitów, powinny być łatane w dniu ogłoszenia. Są jednak na tyle rzadkie, że nie zasługują na większość godzin audytu. Większość należy do wtyczek i to tam zaczyna się prawdziwy przepływ pracy.

Wyobraź sobie scenariusz przed: niedzielny poranek, Twoja witryna przekierowuje na stronę kasyna, a szef pisze e-mail: „Myślałem, że mamy zabezpieczenia”. Miałeś zabezpieczenia — miałeś audyt z odhaczaniem pól. Scenariusz po to system triażu, który traktuje wtyczki jako powierzchnię ataku, którą faktycznie są, testuje je z zewnątrz i sprawdza rzeczy, których skanery nie widzą.

Jesteś w małym zespole marketingowym z witryną WordPress działającą od 2017 roku. Ma niestandardową wtyczkę do rejestracji wydarzeń, którą freelancer zbudował w 2019 roku, wtyczkę formularza kontaktowego z polem przesyłania plików oraz wtyczkę suwaka, która została sprzedana i nie ma już publicznej strony aktualizacji. To nie jest niezwykły stos. To tutaj zaczyna się Twój audyt.

---

Inwentaryzacja wtyczek to Twoja polityka bezpieczeństwa

Sporządź inwentaryzację każdej wtyczki i motywu. Zapisz wersję, datę ostatniej aktualizacji, czy dostawca nadal istnieje i czy ktokolwiek faktycznie z niej korzysta. Następnie zaklasyfikuj każdą do kategorii: utrzymywana i używana, utrzymywana i nieużywana, porzucona ale używana, porzucona i nieużywana. Usuń nieużywane natychmiast. Zignoruj argument „to tylko 50 $ miesięcznie” — nieużywana wtyczka to zobowiązanie, a nie funkcja. W przypadku porzuconych, ale używanych, zdecyduj: wymień ją albo zaakceptuj ryzyko i zapisz je w rejestrze ryzyka, który widział Twój szef.

Wtyczka do rejestracji wydarzeń wpada do kategorii porzucona, ale używana. Przyjmuje płatności i wysyła e-maile z potwierdzeniem, a jej wymiana to projekt, więc na razie ją zostawiasz. Ale piszesz notatkę: „to najbardziej prawdopodobne źródło przyszłego naruszenia” i dodajesz ją na górę listy testów.

Powierzchnia ataku	Udział w znanych lukach WordPressa	Priorytet audytu
Wtyczki stron trzecich	Ponad 96%	Najwyższy — inwentaryzuj, skanuj, testuj, wymieniaj
Motywy	Około 4%	Średni — tylko jeśli niestandardowe lub nieaktualne
Rdzeń WordPressa	Poniżej 1%	Niski — utrzymuj poprawki, idź dalej

Gdy SecurityWeek naliczył ponad 8 000 nowych luk w WordPressie w 2024 roku, zdecydowana większość była tego typu: problemy z wtyczkami, a nie łatki rdzenia. Skaner powie Ci o tych, które zostały ujawnione i otrzymały CVE. Nie powie Ci o niestandardowym kodzie freelancera bez CVE, ponieważ nikt nigdy dokładnie go nie sprawdził. To ręczne spojrzenie to Twoje zadanie. Aby uzyskać bardziej szczegółowy opis kontroli specyficznych dla wtyczek, zobacz ten przewodnik na temat audytu wtyczek WordPressa pod kątem luk.

---

Przetestuj to jak obcy: 43%, które nie potrzebuje hasła

Twój skaner już powiedział Ci, że wszystko jest w porządku. Teraz zrób to, czego on nie potrafi: zbadaj witrynę z zewnątrz, bez logowania. Zacznij od każdego pola przesyłania plików, każdego formularza przetwarzającego POST, każdego punktu końcowego admin-ajax. Czy upload faktycznie sprawdza zawartość pliku, czy tylko rozszerzenie? Gdzie trafiają przesłane pliki i czy serwer WWW może wykonywać PHP w tym katalogu? 43% wad wtyczek niewymagających uwierzytelnienia zwykle znajduje się dokładnie w tych miejscach: nieuwierzytelniony przechowywany XSS, dowolne przesyłanie plików i iniekcja obiektów PHP.

Wtyczka formularza kontaktowego pozwala odwiedzającym dołączyć CV. Zmienia nazwę pliku na oryginalną nazwę odwiedzającego, więc przesyłasz „resume.php”, a ona zapisuje go w folderze /uploads/contact/, który jest zapisywalny z założenia. Jeśli serwer pozwala również na uruchamianie PHP w tym katalogu, atakujący właśnie otrzymał webshella. Fastly udokumentowało aktywne wykorzystywanie nieuwierzytelnionego przechowywanego XSS we wtyczkach WordPressa — to nie jest niszowe ryzyko ze slajdów. Twój test jest prosty: utwórz plik o znanej zawartości, prześlij go i sprawdź, czy wraca z oryginalną nazwą i typem. Następnie spróbuj przesłać plik .php. Jeśli wróci jako .php, właśnie znalazłeś lukę do wykorzystania.

Tutaj również argument „ale nasza wtyczka zabezpieczająca ma WAF” się załamuje. WAF może zablokować znany ładunek, ale reguły normalizacji ścieżek, na których polega, często odbiegają od tego, co faktycznie robi serwer. Przewodnik OWASP Web Security Testing Guide jest lepszym odniesieniem niż jakikolwiek dashboard: opisuje, jak metodycznie testować wady przesyłania plików i przechowywany XSS. A jeśli odkryjesz, że wtyczka jest porzucona, czas zastosować protokół czyszczenia: ukryte niebezpieczeństwo porzuconych wtyczek WordPressa wyjaśnia, dlaczego pozostawienie martwego rozszerzenia jest gorsze niż jego usunięcie i dostosowanie przepływu pracy.

---

Czego skaner nie widzi: użytkownicy, logi i stary kod

Testy dynamiczne wychwytują to, co jest obecnie narażone. Ręczny przegląd wychwytuje to, co już jest w środku. Zacznij od kont użytkowników: otwórz listę administratorów i poszukaj kont, których nie utworzyłeś. Administrator o nazwie „support” z adresem na darmowym mailu i bez człowieka za nim to backdoor, a nie współpracownik. Sprawdź znaczniki czasowe plików w wp-content/uploads pod kątem czegokolwiek niedawno zmodyfikowanego, co nie jest Twoją treścią. Sprawdź log dostępu serwera pod kątem żądań wyglądających na polecenie curl bota, a nie przeglądarkę człowieka.

Wtyczka wydarzeń ma upload „zdjęcie mówcy”, który zapisuje do uploads/event-headshots/. Podczas testu znajdujesz plik, który nie jest Twój — mały plik PHP z losowo wyglądającą nazwą. To Twój webshell. Dostał się tam przez tę samą lukę w uploadzie, którą testowałeś dwa tygodnie temu, a skaner nadal by go „nie zobaczył”, ponieważ to nie jest luka wtyczki; to dowód na nią. Ręczny przegląd znajduje go, usuwa i sprawdza log pod kątem adresu IP, który go tam umieścił. Invicti zauważył, że iniekcja obiektów PHP we wtyczkach rośnie i jest prawie niewidoczna dla skanów czarnoskrzynkowych, ponieważ złośliwy obiekt materializuje się dopiero podczas wykonania. Jedynym sposobem na jego wykrycie jest czytanie kodu pod kątem niebezpiecznych wzorców, takich jak wywoływanie unserialize() na danych wejściowych od użytkownika. Przeczytanie kilkuset linii niestandardowej wtyczki jest tańsze niż płacenie retaineru za reagowanie na incydenty.

Tutaj również standardowa rada, aby „po prostu zainstalować więcej wtyczek zabezpieczających”, osiąga swój limit. Ułożenie trzech wtyczek zabezpieczających daje nakładające się reguły WAF, które blokują się nawzajem, potok zduplikowanych e-maili z logami i sporadyczny błąd „jesteś zbanowany” przy własnym logowaniu do panelu administratora. Jedna aktywna wtyczka zabezpieczająca, dobrze skonfigurowana, wystarczy. Przeczytaj o dlaczego zbyt wiele wtyczek zabezpieczających przynosi odwrotny skutek, zanim dodasz cokolwiek innego do sterty.

---

Mówienie szefowi prawdy bez wywoływania paniki

Twój szef nie dba o wyniki CVSS ani iniekcję obiektów PHP. Dba o to, czy witryna nie padnie, sklep nie przyjmuje zamówień i budżet IT. Tłumaczenie jest proste: „Ta wtyczka ma znaną nieuwierzytelnioną lukę zdalnego wykonania kodu. Osoba postronna może usunąć treść naszej witryny lub zainstalować backdoor. Musimy ją wymienić w tym kwartale”. Następnie pokaż listę priorytetów: wymień wtyczkę wydarzeń, wyłącz przesyłanie plików w formularzu kontaktowym, dopóki nie będzie poprawnie sprawdzać typów plików, zrotuj wszystkie dane logowania administratora i zaplanuj kolejny przegląd kwartalny.

Masz też przewagę językową: CISA prowadzi katalog Known Exploited Vulnerabilities, który dokładnie mówi Ci, które opublikowane luki są aktywnie wykorzystywane w terenie. Jeśli któraś z Twoich wtyczek się tam pojawi, argument nie jest już teoretyczny — istnieje znany exploit i liczysz się z czasem. Jeśli nie, użyj go mimo to jako standardu określającego, co oznacza „pilne”. Śledzenie CISA ułatwia przekonanie nietechnicznego szefa, że to nie jest e-mail phishingowy; to publiczna baza danych o tym, co atakujący robią teraz. Gdy kwartał się kończy, masz przepływ pracy dotyczący napraw, a nie jednorazowe ćwiczenie z odhaczaniem pól. Przepływ pracy zamieniający luki w cykl łatek podtrzymuje nawyk.

Przed to zepsuta witryna, rozpaczliwy e-mail i czysty raport skanera, który mówił, że wszystko jest w porządku. Po to kwartalny rytuał: inwentaryzacja, klasyfikacja, testowanie z zewnątrz, przegląd użytkowników i logów oraz zapisywanie podjętych decyzji i zaakceptowanych ryzyk. Skaner staje się mapą wskazującą, gdzie szukać, a nie świadectwem zdrowia. Wtyczki stają się listą, którą znasz z nazwy. A gdy następnym razem szef zapyta o audyt, będziesz mieć odpowiedź, która nie wymaga trzymania kciuków.