La plataforma de visualización de datos china dejó abierta una ruta para que cualquier atacante remoto acceda a archivos del sistema sin credenciales hasta agosto de 2023.
DataEase, una plataforma open-source de análisis y visualización de datos desarrollada en China y adoptada por organizaciones en varios países, corrigió en agosto de 2023 una vulnerabilidad de directory traversal que permitía a atacantes remotos no autenticados acceder a información sensible del servidor. La falla, identificada como CVE-2023-40772 y catalogada con severidad media por el National Vulnerability Database de NIST, afectó a todas las versiones anteriores a la 1.18.10 y residía en el componente StaticResourceController.java, responsable de servir recursos estáticos de la aplicación.
El problema radicaba en la falta de validación de rutas en las solicitudes HTTP al controlador de recursos estáticos. Un atacante podía enviar una petición manipulada con secuencias de traversal (típicamente «../» repetidas) para navegar fuera del directorio previsto y acceder a archivos arbitrarios del sistema de archivos del servidor, siempre que el proceso de DataEase tuviera permisos de lectura sobre ellos. Este tipo de vulnerabilidad no requiere autenticación previa ni interacción del usuario — basta con que la instancia de DataEase sea accesible por red.
Por qué un controlador de recursos estáticos se convierte en vector de ataque
StaticResourceController.java es el componente de DataEase encargado de entregar archivos estáticos como imágenes, hojas de estilo o scripts al navegador del usuario. En condiciones normales, este controlador debería restringir el acceso exclusivamente a un directorio específico dentro de la aplicación. La vulnerabilidad surgió porque el código no sanitizaba adecuadamente la ruta solicitada antes de construir la ubicación del archivo en el sistema operativo.
Cuando un atacante enviaba una solicitud del tipo `GET /static/../../etc/passwd` (en sistemas Linux) o rutas equivalentes en Windows, el controlador interpretaba literalmente la secuencia de navegación hacia arriba en el árbol de directorios. Si el servidor ejecutaba DataEase con permisos elevados o si archivos de configuración de la aplicación (que suelen contener credenciales de bases de datos, tokens de API o claves de cifrado) estaban en ubicaciones predecibles, el atacante podía extraerlos sin dejar rastro en logs de autenticación, porque técnicamente no estaba violando ningún control de acceso — simplemente estaba explotando una ruta de código legítima mal implementada.
Este patrón de falla es recurrente en frameworks web que delegan el manejo de archivos estáticos a componentes genéricos sin configuración defensiva. En el caso de DataEase, al tratarse de una plataforma que centraliza datos de múltiples fuentes empresariales, los archivos de configuración expuestos podían incluir credenciales para conectarse a bases de datos corporativas, sistemas ERP o almacenes de datos en la nube.
Exposición en América Latina por adopción de plataformas open-source chinas
DataEase ha ganado tracción en sectores de tecnología y educación de América Latina, particularmente en Brasil y México, donde equipos técnicos buscan alternativas open-source a herramientas comerciales de BI como Tableau o Power BI. Aunque no existen reportes públicos de explotación de CVE-2023-40772 en instancias latinoamericanas específicas, la naturaleza de la vulnerabilidad (explotable remotamente sin autenticación) y el perfil de adopción de la plataforma en la región plantean un escenario de riesgo concreto.
Organizaciones que desplegaron DataEase antes de agosto de 2023 y no aplicaron la actualización a la versión 1.18.10 permanecen vulnerables. En contextos donde DataEase se expone a internet para permitir acceso remoto a dashboards — una configuración común en startups y equipos distribuidos — la superficie de ataque es directa. Además, la falta de logs de autenticación asociados a este tipo de explotación dificulta la detección retrospectiva: un atacante que extrajo archivos de configuración en 2023 pudo haber mantenido acceso persistente a sistemas conectados sin que la organización tenga registro del evento inicial.
El caso es representativo de un patrón más amplio en la región: la adopción acelerada de herramientas open-source de origen asiático (DataEase, Halo CMS, JumpServer) sin procesos formales de evaluación de seguridad ni monitoreo de actualizaciones de seguridad. A diferencia de proyectos con comunidades occidentales grandes (donde las vulnerabilidades suelen generar alertas amplificadas en medios especializados), las fallas en software chino de nicho tienden a pasar desapercibidas hasta que aparecen en escaneos automatizados de atacantes.
Qué no se sabe y qué sigue sin resolverse
La información pública sobre CVE-2023-40772 es limitada. No hay detalles técnicos sobre si la vulnerabilidad fue descubierta internamente por el equipo de DataEase o reportada por un investigador externo. Tampoco se conoce si existió explotación en estado salvaje antes del parche, ni si se publicó un proof-of-concept que facilitara la explotación masiva. El registro de NVD no incluye métricas CVSS v3 detalladas más allá de la severidad media, lo que deja sin cuantificar el impacto real en términos de confidencialidad, integridad o disponibilidad según el modelo estándar de evaluación.
Desde la perspectiva de respuesta a incidentes, las organizaciones que ejecutaron versiones vulnerables de DataEase enfrentan un problema de visibilidad: sin logs que registren accesos no autenticados a archivos (porque técnicamente el acceso era a través de un endpoint legítimo), determinar si hubo compromiso requiere análisis forense de accesos de red y correlación con actividad anómala posterior en sistemas conectados. Para instancias que además carecían de segmentación de red o ejecutaban DataEase con privilegios de root o administrador, la exposición potencial se extiende más allá de la propia plataforma.
Nuestro análisis
CVE-2023-40772 encaja en un patrón que hemos documentado repetidamente en plataformas de datos open-source: la priorización de funcionalidad sobre controles de seguridad básicos en componentes de infraestructura. Directory traversal es una clase de vulnerabilidad conocida desde hace más de dos décadas, con mitigaciones bien establecidas (validación de rutas, uso de APIs seguras de acceso a archivos, principio de menor privilegio). Que una plataforma lanzada en la década de 2020 incluya un controlador de recursos estáticos sin sanitización de rutas sugiere ausencia de revisión de código orientada a seguridad en el ciclo de desarrollo.
Lo que distingue este caso no es la sofisticación técnica de la falla — es trivial de explotar — sino la combinación de factores que amplifican el riesgo en contextos latinoamericanos: adopción en sectores con baja madurez en gestión de vulnerabilidades, exposición a internet de instancias que deberían estar en redes internas, y falta de monitoreo de actualizaciones de seguridad en dependencias open-source de nicho. Comparado con vulnerabilidades en software empresarial occidental (donde los vendors suelen emitir boletines, ofrecer parches automáticos y notificar a clientes directamente), las fallas en herramientas chinas de código abierto dependen de que los administradores monitoreen activamente repositorios de GitHub o bases de datos de CVEs — un proceso que rara vez está formalizado en organizaciones pequeñas y medianas de la región.
¿Cuántas instancias de DataEase en América Latina siguen ejecutando versiones anteriores a 1.18.10 tres años después del parche, sin que sus administradores sepan que están exponiendo archivos de configuración a cualquiera que sepa construir una URL con «../» en el path?