La vulnerabilidad CVE-2024-36401 en GeoServer ya se explota en ataques reales y puede permitir ejecución remota de código sin autenticación. La prioridad consiste en actualizar a versiones corregidas o, si no es posible hacerlo de inmediato, aplicar mitigaciones y reducir la exposición a Internet de forma urgente.
Administraciones y empresas que publican servicios cartográficos con OSGeo GeoServer enfrentan un problema urgente. Un fallo crítico permite a un atacante tomar el control del servidor sin credenciales si la instancia expone ciertos endpoints de OGC. La vulnerabilidad, registrada como CVE-2024-36401, ya se vincula a intentos de explotación activa e intrusiones confirmadas, un escenario especialmente delicado en entornos donde GeoServer sirve información geoespacial a través de Internet.
El defecto se origina en la forma en que GeoServer y su biblioteca GeoTools interpretan determinados nombres de propiedades. En configuraciones por defecto, algunos parámetros pueden evaluarse como expresiones XPath, lo que abre la puerta a cadenas maliciosas capaces de desencadenar ejecución remota de código mediante commons jxpath. En la práctica, un atacante puede enviar peticiones construidas deliberadamente para forzar el comportamiento vulnerable y ejecutar instrucciones en el sistema.
La superficie de ataque no se limita a un único servicio. Intervienen peticiones WFS como GetFeature y GetPropertyValue, funciones de WMS como GetMap, GetFeatureInfo y GetLegendGraphic, además de WPS Execute. En otras palabras, basta con que el servidor publique estos endpoints y permanezca accesible desde Internet para que el riesgo se incremente considerablemente.
Los incidentes documentados muestran un patrón conocido: acceso inicial con CVE-2024-36401, reconocimiento dentro de la red, movimiento lateral y persistencia mediante web shells. Entre las herramientas observadas figura China Chopper, un programa clásico por su sencillez y por permitir recuperar control remoto rápidamente tras un reinicio o un cambio superficial en el servicio.
La corrección ya existe en varias ramas del proyecto. Las versiones que incluyen parche son GeoServer 2.22.6, 2.23.6, 2.24.4 y 2.25.2. La recomendación es actualizar sin demora a una de esas versiones o a una posterior, y considerar cualquier instancia expuesta como potencialmente comprometida si ha estado accesible sin parche.
Cuando el parche no llega a tiempo, se ha propuesto una mitigación operativa: retirar del despliegue el fichero gt-complex x.y.jar. Esa medida puede reducir el riesgo, pero también afecta funcionalidades y, en ciertos entornos, incluso puede impedir el arranque si el módulo resulta imprescindible. Conviene validarla previamente en un entorno de pruebas y planificar un retorno rápido al estado anterior si el servicio queda inoperativo.
Más allá de parchear, la defensa pasa por reducir exposición. Limitar el acceso por IP, exigir VPN, colocar un proxy inverso con autenticación y reglas de filtrado mientras se completa la actualización reduce drásticamente la probabilidad de explotación. También resulta necesario revisar logs de GeoServer y del frontal web en busca de patrones anómalos en solicitudes WFS, WMS y WPS, especialmente filtros y parámetros inusuales.
Si el servidor ha estado expuesto, el trabajo no termina con la actualización. Hay que buscar indicios de compromiso en el host, como web shells, procesos inesperados o conexiones salientes extrañas, y rotar credenciales asociadas al sistema. Un plan de respuesta a incidentes probado y una monitorización continua ayudan a acortar el tiempo de detección, justo lo que marca la diferencia cuando se trata de RCE sin autenticación.
Con Información de unaaldia.hispasec.com
