CTF Biscuit — Vai um biscoitinho🍪modificao ae?

🎯 Informações Gerais

Target: 172.16.9.251 — Biscuit Dificuldade: Média 🐤 Plataforma: HackingClub Sistema Operacional: Linux Tempo de Exploração: 5–6hrs (Esse foi o tempo que eu levei) Status: PWNED 🎯Vulnerabilidades Conhecidas: RFI, Type Juggling, Credenciais Fracas, Manipulação de Cookies, Falha de Controle de Acesso Root

📋 Resumo Executivo

Este relatório documenta uma das explorações mais educativas que demonstra como vulnerabilidades aparentemente menores podem ser encadeadas para comprometimento total. Nossa jornada através da máquina “Biscuit” revelou uma cadeia de vulnerabilidades interconectadas que, quando exploradas sequencialmente, resultaram em acesso root completo. A exploração exigiu criatividade, persistência e conhecimento técnico profundo, culminando em uma das escalações de privilégio mais elegantes que já executamos.

🏆 Flags Capturadas:

1. Flag 1: Falha explorada — Cookie Tampering
2. Flag 2: Falha explorada — Type Juggling + RFI
3. Flag 3: Falha explorada — Format String + Privilege Escalation

Esta não foi apenas uma exploração técnica — foi uma jornada de descoberta que demonstra por que a segurança cibernética é tanto arte quanto ciência.

• 3 Flags Conquistadas — Cada uma mais desafiadora que a anterior
• 5 Vulnerabilidades Exploradas — Type Juggling, Cookie Tampering, RFI, Format String, Hardcoded Secrets
• Incontáveis Lições Aprendidas — Sobre persistência, criatividade e elegância técnica.

🔍 Fase 1: Reconhecimento — “Batendo na Porta Principal”

Nossa aventura começou da forma mais tradicional possível — batendo na porta principal para ver quem estava em casa.

Descoberta Inicial

whatweb http://172.16.9.251

Resultados:

• Apache 2.4.48 + PHP 7.4.19
• Página de login com campos username/password
• Cookie PHPSESSID presente

Foi como analisar a fachada de uma casa antes de tentar entrar — queria saber que tipo de fechaduras estava enfrentando.

Enumeração de Diretórios

Comecei a procurar por portas dos fundos, janelas deixadas abertas, ou qualquer acesso alternativo.

gobuster dir -u http://172.16.9.251 -w /usr/share/wordlists/dirb/common.txt -x php,txt,html

Descobertas que mudariam tudo:

• /index.php - Endpoint principal
• /class/ - Diretório com classes PHP
• /class/Auth.class.php - Classe de autenticação
• /.html - Arquivo com status 403

Cada descoberta era como encontrar uma peça de um quebra-cabeças complexo.

🔓 Fase 2: O Mistério do Type Juggling — “A Porta Entreaberta”

Foi aqui que minha jornada tomou uma direção inesperada.

A Descoberta que Mudou Tudo

Estava testando credenciais básicas quando algo estranho aconteceu:

• Credenciais admin/admin → ❌ "Usuario ou senha inválido!" (6906 bytes)
• Credenciais admin/0 → ✅ Silêncio suspeito (6773 bytes)
• Credenciais 0/0 → ✅ Mais silêncio suspeito (6773 bytes)

Com qualquer outro usuário, dava erro, mas 0:0 nao.

O momento “Eureka!”:

A diferença de exatos 133 bytes entre as respostas foi nossa primeira pista real. Era como perceber que uma porta que deveria estar trancada na verdade só estava encostada. Esses 133 bytes eram exatamente o tamanho da mensagem de erro que não estava aparecendo.

Descobri então o que estava diante de um caso clássico de Type Juggling em PHP — uma vulnerabilidade onde comparações fracas (==) podem produzir resultados inesperados. Era como ter uma chave que não deveria funcionar, mas funcionava porque a fechadura estava mal projetada.

🎯 Fase 3: Exploração — Primeira Flag

Cookie Manipulation Attack

Descoberta do Login Guest:

Aqui foi bem tranquilo, eu só fui tentando uma lista dos 10 usuários e senha mais utilizados que encontrei na web, e quando cheguei na guest:guest funcionou.

• Credenciais: guest:guest (credenciais fracas)
• Obteve cookie de sessão válido

Aqui tudo mudou, eu tinha um usuario e um cookie de sessão válido!

Análise do Cookie:

Joguei a hash no CyberChef e era um simples base64

O momento da verdade:

Olhando para essa estrutura, uma ideia brilhante surgiu: se Type Juggling funcionava para senhas, por que não funcionaria para HMACs? Era hora de testar nossa teoria na prática.

O payload que mudou o jogo:

{"hmac":"85570f175991dc425c443fe71f8ba8da","username":"admin","expiration":1754354446}7

#passei no bas64 novamente, e injetei via browser, mas agora com username admin.
eyJobWFjIjoiODU1NzBmMTc1OTkxZGM0MjVjNDQzZmU3MWY4YmE4ZGEiLCJ1c2VybmFtZSI6ImFkbWluIiwiZXhwaXJhdGlvbiI6MTc1NDM1NDQ0Nn03

Modifiquei o username para admin mas mantive o HMAC original. Era como tentar usar um cartão de crédito com nome trocado mas mesma assinatura - teoricamente não deveria funcionar, mas...

A primeira flag veio!

🏆 Primeira Flag Conquistada!

Era como ser pego tentando entrar pela janela, mas o alarme que disparou nos deu exatamente a informação que precisávamos: A Flag! Às vezes, ser pego é parte do plano!

🚀 Fase 4: A Obra-Prima — “Quando 1+1=Acesso Total”

Agora vinha a parte mais criativa da nossa jornada. Eu tinha duas vulnerabilidades distintas: Type Juggling e cookie tampering detectado.

Se o sistema detectava manipulação de cookie, mas ainda processava o conteúdo, talvez pudéssemos usar isso a nosso favor. E se o campo username não fosse apenas um identificador, mas um vetor de ataque?

O payload que fez história:

Mesmo esquema, peguei um reverse shell php na internet, criei o arquivo shellzin.php , subi meu servidor http e tudo pronto!

O plano era o seguinte:

Criar um Shell localmente: Shellzin.php Subir um servidor local, para transferir a shell para o servidor remoto. Usar o cookie para baixar a shellpara dentro do servidor remoto. Torce para que fosse executado 😵‍💫.

joguei no CyberChef:

Ta feito!

O plano agora era só colocar tudo em prática.

To dentro! (eu tinha salvo o arquivo com nome errado antes, por isso os 404 😊.

Resultado: Reverse shell como usuário apache

Logamos com o usuario apache, melhor que nada ne!

🏆 Flag 2 Capturada:

A segunda flag estava ao alcance!

⬆️ Fase 5: Privilege Escalation — Terceira Flag

Enumeração do Sistema

Informações do Sistema:

whoami          # apache
id              # uid=48(apache) gid=48(apache)
uname -a        # Amazon Linux 2, kernel 4.14.232

Descoberta Crítica — Sudo Permissions:

sudo -l
# User apache may run the following commands:
# (ALL) NOPASSWD: /opt/biscuit_checker.py

Esse sudo -l está te dizendo que o usuário apache tem permissão para executar exactamente o comando /opt/biscuit_checker.py como qualquer usuário (incluindo root) sem precisar digitar senha.

Em outras palavras: (ALL): ele pode executar esse script como qualquer usuário alvo do sistema (por padrão, root). NOPASSWD: não vai pedir senha de sudo para rodá-lo.

Análise do Script Python

Tentativas Iniciais (Fracassadas):

• Command injection no menu;
• Python library hijacking (bloqueado por sudo);
• Environment variable manipulation (bloqueado);

Nada estava funcionando!

Esse script python não tinha muita coisa, eu não conseguia ler o mesmo também, somente executar.

Parece que o script tinha uma função de bloquear IPs que fossem adicionados, mas nenhuma das opções eram muito funcionais.

Descoberta do Arquivo JSON Manipulável

Como o script fazia algo como bloquear ou listar endereços de IP’s bloqueados, eu procurei por arquivos no sistema que tivessem a palavra blockenvolvida, encontrei um na pasta www.

Arquivo encontrado:

• /var/www/html/block.ips.db.json
• Permissões de escrita para usuário apache
• Usado pelo script Python executado como root;

Conteúdo inicial:

Eu não fazia ideia do que fazer com isso, fiquei umas 2 horas pesquisando online.

{"ips":[]}

Foi então que a dica na descrição da maquina me ajudou a chegar aonde no próximo passo; Format String

Eu tentei causar errors na aplicação para estudar o output:

E aqui esta a string que vai me salvar!

A ideia agora era como usar isso :D.

Infinitas horas depois, eu consegui chegar na seguinte payload.

{"ips":["{ip.list_blocked.__globals__}"]}

Execução:

sudo /opt/biscuit_checker.py
# Opção 2 - List Blocked IPs

E o resultado foi a senha do root :D.

Flag Final:

Com a senha do usuário root em mão, agora era so ler o ultimo arquivo de flag e terminar nosso desafio!

🏆 Flag 3 Capturada

📊 Cadeia de Exploração

1. Reconhecimento → Descoberta de login page
2. Type Juggling → Bypass parcial de autenticação  
3. Credenciais Fracas → Login como guest:guest
4. Cookie Analysis → Descoberta da estrutura JSON
5. HMAC Bypass → Type juggling com hmac:true
6. RFI Exploitation → Remote code execution via username field
7. Reverse Shell → Acesso como apache
8. Sudo Enumeration → Descoberta do script Python
9. File Write Permission → Controle sobre JSON file
10. Format String → Extração de variáveis globais
11. Secret Extraction → Descoberta da senha root
12. Privilege Escalation → su root com senha extraída

🛡️Monitoramento Recomendado

# Log analysis patterns
grep "Type juggling attempt" /var/log/apache2/access.log
grep "Cookie manipulation" /var/log/security.log
grep "RFI attempt" /var/log/php_errors.log
grep "Format string exploit" /var/log/python.log

A Metodologia OWASP em Ação

• Reconhecimento sistemático — Cada porta, cada janela foi verificada
• Enumeração completa — Nenhum diretório foi deixado sem investigação
• Exploração incremental — Cada vulnerabilidade foi um degrau para a próxima
• Privilege escalation metódica — Do guest ao apache ao root, passo a passo

📝 Conclusão — “O Fim de Uma Jornada, Início de Muitas Outras”

A máquina CTF “Biscuit” se revelou muito mais do que um simples desafio técnico — foi uma masterclass em pensamento criativo aplicado à segurança cibernética.