Investigadores de la empresa china Chaitin Tech han descubierto () En , una implementación abierta de las tecnologías Java Servlet, JavaServer Pages, Java Expression Language y Java WebSocket. A la vulnerabilidad se le ha asignado el nombre clave Ghostcat y un nivel de gravedad crítico (9.8 CVSS). El problema permite, en la configuración predeterminada, enviando una solicitud en el puerto de red 8009, leer el contenido de cualquier archivo del directorio de la aplicación web, incluidos los archivos con configuraciones y códigos fuente de la aplicación.
La vulnerabilidad también hace posible importar otros archivos al código de la aplicación, lo que permite la ejecución de código en el servidor si la aplicación permite cargar archivos en el servidor (por ejemplo, un atacante puede cargar un script JSP disfrazado de imagen a través de el formulario de carga de imágenes). El ataque se puede llevar a cabo cuando es posible enviar una solicitud a un puerto de red con un controlador AJP. Según datos preliminares, en línea más de 1.2 millones de hosts aceptan solicitudes a través del protocolo AJP.
La vulnerabilidad existe en el protocolo AJP y error en la implementación. Además de aceptar conexiones vía HTTP (puerto 8080), Apache Tomcat por defecto permite el acceso a una aplicación web vía el protocolo AJP (, puerto 8009), que es un análogo binario de HTTP optimizado para un mayor rendimiento, generalmente utilizado 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 se puede utilizar, incluida la obtención de archivos que no están sujetos a divulgación. Se supone que AJP es accesible sólo para servidores confiables, pero de hecho la configuración predeterminada de Tomcat ejecutó el controlador en todas las interfaces de red y aceptó solicitudes sin autenticación. Es posible acceder a cualquier archivo de aplicación web, incluido el contenido de WEB-INF, META-INF y cualquier otro directorio proporcionado mediante una llamada a ServletContext.getResourceAsStream(). AJP también le permite utilizar cualquier archivo en directorios accesibles para la aplicación web como un script JSP.
El problema ha estado apareciendo desde que se lanzó la rama Tomcat 13.x hace 6 años. Además del problema de Tomcat en sí. y productos que lo utilizan, como Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), así como aplicaciones web autónomas que utilizan . Vulnerabilidad similar (CVE-2020-1745) en el servidor web , utilizado en el servidor de aplicaciones Wildfly. En JBoss y Wildfly, AJP está habilitado de forma predeterminada solo en los perfiles standalone-full-ha.xml, standalone-ha.xml y ha/full-ha en domain.xml. En Spring Boot, la compatibilidad con AJP está deshabilitada de forma predeterminada. Actualmente, diferentes grupos han preparado más de una docena de ejemplos prácticos de exploits (
,
,
,
,
,
,
,
,
,
,
).
Vulnerabilidad solucionada en las versiones de Tomcat , и (mantenimiento de la rama 6.x ). Puede realizar un seguimiento de la disponibilidad de actualizaciones en los kits de distribución en estas páginas: , , , , , . Como solución alternativa, puede desactivar el servicio Tomcat AJP Connector (vincular un socket de escucha al host local o comentar la línea con Connector port = "8009") si no es necesario, o acceso autenticado utilizando los atributos “secreto” y “dirección”, si el servicio se utiliza para interactuar con otros servidores y proxies basados en mod_jk y mod_proxy_ajp (mod_cluster no admite autenticación).
Fuente: opennet.ru