Ghostcat, la vulnerabilidad en Tomcat que puede sustituir código

Investigadores de Chaitin Tech, China dieron a conocer información sobre un nuevo descubrimiento, pues han identificado una vulnerabilidad en el popular contenedor de servlets (Java Servlet, JavaServer Pages, Java Expression Language y Java WebSocket) Apache Tomcat (ya catalogada como CVE-2020-1938).

Esta vulnerabilidad se les asigno el nombre código “Ghostcat” y un nivel de gravedad crítico (9.8 CVSS). El problema permite en la configuración predeterminada enviar una solicitud a través del puerto de red 8009 para leer el contenido de cualquier archivo del directorio de la aplicación web, incluidos los archivos de configuración y los códigos fuente de la aplicación.

La vulnerabilidad también permite importar otros archivos en el código de la aplicación, lo que permite organizar la ejecución del código en el servidor si la aplicación permite que los archivos se carguen en el servidor.

Por ejempl, si la aplicación del sitio web permite a los usuarios cargar archivos, un atacante puede cargar primero un archivo que contenga código de script JSP malicioso en el servidor (el archivo cargado en sí mismo puede ser cualquier tipo de archivo, como imágenes, archivos de texto plano, etc.) y luego incluya el archivo cargado explotando la vulnerabilidad de Ghostcat, que finalmente puede resultar en la ejecución remota de código.

Tambien se menciona que se puede realizar un ataque si es posible enviar una solicitud a un puerto de red con un controlador AJP. Según datos preliminares, la red encontró más de 1.2 millones de hosts que aceptan solicitudes utilizando el protocolo AJP.

La vulnerabilidad está presente en el protocolo AJP y no es causada por un error de implementación.

Además de aceptar conexiones HTTP (puerto 8080) en Apache Tomcat, de forma predeterminada es posible acceder a la aplicación web utilizando el protocolo AJP (Protocolo Apache Jserv, puerto 8009), que es un análogo binario de HTTP optimizado para lograr un mayor rendimiento, que generalmente se usa al crear un clúster desde 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 los archivos en el servidor, que puede usarse, incluida la recepción de archivos que no están sujetos a divulgación.

Se entiende que el acceso a AJP está abierto solo a servidores de confianza, pero de hecho, en la configuración predeterminada de Tomcat, el controlador se lanzó en todas las interfaces de red y las solicitudes se aceptaron sin autenticación.

El acceso es posible a cualquier archivo de la aplicación web, incluidos los contenidos de WEB-INF, META-INF y cualquier otro directorio devuelto a través de la llamada ServletContext.getResourceAsStream(). AJP también le permite usar cualquier archivo en directorios disponibles para una aplicación web como un script JSP.

El problema ha sido evidente desde que se lanzó la rama Tomcat 6.x hace 13 años. Además del propio Tomcat, el problema también afecta a los productos que lo utilizan, como Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), así como a aplicaciones web autónomas que utilizan Spring Boot.

También se encontró una vulnerabilidad similar (CVE-2020-1745) en el servidor web Undertow utilizado en el servidor de aplicaciones Wildfly. Actualmente, varios grupos han preparado más de una docena de ejemplos de trabajo de exploits.

Apache Tomcat ha lanzado oficialmente las versiones 9.0.31, 8.5.51 y 7.0.100 para corregir esta vulnerabilidad. Para corregir esta vulnerabilidad correctamente, primero se debe determinar si el servicio Tomcat AJP Connector se usa en su entorno de servidor:

• Si no se usa clúster o proxy inverso, básicamente se puede determinar que no se usa AJP.
•  De lo contrario, se debe averiguar si el clúster o el servidor inverso se está comunicando con el servicio Tomcat AJP Connect

Tambien se menciona que ya estan disponibles las actualizaciones en las diferentes distribuciones de Linux como: Debian, Ubuntu, RHEL, Fedora, SUSE.

Como solución alternativa, se puede deshabilitar el servicio Tomcat AJP Connector (vincular el socket de escucha a localhost o comentar la línea con Connector port=”8009″), si no es necesario o configurar acceso autenticado.

Si quieres conocer más al respecto puedes consultar el siguiente enlace.