Investigadores de la empresa china Chaitin Tech han identificado () en , una implementación abierta de las tecnologías Java Servlet, JavaServer Pages, Java Expression Language y Java WebSocket. Esta vulnerabilidad ha recibido el nombre en clave Ghostcat y su nivel de peligrosidad es crítico (9.8 CVSS). El problema permite, en la configuración predeterminada, leer el contenido de cualquier archivo del directorio de la aplicación web mediante el envío de una solicitud al puerto de red 8009, incluyendo archivos de configuración y el código fuente de la aplicación.
La vulnerabilidad también permite importar otros archivos en el código de la aplicación, lo que posibilita la ejecución de código en el servidor, si la aplicación permite la carga de archivos en el servidor (por ejemplo, un atacante puede subir un script JSP haciéndose pasar por una imagen a través de un formulario de carga). El ataque puede llevarse a cabo si hay posibilidad de enviar una solicitud al puerto de red con el manejador AJP. Según datos preliminares, en la red hay más de 1.2 millones de hosts que aceptan solicitudes a través del protocolo AJP.
La vulnerabilidad está presente en el protocolo AJP, y por un error en la implementación. Además de aceptar conexiones por HTTP (puerto 8080), Apache Tomcat, por defecto, permite el acceso a la aplicación web a través del protocolo AJP (, puerto 8009), que es un análogo binario optimizado para lograr un mayor rendimiento del HTTP, utilizado generalmente al crear un clúster de servidores Tomcat o para acelerar la interacción con Tomcat en un proxy inverso o equilibrador de carga.
AJP proporciona una función estándar para acceder a archivos en el servidor, que también puede ser utilizada para obtener archivos que no deberían ser divulgados. Se supone que el acceso a AJP está abierto solo para servidores de confianza, pero en realidad, en la configuración predeterminada, Tomcat se inicia con el manejador en todas las interfaces de red, y las solicitudes se aceptan sin autenticación. Es posible acceder a cualquier archivo de la aplicación web, incluyendo contenido de WEB-INF, META-INF y cualquier otro directorio accesible a través de la llamada ServletContext.getResourceAsStream(). AJP también permite utilizar cualquier archivo en los directorios disponibles para la aplicación web como un script JSP.
El problema se manifiesta desde el lanzamiento de la versión Tomcat 6.x hace 13 años. Además de Tomcat, el problema afecta a productos que lo utilizan, como Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), así como aplicaciones web independientes que usan . Una vulnerabilidad similar (CVE-2020-1745) en el servidor web , utilizado en el servidor de aplicaciones Wildfly. En JBoss y Wildfly, el protocolo AJP está habilitado por defecto solo en standalone-full-ha.xml, standalone-ha.xml y en los perfiles ha/full-ha en domain.xml. En Spring Boot, el soporte para AJP está desactivado de forma predeterminada. Actualmente, varios grupos han preparado más de una docena de ejemplos funcionales de exploits (
,
,
,
,
,
,
,
,
,
,
).
La vulnerabilidad ha sido corregida en las versiones de Tomcat , y (mantenimiento de la rama 6.x ). Se puede seguir la aparición de actualizaciones en las distribuciones en estas páginas: , , , , , . Como medida de mitigación, se puede desactivar el conector de servicio Tomcat AJP (vincular el socket de escucha a localhost o comentar la línea con Connector port = «8009»), si no es necesario, o el acceso autenticado utilizando los atributos «secret» y «address», si el servicio se utiliza para interactuar con otros servidores y proxies basados en mod_jk y mod_proxy_ajp (la autenticación mod_cluster no es compatible).
Fuente: opennet.ru
