Vulnerabilidade no Apache Tomcat que permite substituir o código JSP e obter arquivos de aplicativos da web

Pesquisadores da empresa chinesa Chaitin Tech descobriram vulnerabilidade (CVE-2020-1938) em Apache Tomcat, uma implementação aberta das tecnologias Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket. A vulnerabilidade recebeu o codinome Ghostcat e um nível de gravidade crítico (9.8 CVSS). O problema permite, na configuração padrão, através do envio de uma solicitação na porta de rede 8009, ler o conteúdo de quaisquer arquivos do diretório da aplicação web, incluindo arquivos com configurações e códigos-fonte da aplicação.

A vulnerabilidade também possibilita a importação de outros arquivos para o código da aplicação, o que permite a execução do código no servidor caso a aplicação permita o upload de arquivos para o servidor (por exemplo, um invasor pode fazer upload de um script JSP disfarçado de imagem por meio de o formulário de upload de imagem). O ataque pode ser realizado quando é possível enviar uma solicitação para uma porta de rede com um manipulador AJP. De acordo com dados preliminares, online encontrado mais de 1.2 milhão de hosts aceitando solicitações por meio do protocolo AJP.

A vulnerabilidade existe no protocolo AJP e não ligou erro na implementação. Além de aceitar conexões via HTTP (porta 8080), o Apache Tomcat por padrão permite o acesso a uma aplicação web através do protocolo AJP (Protocolo Apache Jserv, porta 8009), que é um análogo binário do HTTP otimizado para maior desempenho, geralmente usado ao criar um cluster de servidores Tomcat ou para acelerar a interação com o Tomcat em um proxy reverso ou balanceador de carga.

O AJP fornece uma função padrão para acesso a arquivos no servidor, que pode ser utilizada, inclusive, para obter arquivos que não estão sujeitos a divulgação. Supõe-se que o AJP seja acessível apenas a servidores confiáveis, mas na verdade a configuração padrão do Tomcat executava o manipulador em todas as interfaces de rede e aceitava solicitações sem autenticação. O acesso é possível a qualquer arquivo de aplicação web, incluindo o conteúdo de WEB-INF, META-INF e quaisquer outros diretórios fornecidos através de uma chamada para ServletContext.getResourceAsStream(). AJP também permite usar qualquer arquivo em diretórios acessíveis à aplicação web como um script JSP.

O problema vem aparecendo desde o lançamento do branch Tomcat 13.x, há 6 anos. Além do próprio problema do Tomcat afeta e produtos que o utilizam, como Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), bem como aplicativos web independentes que usam Bota de mola. Vulnerabilidade semelhante (CVE-2020-1745) presente no servidor web Ressaca, usado no servidor de aplicativos Wildfly. No JBoss e Wildfly, o AJP é habilitado por padrão apenas nos perfis standalone-full-ha.xml, standalone-ha.xml e ha/full-ha em domain.xml. No Spring Boot, o suporte AJP está desabilitado por padrão. Atualmente, diferentes grupos prepararam mais de uma dúzia de exemplos práticos de explorações (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Vulnerabilidade corrigida nas versões do Tomcat 9.0.31, 8.5.51 и 7.0.100 (manutenção da filial 6.x interrompido). Você pode acompanhar a disponibilidade de atualizações nos kits de distribuição nestas páginas: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. Como solução alternativa, você pode desabilitar o serviço Tomcat AJP Connector (vincular um soquete de escuta ao host local ou comentar a linha com Connector port = "8009") se não for necessário, ou sintonia acesso autenticado utilizando os atributos “secret” e “address”, caso o serviço seja utilizado para interagir com outros servidores e proxies baseados em mod_jk e mod_proxy_ajp (mod_cluster não suporta autenticação).

Fonte: opennet.ru