Hakerzy wykorzystują błąd kryptograficzny w Gladinet CentreStack/Triofox do ataków RCE

Wprowadzenie do problemu / definicja luki

11 grudnia 2025 r. pojawiły się doniesienia o aktywnym wykorzystywaniu nowej, nieudokumentowanej wcześniej podatności kryptograficznej w produktach Gladinet CentreStack i Triofox. Błąd wynika z zastosowania stałych (hardcoded) kluczy AES w komponencie odpowiedzialnym za szyfrowanie tzw. „Access Ticketów”. Atakujący, posiadając te klucze, mogą odszyfrowywać lub fałszować bilety dostępu, pobierać plik web.config z serwera i następnie doprowadzać do zdalnego wykonania kodu (RCE) poprzez nadużycie ASP.NET ViewState. Vendor potwierdził aktualizacje i przekazał IOC oraz zalecenia, a badacze obserwują ataki na co najmniej 9 organizacji z różnych sektorów.

W skrócie

• Co się dzieje: aktywne ataki na CentreStack/Triofox z wykorzystaniem stałych kluczy AES i mechanizmu „Access Ticket”.
• Skutki: odczyt web.config → pozyskanie machineKey → ViewState deserialization → RCE.
• Skala: potwierdzone co najmniej 9 ofiar (stan na 10 grudnia 2025 r.). Adres źródłowy widoczny w telemetrii: 147.124.216[.]205.
• Wersje/patch: zalecana wersja 16.12.10420.56791 (wydana 8 grudnia 2025 r.). Bezwzględnie zrotować machineKey.
• Łańcuch z wcześniejszą luką: aktywnie wykorzystywane CVE-2025-11371 (LFI) oraz wcześniejsze CVE-2025-30406 (RCE przez ViewState).

Kontekst / historia / powiązania

Jesienią 2025 r. CISA dodała do katalogu KEV podatność CVE-2025-11371 (LFI), umożliwiającą nieautoryzowany odczyt plików – w praktyce web.config. Wcześniej opisywano także CVE-2025-30406, gdzie błędna obsługa kluczy/machineKey umożliwia RCE przez ViewState. w tej chwili obserwowany błąd kryptograficzny z hardcoded kluczami AES ułatwia ten sam łańcuch ataku i jest wykorzystywany „widzianie w boju” (in the wild).

Analiza techniczna / szczegóły luki

• Miejsce problemu: niestandardowa implementacja AES w GladCtrl64.dll; podczas startu serwisu generowane są dwie stałe 100-bajtowe sekwencje znaków (chiński i japoński tekst marketingowy), z których obliczane są klucz (32 B) i IV (16 B).
• Mechanizm błędu: handler filesvr.dn przyjmuje parametr t (Access Ticket), podmienia znaki, dekoduje Base64 i odszyfrowuje bilety stałym kluczem/IV. Ktokolwiek te wartości odczyta (np. z pamięci procesu), może tworzyć własne, ważne bilety – np. z timestampem ustawionym na rok 9999 (nigdy nie wygasną).
• Co dalej robi atakujący: tworzy bilet wskazujący na ścieżkę C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config, pobiera plik i wyciąga z niego <machineKey>. Następnie przeprowadza ViewState deserialization i osiąga RCE w kontekście aplikacji IIS.
• IOC o wysokiej wiarygodności: skrót szyfrowanego ciągu odpowiadający ścieżce web.config: vghpI7EToZUDIZDdprSubL3mTZ2 – to najlepszy wskaźnik w logach HTTP.

Praktyczne konsekwencje / ryzyko

• Przejęcie serwera aplikacyjnego (RCE) i dostęp do plików udziałów/zasobów.
• Ruch lateralny w domenie (kradzież poświadczeń, eskalacja uprawnień).
• Eksfiltracja danych z udziałów plikowych udostępnionych przez CentreStack/Triofox.
• Trwałość: bilety z timestampem „9999-…” można wielokrotnie odtwarzać.
• Sektory: potwierdzone ofiary m.in. ochrona zdrowia i technologia.

Rekomendacje operacyjne / co zrobić teraz

1. Natychmiastowa aktualizacja do 16.12.10420.56791 (build z 8 grudnia 2025 r.).
2. Rotacja machineKey we wszystkich węzłach/instancjach (to warunek konieczny – same łatki nie unieważnią zdobytych kluczy).
3. Przegląd logów (IIS, WAF, proxy) pod kątem:
   • żądań do /storage/filesvr.dn z parametrem t=,
   • wystąpień ciągu vghpI7EToZUDIZDdprSubL3mTZ2 (wysoka trafność),
   • nietypowych błędów ViewState/ObjectStateFormatter.
4. Weryfikacja kompromitacji: jeżeli machineKey mógł wyciec, zakładaj kompromitację → rotuj klucze, unieważnij sesje, przeprowadź IR (przegląd harmonogramów zadań, usług, modułów IIS, webshelli, skryptów w katalogach aplikacji).
5. Twardnienie konfiguracji:
   • wyłącz/ogranicz dostęp do filesvr.dn,
   • zastosuj WAF-owe reguły dla podejrzanych t= (Base64 + znaki :, |),
   • zmień domyślny machineKey i egzekwuj jego rotację proceduralnie (runbook).
6. Śledź KEV/CVE: monitoruj status CVE-2025-11371 (LFI) i wcześniejszej CVE-2025-30406 (RCE) – łańcuchy są ze sobą silnie powiązane operacyjnie.

Różnice / porównania z innymi przypadkami

• CVE-2025-11371 (LFI): umożliwia odczyt plików bez uwierzytelnienia (np. web.config). Sama w sobie nie daje natychmiastowego RCE, ale otwiera drzwi do pozyskania machineKey.
• Nowy błąd kryptograficzny (brak CVE na dziś): ułatwia fałszowanie Access Ticketów dzięki stałym kluczom AES — z pominięciem innych kontroli czasu/uwierzytelniania — co przyspiesza zdobycie web.config.
• CVE-2025-30406 (RCE): deserializacja ViewState z użyciem poznanego machineKey → pełne RCE w aplikacji.

Podsumowanie / najważniejsze wnioski

• Atakujący aktywnie łączą błąd kryptograficzny z wcześniejszymi słabościami CentreStack/Triofox, aby masowo uzyskiwać RCE.
• Patch + rotacja kluczy to absolutne minimum; bez rotacji machineKey środowisko pozostaje narażone na ponowne wykorzystanie.
• Najbardziej wiarygodny IOC do szybkiego huntingu w logach HTTP to: vghpI7EToZUDIZDdprSubL3mTZ2.
• Wdrożenie kontroli prewencyjnych (WAF, ograniczenie handlerów, segmentacja) znacząco utrudni powtórny kompromis.

Źródła / bibliografia

1. BleepingComputer: „Hackers exploit Gladinet CentreStack cryptographic flaw in RCE attacks” (11 grudnia 2025). (BleepingComputer)
2. Huntress: „Active Exploitation of Gladinet CentreStack/Triofox Insecure Cryptography Vulnerability” (10 grudnia 2025). (Huntress)
3. CISA KEV – wpis dot. CVE-2025-11371 (4 listopada 2025). (CISA)
4. Huntress: „CVE-2025-30406 – Critical Gladinet CentreStack & Triofox vulnerability exploited in the wild” (14 kwietnia 2025). (Huntress)
5. Gladinet Support: „Hardening the CentreStack Cluster” – sekcja o aktualizacji/rotacji machineKey. (support.centrestack.com)