Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
CVE-2024-25600 to krytyczna podatność typu unauthenticated remote code execution (RCE) w motywie WordPress Bricks Builder. Błąd pozwala na zdalne wykonanie kodu bez konieczności logowania, co w praktyce oznacza możliwość pełnego przejęcia podatnej witryny przez atakującego. Problem dotyczył wersji Bricks Builder do 1.9.6 włącznie i został usunięty w wydaniu 1.9.6.1.
Z perspektywy bezpieczeństwa to jeden z najgroźniejszych scenariuszy dla środowisk WordPress, ponieważ naruszenie nie wymaga konta użytkownika ani wcześniejszego dostępu do panelu administracyjnego.
W skrócie
Podatność wynikała z połączenia dwóch błędów: niewystarczającej kontroli uprawnień w endpointzie REST API oraz niebezpiecznego przetwarzania danych wejściowych prowadzącego do wykonania kodu PHP po stronie serwera. Atakujący mógł pozyskać poprawny nonce z publicznie dostępnej strony, a następnie użyć go do wywołania podatnej ścieżki renderowania elementów.
- Brak wymogu uwierzytelnienia
- Możliwość wykonania dowolnego kodu na serwerze
- Wysokie ryzyko masowej eksploatacji
- Publicznie dostępne materiały PoC i exploity
- Konieczność natychmiastowej aktualizacji do wersji 1.9.6.1 lub nowszej
Kontekst / historia
Luka została publicznie opisana w lutym 2024 roku i otrzymała identyfikator CVE-2024-25600. Informacje o zagrożeniu szybko trafiły do publicznych baz podatności, analiz badaczy bezpieczeństwa oraz repozytoriów zawierających demonstracje eksploatacji.
Ryzyko operacyjne wzrosło dodatkowo wraz z pojawieniem się publicznie dostępnych kodów exploitów. Tego typu materiały obniżają próg wejścia dla cyberprzestępców i sprzyjają zarówno atakom ukierunkowanym, jak i zautomatyzowanym kampaniom skanującym internet w poszukiwaniu podatnych instalacji WordPress.
Analiza techniczna
Techniczne źródło problemu sprowadzało się do błędnego modelu autoryzacji oraz niebezpiecznego wykonania kodu na podstawie kontrolowanych danych wejściowych. W podatnym przepływie aplikacja umożliwiała wywołanie funkcji renderującej elementy buildera przez endpoint REST API. Kontrola dostępu opierała się jednak wyłącznie na sprawdzeniu nonce, bez realnej weryfikacji uprawnień użytkownika.
To założenie było nieprawidłowe, ponieważ nonce w WordPress nie pełni roli mechanizmu autoryzacji. W analizowanym przypadku poprawny token mógł zostać pozyskany z publicznie renderowanej strony, co usuwało praktyczną barierę przed wykorzystaniem luki przez niezalogowanego atakującego.
Drugi element łańcucha ataku dotyczył logiki renderowania i zapytań. Dane przekazywane do określonych ścieżek przetwarzania trafiały do mechanizmu wykonującego kod PHP. Jeżeli napastnik kontrolował wejście kierowane do tej logiki, mógł doprowadzić do uruchomienia własnych poleceń lub kodu aplikacyjnego po stronie serwera.
Typowy scenariusz eksploatacji wyglądał następująco:
- Atakujący pobierał publicznie dostępną stronę i wyodrębniał nonce.
- Następnie wysyłał żądanie POST do endpointu renderującego elementy Bricks.
- W ładunku umieszczał dane prowadzące do uruchomienia podatnej ścieżki renderowania.
- Serwer wykonywał dostarczony kod, umożliwiając zdalne wykonanie poleceń.
Z technicznego punktu widzenia jest to przykład krytycznej podatności wynikającej z połączenia błędu klasy CWE-94, czyli niewłaściwej kontroli generowania lub wykonywania kodu, z błędami w autoryzacji warstwy API.
Konsekwencje / ryzyko
Skutki skutecznego wykorzystania CVE-2024-25600 mogą być bardzo poważne. Atakujący jest w stanie osadzić webshell, modyfikować pliki aplikacji, przechwytywać konfigurację WordPress, wykraść poświadczenia do bazy danych oraz utrwalić obecność w środowisku.
W praktyce przejęta witryna może zostać użyta do dalszych działań przestępczych, takich jak dystrybucja malware, phishing, spam SEO, przekierowania ruchu czy kradzież danych klientów. W środowiskach współdzielonych ryzyko może objąć również inne zasoby, zależnie od poziomu separacji kont i konfiguracji hostingu.
Szczególnie narażone są organizacje, które:
- utrzymują publicznie dostępne serwisy WordPress,
- opóźniają aktualizacje motywów i komponentów,
- nie monitorują integralności plików,
- nie stosują warstwy WAF ani mechanizmów detekcji anomalii.
Rekomendacje
Najważniejszym działaniem naprawczym jest natychmiastowa aktualizacja Bricks Builder do wersji 1.9.6.1 lub nowszej. Sama aktualizacja nie powinna jednak kończyć procesu reakcji, ponieważ w wielu przypadkach konieczna jest także weryfikacja, czy podatność nie została już wcześniej wykorzystana.
Zalecane działania operacyjne obejmują:
- zidentyfikowanie wszystkich instalacji WordPress korzystających z Bricks Builder,
- potwierdzenie wersji komponentu i pilne wdrożenie poprawki,
- analizę logów HTTP pod kątem żądań do endpointów renderujących elementy buildera,
- sprawdzenie, czy w środowisku nie pojawiły się nowe pliki PHP, webshelle lub nieautoryzowane modyfikacje,
- przegląd kont administracyjnych WordPress oraz poświadczeń do bazy danych,
- rotację haseł i kluczy w przypadku podejrzenia kompromitacji,
- uruchomienie skanu integralności plików i porównanie z kopią referencyjną,
- wdrożenie reguł WAF ograniczających podejrzane żądania do REST API.
W szerszej perspektywie obronnej warto również stosować zasadę najmniejszych uprawnień, eliminować użycie konstrukcji takich jak eval oraz nie traktować nonce jako zamiennika dla pełnej autoryzacji.
Podsumowanie
CVE-2024-25600 to jedna z najpoważniejszych podatności, jakie dotknęły ekosystem WordPress w obszarze motywów i builderów stron. Połączenie braku wymogu logowania, błędnej kontroli dostępu i możliwości wykonania kodu po stronie serwera sprawiło, że luka osiągnęła krytyczny poziom ryzyka.
Dla administratorów oznacza to konieczność nie tylko szybkiego wdrożenia poprawki, ale również przeglądu logów, kontroli integralności plików i oceny, czy środowisko nie zostało naruszone przed aktualizacją. To także ważne przypomnienie, że tokeny anty-CSRF nie zastępują autoryzacji, a mechanizmy wykonujące kod z danych wejściowych stanowią trwałe źródło wysokiego ryzyka.