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

gato fantasma

Pesquisadores da Chaitin Tech, China divulgaram informações sobre uma nova descoberta, conforme identificaram uma vulnerabilidade no popular contêiner de servlet (Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket) Apache tomcat (já listado como CVE-2020-1938).

Esta vulnerabilidade eles receberam 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 um pedido via porta de rede 8009 para ler o conteúdo de qualquer arquivo no diretório do aplicativo da web, incluindo códigos-fonte do aplicativo e arquivos de configuração.

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 para o servidor.

Por exemplo, se o aplicativo do site permite que os usuários carreguem arquivos, um invasor pode cobrar primeiro um arquivo contendo o código de script JSP malicioso no servidor (o próprio arquivo carregado pode ser qualquer tipo de arquivo, como imagens, arquivos de texto simples, etc.) e inclua o arquivo carregado explorando a vulnerabilidade do Ghostcat, que pode resultar em execução remota de código.

Também é mencionado que um ataque pode ser executado se for possível enviar uma solicitação a uma porta de rede com um driver AJP. De acordo com dados preliminares, a rede encontrou mais de 1.2 milhão de hosts aceitando solicitações usando o protocolo AJP.

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

Além de aceitar conexões HTTP (porta 8080) no Apache Tomcat, por padrão é possível acessar para o aplicativo da web usando o protocolo AJP (Protocolo Apache Jserv, porta 8009), que é um análogo binário de HTTP otimizado para maior desempenho, geralmente usado ao criar um cluster de servidores Tomcat ou para acelerar a interação com Tomcat em um proxy reverso ou balanceador de carga.

AJP fornece uma função padrão para acessar arquivos no servidor, que pode ser utilizado, inclusive para o recebimento de arquivos não sujeitos a divulgação.

Entende-se que o acesso a AJP está aberto apenas para servidores de confiançamas, na verdade, na configuração padrão do Tomcat, o driver foi iniciado em todas as interfaces de rede e as solicitações foram aceitas sem autenticação.

O acesso é possível a qualquer arquivo no aplicativo da web, incluindo o conteúdo de WEB-INF, META-INF e qualquer outro diretório retornado por meio da chamada ServletContext.getResourceAsStream (). O AJP também permite que você use qualquer arquivo em diretórios disponíveis para um aplicativo da web como um script JSP.

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

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

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

  • Se o cluster ou proxy reverso não for usado, pode-se basicamente determinar que o AJP não é usado.
  •  Caso contrário, você precisa descobrir se o cluster ou servidor reverso está se comunicando com o serviço Tomcat AJP Connect

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

Como solução alternativa, você pode desativar o serviço do Conector Tomcat AJP (ligar o soquete de escuta ao host local ou comentar a linha com a porta do Conector = »8009 ″), se não for necessário, ou configurar o acesso autenticado.

Se você quiser saber mais sobre isso, você pode consultar o seguinte link. 


Deixe um comentário

Seu endereço de email não será publicado. Campos obrigatórios são marcados com *

*

*

  1. Responsável pelos dados: Miguel Ángel Gatón
  2. Finalidade dos dados: Controle de SPAM, gerenciamento de comentários.
  3. Legitimação: Seu consentimento
  4. Comunicação de dados: Os dados não serão comunicados a terceiros, exceto por obrigação legal.
  5. Armazenamento de dados: banco de dados hospedado pela Occentus Networks (UE)
  6. Direitos: A qualquer momento você pode limitar, recuperar e excluir suas informações.