Vulnerabilidade en Apache Tomcat que permite substituír código JSP e obter ficheiros de aplicacións web

Descubriron os investigadores da empresa chinesa Chaitin Tech vulnerabilidade (CVE-2020-1938) en Apache tomcat, unha implementación aberta das tecnoloxías Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket. A vulnerabilidade foi asignada ao nome de código Ghostcat e a un nivel de gravidade crítico (9.8 CVSS). O problema permite, na configuración predeterminada, enviando unha solicitude no porto de rede 8009, ler o contido de calquera ficheiro do directorio da aplicación web, incluídos os ficheiros con configuración e códigos fonte da aplicación.

A vulnerabilidade tamén permite importar outros ficheiros no código da aplicación, o que permite a execución de código no servidor se a aplicación permite cargar ficheiros no servidor (por exemplo, un atacante pode cargar un script JSP disfrazado de imaxe a través de formulario de carga de imaxes). O ataque pódese levar a cabo cando é posible enviar unha solicitude a un porto de rede cun manejador AJP. Segundo datos preliminares, en liña atopado máis de 1.2 millóns de hosts que aceptan solicitudes a través do protocolo AJP.

A vulnerabilidade existe no protocolo AJP, e non chamado erro na implementación. Ademais de aceptar conexións vía HTTP (porto 8080), Apache Tomcat permite por defecto o acceso a unha aplicación web a través do protocolo AJP (Protocolo Apache Jserv, porto 8009), que é un análogo binario de HTTP optimizado para un maior rendemento, normalmente usado cando se crea un clúster de servidores Tomcat ou para acelerar a interacción con Tomcat nun proxy inverso ou equilibrador de carga.

AJP proporciona unha función estándar para acceder a ficheiros no servidor, que se pode usar, incluíndo a obtención de ficheiros que non están suxeitos a divulgación. Suponse que AJP só é accesible para servidores de confianza, pero de feito a configuración predeterminada de Tomcat executou o controlador en todas as interfaces de rede e aceptou solicitudes sen autenticación. É posible acceder a calquera ficheiro de aplicación web, incluídos os contidos de WEB-INF, META-INF e calquera outro directorio proporcionado mediante unha chamada a ServletContext.getResourceAsStream(). AJP tamén permite usar calquera ficheiro en directorios accesibles para a aplicación web como un script JSP.

O problema aparece dende a rama Tomcat 13.x lanzado hai 6 anos. Ademais do propio problema de Tomcat afecta e produtos que o usan, como Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), así como aplicacións web autónomas que utilizan Bota de primavera. Vulnerabilidade semellante (CVE-2020-1745) presente no servidor web Resaca, usado no servidor de aplicacións Wildfly. En JBoss e Wildfly, AJP está habilitado por defecto só nos perfís standalone-full-ha.xml, standalone-ha.xml e ha/full-ha en domain.xml. En Spring Boot, o soporte AJP está desactivado por defecto. Actualmente, diferentes grupos prepararon máis dunha ducia de exemplos prácticos de exploits (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Vulnerabilidade corrixida nas versións de Tomcat 9.0.31, 8.5.51 и 7.0.100 (mantemento da rama 6.x descontinuado). Podes seguir a dispoñibilidade de actualizacións nos kits de distribución nestas páxinas: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Como solución alternativa, pode desactivar o servizo Tomcat AJP Connector (enlazar un socket de escoita a localhost ou comentar a liña con Connector port = "8009") se non é necesario, ou configurar acceso autenticado mediante os atributos "secret" e "address", se o servizo se usa para interactuar con outros servidores e proxies baseados en mod_jk e mod_proxy_ajp (mod_cluster non admite a autenticación).

Fonte: opennet.ru