Luka oznaczona identyfikatorem CVE-2019-25745 otrzymała ocenę 8.2 w 10-stopniowej skali CVSS (Common Vulnerability Scoring System — system oceny powagi luki). 1 Dotyczy ona wtyczki Google Review Slider do systemu WordPress w wersji 6.1. Podatność umożliwia nieautoryzowanym atakującym zdalne wykonanie zapytań do bazy danych strony internetowej. Jest to możliwe poprzez manipulację parametrem przekazywanym w adresie URL.

WordPress jest najpopularniejszym systemem zarządzania treścią na świecie, napędzając również znaczną część polskiego internetu. Wiele małych i średnich firm w Polsce opiera swoje witryny właśnie na tej platformie, często korzystając z dziesiątek wtyczek w celu rozszerzenia funkcjonalności. Stare, nieaktualizowane wtyczki stanowią jeden z głównych wektorów ataku na te serwisy. Chociaż podatność pochodzi z 2019 roku, niezałatane instancje wciąż mogą być celem zautomatyzowanych skanerów poszukujących łatwych celów.

TL;DR

  • Produkt: Wtyczka WordPress Google Review Slider, wersja 6.1. 1
  • Podatność: CVE-2019-25745, Time-Based Blind SQL Injection. 1
  • Wektor: Nieautoryzowany atakujący może wysłać spreparowane żądanie GET do interfejsu administratora, wykorzystując parametr tid. 2
  • Skutek: Możliwość ekstrakcji wrażliwych informacji z bazy danych, takich jak dane użytkowników, hashe haseł czy dane konfiguracyjne. 3
  • Zagrożeni: Właściciele stron na WordPressie używający podatnej wersji wtyczki, szczególnie w polskim sektorze MŚP, gdzie audyty bezpieczeństwa wtyczek są rzadkością.
  • Pierwszy krok: Natychmiastowa weryfikacja wersji wtyczki Google Review Slider i jej aktualizacja do najnowszej dostępnej wersji lub całkowite usunięcie, jeśli nie jest aktywnie używana.

Wektor ataku

Podatność należy do kategorii Time-Based Blind SQL Injection. Jest to technika, w której atakujący nie otrzymuje bezpośredniej odpowiedzi z bazy danych w treści odpowiedzi HTTP. Zamiast tego, wnioskuje o danych na podstawie czasu, jaki zajmuje serwerowi przetworzenie zapytania.

Atakujący wstrzykuje do zapytania SQL fragmenty, które powodują warunkowe opóźnienie. Przykładowo, może skonstruować zapytanie o treści: „jeśli pierwszy znak hasła administratora to ‘a’, poczekaj 5 sekund przed odpowiedzią”. Obserwując czas odpowiedzi serwera, atakujący jest w stanie, znak po znaku, odtworzyć dowolne dane z bazy.

W przypadku wtyczki Google Review Slider, wektorem jest parametr tid w żądaniu GET wysyłanym do panelu administracyjnego. 2 Atakujący nie potrzebuje uwierzytelnienia, aby wysłać takie żądanie. 3 Może ono wyglądać następująco (przykład poglądowy):

https://przykladowa-polska-strona.pl/wp-admin/admin-ajax.php?action=grs_get_reviews&tid=1' AND (SELECT 1 FROM (SELECT(SLEEP(5)))a) AND '1'='1

Jeśli strona odpowie z 5-sekundowym opóźnieniem, atakujący wie, że wstrzyknięty kod SQL został wykonany. Następnie może zautomatyzować proces odpytywania o kolejne znaki haseł, nazw użytkowników czy kluczy API zapisanych w bazie danych WordPressa. Proces ten jest powolny, ale w pełni zautomatyzowany i skuteczny przeciwko niezałatanej infrastrukturze.

Telemetria wskazuje, że tego typu ataki są często częścią masowych kampanii skanujących, gdzie boty szukają podatnych stron na masową skalę. Dla polskiej firmy, która nie monitoruje aktywnie logów serwera, taki powolny wyciek danych może pozostać niezauważony przez wiele miesięcy.

Wskaźniki kompromitacji

Brak jest specyficznych wskaźników kompromitacji (IoC — Indicators of Compromise), takich jak adresy IP serwerów C2 (Command and Control — serwer kontrolujący zainfekowane maszyny) czy hashe plików. Obrona powinna skupić się na analizie logów serwera WWW (np. Apache, Nginx) w poszukiwaniu anomalii w żądaniach GET kierowanych do plików wp-admin/admin-ajax.php lub podobnych.

Należy szukać żądań zawierających w parametrze tid słowa kluczowe typowe dla SQL, takie jak:

SELECT
UNION
SLEEP
BENCHMARK
WAITFOR
--
'
"

Przykładowa reguła grep do przeszukania logów dostępowych Apache może wyglądać tak:

# Przeszukaj logi w poszukiwaniu prób wykorzystania parametru 'tid' z poleceniem SLEEP
grep "tid=.*SLEEP" /var/log/apache2/access.log

Atakujący mogą stosować techniki zaciemniania (obfuskacji) w celu ominięcia prostych filtrów. Zalecane jest użycie Web Application Firewall (WAF), który posiada wbudowane reguły do wykrywania prób SQL Injection.

Co zrobić w 24-48h

Rekomendowane podejście zakłada natychmiastowe działania prewencyjne i weryfikacyjne. Poniższe kroki nie zastępują pełnego audytu bezpieczeństwa, ale mogą znacząco ograniczyć ryzyko.

  1. Audyt wtyczek: Zaloguj się do panelu administracyjnego WordPress (/wp-admin/) i przejdź do sekcji „Wtyczki”. Zidentyfikuj wtyczkę Google Review Slider. Jeśli jest zainstalowana, sprawdź jej wersję. Jeśli jest to wersja 6.1 lub starsza, strona jest podatna. 1

  2. Aktualizacja lub usunięcie: Najprostszą metodą ograniczenia ryzyka jest aktualizacja wtyczki do najnowszej, załatanej wersji udostępnionej przez producenta. Jeśli wtyczka nie jest już aktywnie rozwijana lub nie jest kluczowa dla działania serwisu, rekomendujemy jej całkowite wyłączenie i usunięcie. Nieaktywne wtyczki wciąż mogą stanowić wektor ataku.

  3. Analiza logów serwera: Przejrzyj logi dostępowe serwera WWW w poszukiwaniu podejrzanych żądań do admin-ajax.php z manipulowanym parametrem tid, jak opisano w sekcji o IoC. Zwróć szczególną uwagę na żądania pochodzące z nietypowych adresów IP lub wykazujące nienaturalnie długi czas odpowiedzi serwera.

  4. Wdrożenie WAF: Dla polskich firm, zwłaszcza tych przetwarzających dane klientów (sklepy e-commerce, serwisy rezerwacyjne), wdrożenie Web Application Firewall jest kluczowym elementem obrony. Rozwiązania takie jak Cloudflare (w planie darmowym) lub komercyjne WAF mogą blokować próby SQL Injection na poziomie sieci, zanim dotrą one do aplikacji.

  5. Weryfikacja integralności bazy danych: Jeśli istnieje podejrzenie, że atak się powiódł, należy przeprowadzić audyt bazy danych. Sprawdź, czy nie utworzono nowych kont administratorów, czy nie zmodyfikowano istniejących wpisów oraz czy nie doszło do wycieku danych wrażliwych. W przypadku potwierdzenia naruszenia, incydent może podlegać zgłoszeniu do Urzędu Ochrony Danych Osobowych (UODO) zgodnie z RODO (Rozporządzenie o Ochronie Danych Osobowych).

Źródła

Zobacz też

Footnotes

  1. Wtyczka WordPress Google Review Slider w wersji 6.1 zawiera lukę typu time-based blind SQL injection. — https://nvd.nist.gov/vuln/detail/CVE-2019-25745 ↩ ↩2 ↩3 ↩4

  2. Luka umożliwia nieautoryzowanym atakującym manipulowanie zapytaniami do bazy danych poprzez wstrzykiwanie kodu SQL za pomocą parametru ‘tid’. — https://nvd.nist.gov/vuln/detail/CVE-2019-25745 ↩ ↩2

  3. Atakujący mogą wysyłać żądania GET do interfejsu administratora ze złośliwymi wartościami ‘tid’, aby wyodrębnić wrażliwe informacje z bazy danych, używając technik time-based blind SQL injection. — https://nvd.nist.gov/vuln/detail/CVE-2019-25745 ↩ ↩2