Gladinet łata aktywnie wykorzystywaną lukę zero-day w CentreStack. Co wiemy i co robić? - Security Bez Tabu

Gladinet łata aktywnie wykorzystywaną lukę zero-day w CentreStack. Co wiemy i co robić?

Wprowadzenie do problemu / definicja luki

Gladinet wydał poprawkę dla CentreStack usuwając wykorzystywaną w atakach lukę CVE-2025-11371 typu Local File Inclusion (LFI). Błąd pozwalał nieautoryzowanym napastnikom odczytać plik Web.config, wyekstrahować ASP.NET machineKey, a następnie zrealizować RCE (zdalne wykonanie kodu) poprzez wcześniej opisaną podatność na deserializację ViewState (CVE-2025-30406). Łatka jest dostępna w CentreStack 16.10.10408.56683.

W skrócie

  • CVE-2025-11371 (LFI) umożliwia odczyt wrażliwych plików (m.in. Web.config) na serwerze CentreStack/Triofox w domyślnej konfiguracji.
  • Ataki obserwowane od 27 września 2025 r. (zero-day).
  • Po pozyskaniu machineKey napastnik może sfałszować ViewState i osiągnąć RCE, łańcuchowo z CVE-2025-30406.
  • Poprawka wydana 14 października 2025 r. w CentreStack 16.10.10408.56683; zalecana natychmiastowa aktualizacja.
  • W okresie bez łatki rekomendowano tymczasową dezaktywizację handlera “temp” w UploadDownloadProxy.

Kontekst / historia / powiązania

W kwietniu 2025 r. naprawiono CVE-2025-30406 (twardo zakodowany machineKey i deserializacja ViewState), która była aktywnie wykorzystywana. Nowa luka LFI (CVE-2025-11371) pozwalała „odtworzyć” warunki do RCE – tym razem poprzez pozyskanie klucza z działającej, już zaktualizowanej instancji. Zależność między CVE-2025-11371 (LFI) i CVE-2025-30406 (RCE) stanowiła kluczowy łańcuch ataku.

Analiza techniczna / szczegóły luki

  • Wektor: niezabezpieczony punkt końcowy /storage/t.dn w komponencie GSUploadDownloadProxy.dll (klasa GladinetStorage.TempDownload). Parametr s= był podatny na directory traversal, umożliwiając odczyt dowolnych plików w kontekście NT AUTHORITY\SYSTEM (np. ...\root\Web.config).
  • Łańcuch do RCE: po odczycie Web.config napastnik uzyskiwał machineKey i mógł wygenerować złośliwy ViewState, aby wykonać komendy z uprawnieniami puli aplikacyjnej IIS (efektywnie przejęcie hosta).
  • Wersje podatne: wg NVD – wszystkie wersje do i włącznie z 16.7.10368.56560 w domyślnej instalacji/konfiguracji.
  • IoC / telemetria zaobserwowana przez Huntress:
    • Żądania GET do **/storage/t.dn?s=..\..\..\Program+Files+(x86)\Gladinet+Cloud+Enterprise\root\Web.config&sid=1**
    • Następnie POST-y z base64 (payload ViewState) i logi Event ID 1316 z komendami systemowymi (ipconfig /all > ...).

Praktyczne konsekwencje / ryzyko

  • Ekspozycja klucza kryptograficznego (machineKey) umożliwia podpisywanie złośliwych danych i omijanie zabezpieczeń ViewState → pełne przejęcie serwera.
  • Atak bez uwierzytelnienia, w domyślnej konfiguracji, na systemach często wystawionych do Internetu (MSP, wdrożenia samo-hostowane).
  • Ataki w toku (co najmniej kilku poszkodowanych) i obserwacje od końca września zwiększają pilność działań.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zaktualizuj CentreStack do 16.10.10408.56683 (lub nowszej). Zweryfikuj numer buildu po instalacji.
  2. Jeśli aktualizacja chwilowo niemożliwa: wyłącz handler „temp” w UploadDownloadProxy\Web.config (usunięcie mapowania do t.dn). Uwaga: ogranicza funkcjonalność, ale zamyka wektor LFI.
  3. Hunting/Monitoring:
    • Szukaj żądań do **/storage/t.dn** z ciągami ..\..\.. i odczytem Web.config.
    • Analizuj logi aplikacyjne (np. Event ID 1316) pod kątem nietypowych payloadów base64 i komend systemowych.
  4. Twardnij konfigurację ASP.NET: rotacja machineKey po incydencie, wymuszenie minimalnych uprawnień puli aplikacyjnej, kontrola dostępu do ścieżek tymczasowych. (Wniosek na podstawie analizy łańcucha ataku).
  5. Przegląd ekspozycji: potwierdź, czy interfejsy CentreStack/Triofox są dostępne z Internetu; jeśli tak, rozważ geofencing/VPN/WAF i reguły sygnaturowe na /storage/t.dn.
  6. Triofox: produkt był wskazany jako podatny w domyślnej konfiguracji; sprawdź komunikaty producenta i dostępność aktualizacji dla Twojej wersji Triofox (w artykułach potwierdzono patch publicznie dla CentreStack).

Różnice / porównania z innymi przypadkami

  • CVE-2025-11371 vs CVE-2025-30406:
    • 11371 = LFI (odczyt plików) → pośrednio umożliwia RCE przez 30406 (ViewState).
    • 30406 = krytyczna deserializacja możliwa przy znajomości machineKey (wcześniej twardo zakodowanego); naprawiona w kwietniu 2025 r. 11371 „odblokowała” 30406 na zaktualizowanych hostach przez ujawnienie klucza.

Podsumowanie / kluczowe wnioski

  • Zaktualizuj teraz do 16.10.10408.56683 – to jedyny trwały sposób zamknięcia LFI.
  • Sprawdź logi pod kątem odczytów Web.config przez /storage/t.dn i podejrzanych payloadów base64 – to typowy ślad tej kampanii.
  • Traktuj 11371 + 30406 jako łańcuch: sama „średnia” punktacja LFI (CVSS 6.2) jest myląca – w praktyce prowadzi do pełnego RCE.

Źródła / bibliografia

  1. BleepingComputer – „Gladinet fixes actively exploited zero-day in file-sharing software” (wydanie łatki, wersja 16.10.10408.56683, wektor /storage/t.dn). (BleepingComputer)
  2. Huntress – „Active Exploitation of Gladinet CentreStack and Triofox Local File Inclusion Flaw (CVE-2025-11371)” (timeline, IoC, technikalia, mitigacje, potwierdzenie daty wydania łatki). (Huntress)
  3. SecurityWeek – „Gladinet Patches Exploited CentreStack Vulnerability” (podsumowanie łańcucha LFI → ViewState RCE, potwierdzenie wersji z poprawką). (SecurityWeek)
  4. NVD – CVE-2025-11371 (opis wpływu i zakres wersji w domyślnej konfiguracji). (NVD)
  5. Field Effect – „Gladinet patches critical vulnerability exploited in the wild” (daty: obserwacje, publikacja mitigacji i wydanie poprawki). (fieldeffect.com)