La vulnerabilidad CVE-2024-36401 en GeoServer ya se explota en ataques reales y puede resultar en ejecución remota de código sin autenticación. La prioridad pasa por actualizar a versiones corregidas o, si no se llega a tiempo, aplicar mitigaciones y reducir exposición a Internet de forma inmediata.
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 aparece vinculada 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 nace en el modo 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 a propósito para forzar el comportamiento vulnerable y ejecutar instrucciones en el sistema.
La superficie de ataque no se limita a un único servicio. Entran en juego peticiones WFS como GetFeature y GetPropertyValue, funciones de WMS como GetMap, GetFeatureInfo y GetLegendGraphic, además de WPS Execute. Dicho de otro modo, basta con que el servidor publique estos endpoints y permanezca accesible desde Internet para que el riesgo se dispare.
Los incidentes documentados dibujan 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 clásico por su sencillez y por lo rápido que permite recuperar control remoto 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 práctica es actualizar sin demora a una de esas versiones o a una posterior, y tratar 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 rompe funcionalidades y, en ciertos entornos, incluso puede impedir el arranque si el módulo resulta imprescindible. Conviene validarla antes 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 recortar 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 toca 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
