Ghostcat é a vulnerabilidade no Tomcat

Pesquisadores da Chaitin Tech, China divulgaram informações sobre uma nova descoberta, pois identificaram uma vulnerabilidade no popular contêiner de servlets (Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket) Apache Tomcat (já listado como CVE-2020 -1938). Essa vulnerabilidade recebeu o nome de código “Ghostcat” e um nível de gravidade crítico (9,8 CVSS). O problema permite na configuração padrão enviar uma solicitação pela porta de rede 8009 para ler o conteúdo de qualquer arquivo no diretório de aplicativos da web. Isso inclui arquivos de configuração e códigos-fonte do aplicativo. Portanto, o Ghostcat é a vulnerabilidade no Tomcat capaz de substituir o código.

A vulnerabilidade também permite importar outros arquivos para o código do aplicativo, o que permite organizar a execução do código no servidor se o aplicativo permitir que os arquivos sejam carregados no servidor.

Ghostcat é a vulnerabilidade no Tomcat que pode substituir o código

Ghostcat é a vulnerabilidade no Tomcat que pode substituir o código

Por exemplo, se o aplicativo do site permitir que os usuários façam upload de arquivosum invasor poderá primeiro fazer upload de um arquivo que contém código de script JSP malicioso no servidor (pode ser qualquer tipo de arquivo, como imagens, arquivos de texto sem formatação etc.) e, em seguida, incluir o arquivo carregado que explora a vulnerabilidade do Ghostcat, que pode resultar em execução remota de código.

Também é mencionado que um ataque pode ser feito se for possível enviar uma solicitação para uma porta de rede com um controlador AJP. Segundo dados preliminares, a rede encontrou mais de 1,2 milhão de hosts que aceitam solicitações usando o protocolo AJP.

A vulnerabilidade está presente no protocolo AJP e não é causada por um erro de implementação.

Mais detalhes

Além de aceitar conexões HTTP (porta 8080) no Apache Tomcat, por padrão, é possível acessar o aplicativo Web usando o protocolo AJP (Protocolo Apache Jserv, porta 8009), que é um analógico binário HTTP otimizado para obter um desempenho superior, que geralmente é usado ao criar um cluster a partir 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 acessar arquivos no servidor, que podem ser usados, incluindo o recebimento de arquivos que não estão sujeitos a divulgação.

Entende-se que o acesso ao AJP é aberto apenas a servidores confiáveis, porém, na configuração padrão do Tomcat, o controlador foi iniciado em todas as interfaces de rede e as solicitações foram aceitas sem autenticação.

O acesso é possível a qualquer arquivo do aplicativo da web, incluindo o conteúdo de WEB-INF, META-INF e qualquer outro diretório retornado pelo chamado ServletContext.getResourceAsStream ().

Problema se alastrou

Ghostcat é a vulnerabilidade no Tomcat que pode substituir o código

O AJP também permite usar qualquer arquivo nos diretórios disponíveis para um aplicativo da web, como um script JSP.

O problema ficou evidente desde que a versão do Tomcat 6.x foi lançada 13 anos atrás. Além do próprio Tomcat, o problema também afeta os produtos que o utilizam, como o JBoss Web Server da Red Hat (JWS), o JBoss Enterprise Application Platform (EAP), bem como aplicativos da web independentes que usam o Spring Boot.

Uma vulnerabilidade semelhante (CVE-2020-1745) também foi encontrada no servidor da web Undertow usado no servidor de aplicativos Wildfly. Atualmente, vários grupos prepararam mais de uma dúzia de exemplos de trabalho de exploração.

Solução

O Apache Tomcat lançou oficialmente as versões 9.0.31, 8.5.51 e 7.0.100 para corrigir esta vulnerabilidade. Para isso, você deve primeiro determinar se o serviço Tomcat AJP Connector é usado no ambiente do servidor:

  • Se nenhum cluster ou proxy reverso for usado, basicamente poderá ser determinado que o AJP não seja usado.
  •  Caso contrário, você deve descobrir se o cluster ou o servidor reverso está se comunicando com o serviço Tomcat AJP Connect

Também é mencionado que as atualizações já estão disponíveis nas diferentes distribuições Linux, como: Debian, Ubuntu, RHEL, Fedora, SUSE.

Como uma solução alternativa, você pode desativar o serviço Tomcat AJP Connector, se não for necessário, ou configurar o acesso autenticado.

Da mesma forma, se você quiser saber mais sobre isso, consulte o seguinte link. 

Ubunlog

Artigos recentes

Artigos relacionados