Dessincronização do Portal Nether (HUUP)

"Não viajo por estradas estabelecidas, mas salto livremente pelo vazio. Empacote-me errado e entregarei um segredo na porta errada."

Descrição

O desafio apresenta uma aplicação HTTP/3 (QUIC) sobre UDP. Como o UDP não tem estado e o proxy não impõe limites rígidos de requisições HTTP como o TCP, é possível dessincronizar o proxy e o servidor backend. Um atacante pode contrabandear uma requisição HTTP oculta dentro de outra requisição.

Notas - o tamanho máximo da mensagem é 1024 bytes, apenas requisições GET funcionarão de fato, e as mensagens são descartadas após 10 segundos

Alvo: byuctf.xyz:40011

Análise de Vulnerabilidade

• Vulnerabilidade: Contrabando de Requisição HTTP (sobre UDP/QUIC)
• Causa Raiz: Análise inconsistente dos limites do payload HTTP entre o proxy frontend e a aplicação backend sob protocolos não confiáveis.

Nesta implementação específica, um middleware Python (udp_server.py) escuta na porta 40000 por texto de entrada. Este servidor encaminha requisições assim que um \r\n\r\n é encontrado para o servidor web real. Como é UDP, há uma alta chance de entrega parcial de pacotes, levando à dessincronização se múltiplas requisições são enviadas rapidamente ou se os limites dos pacotes são manipulados.

Writeup

Para resolver este desafio, você deve levar em conta a natureza não confiável do UDP e a forma específica como o middleware lida com os limites das requisições.

1. Reconhecimento: Acessar o endpoint raiz / revela uma dica sobre a instabilidade da conexão do Nether.
2. Descoberta de Endpoints: Navegue até /endpoints.txt para encontrar uma lista de 200 possíveis endpoints ocultos.
3. Força Bruta: Um desses endpoints contém a flag, enquanto três outros retornam falsos positivos.
4. Domínio do Protocolo: Devido ao middleware UDP, uma requisição padrão do navegador pode falhar ao receber o corpo completo da resposta (apenas os cabeçalhos podem retornar antes que a conexão seja encerrada ou o tempo limite seja atingido).
5. Automação: Escreva um script (veja solve.py) para enviar requisições HTTP brutas sobre UDP para o alvo. O script deve iterar pelos endpoints e solicitar cada um repetidamente até que uma resposta completa (contendo um corpo) seja recebida.

Mitigação

• Garanta que tanto o frontend quanto o backend usem exatamente a mesma lógica para analisar os limites das requisições.
• Rejeite qualquer requisição com cabeçalhos de comprimento ambíguos ou caracteres ilegais no fluxo de cabeçalhos.
• Use bibliotecas HTTP/3 estabelecidas em vez de lógica personalizada de encaminhamento UDP para TCP.

Dicas

• Você já mapeou como o proxy frontend se comunica com o proxy backend?
• Verifique o protocolo em uso—o UDP não garante entrega!

Flag

CH4KR4X2{P0D5_bl0ckch41n_br34ch}

Hospedagem

Este desafio executa um servidor Flask na porta 1337 e udp_server.py na porta 40000.

Build:

sudo docker build -t huup .
sudo docker network create -d bridge huup

Executar:

sudo docker run -p 40011:40000/udp --detach --name huup --network huup huup:latest