Stos, który audytowaliśmy
Strona małej firmy trafiła na audyt bezpieczeństwa, a znaleziska były tego zwyczajnego rodzaju, który po cichu stawia stronę o jeden automatyczny skan od kompromitacji. Page builder, Elementor, był przypięty na wersji 3.11.1, niosąc cztery krytyczne CVE, w tym SQL injection i stored cross-site scripting. Contact Form 7 działał na 5.8, narażony na CVE-2023-6449, arbitralny upload pliku. Nic egzotycznego, po prostu nieaktualne wtyczki, czyli dominujący sposób, w jaki strony WordPress padają.
Niewygodne jest to, jak bardzo to normalne. Strona działała. Wyglądała dobrze. Właściciel nie miał powodu niczego podejrzewać, bo nieaktualne wtyczki nie dają objawów, dopóki nie zostaną wykorzystane. Audyt istniał po to, by znaleźć lukę, zanim zrobi to ktoś inny.
Nieaktualne wtyczki to powierzchnia ataku
Wtyczka jest bezpieczna, dopóki jest łatana. W chwili, gdy podatność zostaje opublikowana jako CVE, a Ty nie zaktualizowałeś, exploit jest wiedzą publiczną, a Twoja zainstalowana wersja staje się nazwanym celem dla automatycznych skanerów. Ataki na WordPress są w przeważającej mierze ślepe i automatyczne, boty omiatają sieć w poszukiwaniu znanych-podatnych wersji popularnych wtyczek, więc używanie starego Elementora czy Contact Form 7 nie jest ryzykiem abstrakcyjnym. Jest reklamowane.
Na tej stronie:
- Elementor 3.11.1 niósł cztery krytyczne CVE (m.in. SQL injection i stored cross-site scripting), podczas gdy łatana linia przesunęła się już do 3.17.3. Każde z tych czterech było aktywne.
- Contact Form 7 5.8 był narażony na CVE-2023-6449, lukę drag-and-drop upload pliku, która pozwalała uwierzytelnionemu użytkownikowi z prawami redaktora wgrać dowolne pliki, bezpośrednia droga do zdalnego wykonania kodu.
Żadna z wtyczek nie była nietypowa. Obie są na ogromnym odsetku stron WordPress. Właśnie dlatego ich znane podatności są warte czasu skanera.
Co sprawdza audyt
Audyt bezpieczeństwa jest metodyczny, nie sprytny. Jego rdzeń:
- Inwentaryzacja każdej zainstalowanej wtyczki i motywu oraz zestawienie każdej wersji z jej znanymi CVE i minimalną bezpieczną wersją. To ujawniło ekspozycję Elementora i Contact Form 7 tutaj.
- Test kodu własnego i motywu pod kątem podstaw bezpieczeństwa WordPress, weryfikacji nonce i uprawnień przy akcjach, sanityzacji danych przed bazą, escapowania wyjścia przed stroną i endpointów wymagających autoryzacji.
- Sprawdzenie ekspozycji na poziomie serwera, otwarty
xmlrpc.php, błędy PHP na produkcji ujawniające ścieżki, brak nagłówków bezpieczeństwa. - Przegląd polityki aktualizacji i kopii zapasowych, bo nieutrzymywana strona wraca do tego stanu w ciągu miesięcy.
Zestawienie wersji to nieefektowna część, która łapie najwięcej, bo najczęstsza podatność WordPressa to nie sprytny zero-day. To popularna wtyczka trzy wersje za łatką.
Gdzie wdrożenia wspomagane AI to pogłębiają
Ten audyt dotyczył nieaktualnych wtyczek firm trzecich, wzorzec zaniedbania. Wdrożenia wspomagane AI dokładają drugą warstwę. Instalują wtyczki szybko, często bez ustawienia jakiejkolwiek rutyny aktualizacji, więc wersje zostają w tyle za łatkami jeszcze szybciej. A kod generowany przez AI często powstaje bez weryfikacji nonce, uprawnień i sanityzacji, których oczekuje WordPress, więc dziedziczysz naraz problem nieaktualnych wtyczek i problem generowanego kodu. Dlatego taki audyt jest częścią naszej szerszej naprawy stron zrobionych przez AI, a samodzielny audyt bezpieczeństwa WordPress zaczyna się od nudnego zestawienia wersji, zanim zajmie się czymkolwiek innym.
Jak wygląda naprawa
Kolejność naprawy jest wg ryzyka, nie wygody:
- Załatać lub usunąć wtyczki z aktywnymi CVE natychmiast, zaczynając od ścieżek upload pliku i injection, bo to najwyższa waga.
- Usunąć wtyczki porzucone lub już niepotrzebne, trwale zmniejszając powierzchnię.
- Zamknąć ekspozycję na poziomie serwera (
xmlrpc.php, wyświetlanie błędów na produkcji, brakujące nagłówki). - Wdrożyć realną rutynę aktualizacji i kopii zapasowych, by strona nie wróciła do czterech-aktywnych-CVE w ciągu roku.
Słownik
- CVE - identyfikator Common Vulnerabilities and Exposures, publiczny wpis katalogowy konkretnej znanej podatności.
- SQL injection - atak przemycający polecenia bazy danych przez niesanityzowane dane.
- Stored cross-site scripting - złośliwy skrypt zapisany na stronie i serwowany innym użytkownikom.
- Weryfikacja nonce / uprawnień - mechanizmy WordPressa potwierdzające, że żądanie jest zamierzone, a użytkownik ma do niego prawo.
Wniosek
Strona WordPress nie musi być interesująca, żeby zostać zaatakowana. Musi działać na znanej-podatnej wersji popularnej wtyczki, co opisuje dużą część stron, których nie zaudytowano. Dobra wiadomość jest taka, że dominujące ryzyko jest też najnudniejsze do naprawy: zestaw wersję każdej wtyczki z jej CVE, załataj lub usuń winowajców i wdroż rutynę utrzymania, by luka się nie otworzyła. Strona z tego audytu była o jeden skan od kłopotów i o tym nie wiedziała. Większość stron w tej sytuacji nie wie.
