Actualización n.º 1: 15/10/25 a la 1:00 p. m. hora del Este
El 14 de octubre, Gladinet lanzó la versión 16.10.10408.56683 de CentreStack, que incluye una corrección para la vulnerabilidad de inclusión de archivos locales que se describe a continuación. Huntress recomienda que las organizaciones afectadas actualicen al número de compilación más reciente lo antes posible.
Ahora que se publicó un parche, también compartimos un análisis más detallado de la vulnerabilidad y de la actividad de explotación, como se describe a continuación. Lo siguiente también incluye partes del blog original, publicado el 9/10/25.
----------------------------------------------------------------------
Resumen: Huntress descubrió explotación activa de una falla de inclusión de archivos locales no autenticada (CVE-2025-11371) en los productos Gladinet CentreStack y Triofox. Al momento de la redacción inicial de este blog, no había un parche disponible en las versiones más recientes de CentreStack y Triofox.
Antecedentes
En abril de 2025, Huntress publicó sus hallazgos sobre la explotación de CVE-2025-30406, una falla de gravedad crítica en los productos Gladinet CentreStack y Triofox.
El 27 de septiembre de 2025, el Huntress SOC recibió una alerta de un detector interno por la explotación exitosa del software Gladinet CentreStack. Sin embargo, la versión del software en ejecución era posterior a 16.4.10315.56368, que ya no era vulnerable a CVE-2025-30406. En versiones anteriores de CentreStack y Triofox vulnerables a CVE-2025-30406, una clave de máquina codificada de forma fija permitía que un actor de amenazas realizara ejecución remota de código mediante una vulnerabilidad de deserialización de ViewState.
Tras un análisis posterior, Huntress descubrió la explotación de una vulnerabilidad de inclusión de archivos locales no autenticada (CVE-2025-11371) que permitía a un actor de amenazas obtener la clave de máquina del archivo Web.config de la aplicación para realizar ejecución remota de código mediante la vulnerabilidad de deserialización de ViewState mencionada.
Durante nuestra investigación, vimos evidencia de que Gladinet se había puesto en contacto con un cliente en común para implementar una mitigación. Poco después de este descubrimiento, Huntress se comunicó con Gladinet para divulgar la falla, según nuestra política estándar de divulgación de vulnerabilidades; Gladinet confirmó que ya tenía conocimiento de la vulnerabilidad y que estaba en proceso de notificar a los clientes sobre una solución alternativa inmediata.
Huntress también notificó a sus propios clientes afectados sobre la solución alternativa. Hasta el momento, hemos observado explotación activa de esta vulnerabilidad que afectó a tres clientes. Al momento de la redacción inicial de este blog, no había un parche disponible en las versiones más recientes de CentreStack y Triofox.
Observaciones de Huntress
El 26/09/2025 a las 20:48:37 UTC, el Huntress SOC respondió a un detector interno diseñado para detectar actividad posterior a la explotación de CVE-2025-30406. En cuanto se confirmó la amenaza, el analista contuvo el endpoint, lo que impidió que continuara la actividad maliciosa. La detección se basó en un payload en base64 irregular que se ejecutaba como proceso hijo de el servidor web.
Figura 1: Cronología de detección de la actividad de explotación observada
Esto dio pie a una investigación sobre la comunicación externa con el endpoint. A partir de los registros del servidor web, pudimos determinar que el atacante accedió al sitio web mediante un referente de hxxps[://]en[.]fofa[.]info/.
FOFA es un motor de búsqueda de mapeo de internet que ofrece datos sobre activos de redes expuestos públicamente.
El atacante luego envió una solicitud GET a la página de inicio de sesión /portal/loginpage.aspx, que devolvió un código 200, como cabría esperar en una navegación normal.
Figura 2: Solicitudes GET referidas por FOFA, como se muestra en los registros del servidor web
El atacante luego hizo una solicitud post al servidor. Así es como un usuario legítimo enviaría sus credenciales al servidor. Esto generaría un código de respuesta 200, que indica que la página se actualizó (contraseña o usuario incorrectos), o un código 302, que indica que el usuario, ya autenticado, fue redirigido a otra página.
Figura 3: Solicitud POST, como se muestra en los registros
Aquí es donde se pone interesante. El atacante luego hizo una solicitud GET inusual:
GET /storage/t.dn s=..\..\..\Program+Files+(x86)\Gladinet+Cloud+Enterprise\root\Web.config&sid=1
El servidor respondió entregando una copia de web.config. Esto se confirmó con el código 200 y 1497 bytes de datos, que es el tamaño aproximado de web.config descontando el sobrecosto esperado.
¿Qué pasó? Bueno, las solicitudes a /storage/t.dn son manejadas por la función GladinetStorage.TempDownload de GSUploadDownloadProxy.dll. Esta función está diseñada para recuperar archivos del directorio temporal para usuarios autenticados.
Esto, lamentablemente, es vulnerable a una vulnerabilidad de inclusión de archivos locales y queda expuesto externamente.
Figura 4: Solicitud GET que muestra la explotación
Ahora que el atacante tenía una copia del archivo Web.config que contenía la machine key, pudo realizar un ataque de deserialización y comenzar a reconocer el endpoint. Esto se logró mediante dos conjuntos de payloads codificados en base64 que contenían el comando ipconfig /all, los cuales fueron capturados por los registros de la aplicación en Event ID 1316. Como los comandos se ejecutaron a ciegas, la salida del comando se dirigió a un documento de texto y luego se recuperó mediante la vulnerabilidad de inclusión de archivos locales.
Base64 decodificado: ipconfig /all > "C:\programdata\CentreStac_log.txt"
GET /storage/t.dn s=..\..\..\programdata\CentreStac_log.txt&sid=1
Figura 5: Más evidencia de explotación en los registros del servidor web
El atacante no pudo abusar más de esto porque el endpoint fue contenido rápidamente.
Figura 6: Event ID 1316 mostrando el ataque de deserialización de ViewState
Figura 7: Payload codificado en base64 contenido dentro de las solicitudes post
Análisis de la vulnerabilidad
El equipo de Huntress Hunt and Response investigó el endpoint con la vulnerabilidad de inclusión de archivos locales y encontró el código vulnerable dentro de la clase GladinetStorage.TempDownload ubicada en C:\Program Files (x86)\Gladinet Cloud Enterprise\UploadDownloadProxy\bin\GSUploadDownloadProxy.dll.
Figura 8: Una vista de la función ProcessRequest() dentro de la clase TempDownload en GSUploadDownloadProxy.dll
En lo anterior, TempRoot se define mediante la función GladPDF.GetTempRoot(). Esta función recupera una ruta temporal e intenta asegurar que la carpeta glad_temp esté presente.
Figura 9: Código de la función GetTempRoot()
Debido a que Gladinet Cloud Enterprise se ejecuta como la cuenta de usuario NT AUTHORITY\SYSTEM, el directorio temporal del usuario generalmente estará presente en C:\Windows\Temp. Esto significa que al incluir caracteres de recorrido de directorio ..\ se permitirá que la aplicación recupere cualquier archivo relativo a C:\Windows\Temp\glad_temp. Por ejemplo, recuperar el archivo ..\..\explorer.exe recuperaría el archivo desde C:\Windows\explorer.exe.
Prueba de concepto
Aunque Huntress sigue inclinándose a no publicar el código de prueba de concepto para explotar el CVE-2025-30406 original, a continuación se muestra una solicitud de PowerShell de una línea para recuperar el archivo Web.config utilizando el endpoint no autenticado mencionado anteriormente.
Invoke-WebRequest "http://<IP_ADDRESS_OR_URL>/storage/t.dn?s=..\..\..\Program+Files+(x86)\Gladinet+Cloud+Enterprise\root\Web.config&sid=1"|Select-Object -exp RawContent
Guía de mitigación / ¿Qué debo hacer?
Recomendamos deshabilitar el controlador temp dentro del archivo Web.config para UploadDownloadProxy ubicado en:
C:\Program Files (x86)\Gladinet Cloud Enterprise\UploadDownloadProxy\Web.config
Esto afectará algunas funcionalidades de la plataforma; sin embargo, garantizará que esta vulnerabilidad no se pueda explotar hasta que se aplique el parche.
Figura 10: Una imagen del controlador temp apuntando a t.dn, el cual puede deshabilitarse como mitigación
Eliminar la línea resaltada anteriormente mitigará la vulnerabilidad.
IOC
|
Elemento |
Descripción |
|
GET /storage/t.dn s=..\..\..\Program+Files+(x86)\Gladinet+Cloud+Enterprise\root\Web.config&sid=1 |
Solicitud GET para recuperar el archivo Web.config |
