Pesquisadores da empresa chinesa Chaitin Tech identificaram () em , uma implementação aberta das tecnologias Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket. A vulnerabilidade foi nomeada Ghostcat e classificada com um nível crítico de severidade (9.8 CVSS). O problema permite que, na configuração padrão, ao enviar uma solicitação pela porta de rede 8009, seja possível ler o conteúdo de quaisquer arquivos do diretório do aplicativo web, incluindo arquivos de configuração e códigos fonte do aplicativo.
A vulnerabilidade também permite importar outros arquivos para o código do aplicativo, o que pode resultar na execução de código no servidor, se o aplicativo permitir o upload de arquivos (por exemplo, o atacante pode carregar um script JSP disfarçado como uma imagem através de um formulário de upload de imagem). O ataque pode ser realizado se for possível enviar uma solicitação para a porta de rede com o manipulador AJP. De acordo com informações preliminares, existem na rede mais de 1,2 milhão de hosts aceitando solicitações via protocolo AJP.
A vulnerabilidade está presente no protocolo AJP, mas por um erro na implementação. Além de aceitar conexões via HTTP (porta 8080), o Apache Tomcat, por padrão, permite o acesso ao aplicativo web através do protocolo AJP (, porta 8009), que é uma alternativa binária otimizada para alcançar maior desempenho, geralmente utilizada na criação de clusters de servidores Tomcat ou para acelerar a interação com Tomcat em um proxy reverso ou balanceador de carga.
O AJP fornece uma funcionalidade padrão para acessar arquivos no servidor, que pode ser usada, entre outras coisas, para obter arquivos que não deveriam ser divulgados. Supõe-se que o acesso ao AJP esteja aberto apenas para servidores de confiança, mas na realidade, na configuração padrão, o Tomcat estava configurado para iniciar o manipulador em todas as interfaces de rede, e as solicitações eram aceitas sem autenticação. O acesso era possível a quaisquer arquivos do aplicativo web, incluindo o conteúdo de WEB-INF, META-INF e quaisquer outros diretórios acessados através da chamada ServletContext.getResourceAsStream(). O AJP também permite que qualquer arquivo nos diretórios disponíveis para o aplicativo web seja usado como um script JSP.
O problema aparece a partir da versão do Tomcat 6.x, lançada há 13 anos. Além do próprio Tomcat, o problema e os produtos que o utilizam, como o Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), assim como aplicações web autossuficientes que utilizam . Uma vulnerabilidade semelhante (CVE-2020-1745) no servidor web , usado no servidor de aplicações Wildfly. No JBoss e Wildfly, o protocolo AJP está habilitado por padrão apenas nos perfis standalone-full-ha.xml, standalone-ha.xml e ha/full-ha no domain.xml. No Spring Boot, o suporte a AJP está desabilitado por padrão. Atualmente, diversos grupos prepararam mais de uma dezena de exemplos funcionais de exploits (
,
,
,
,
,
,
,
,
,
,
).
A vulnerabilidade foi corrigida nas versões do Tomcat , e ((manutenção da ramificação 6.x ). É possível acompanhar o lançamento de atualizações nas distribuições através dessas páginas: , , , , , . Como uma medida de contorno, pode-se desativar o serviço Tomcat AJP Connector (vincular o socket ouvinte ao localhost ou comentar a linha com Connector port = "8009"), se não for necessário, ou acesso autenticado usando os atributos "secret" e "address", caso o serviço seja utilizado para interação com outros servidores e proxies baseados em mod_jk e mod_proxy_ajp (a autenticação mod_cluster não é suportada).
Fonte: opennet.ru
