hunt-mfa-bypass

⚠️ USO AUTORIZADO APENAS Esta habilidade é apenas para fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Porta de confirmação obrigatória Antes de executar qualquer comando que sonde, explore, altere, persista, extraia dados ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL, IP, conta ou recurso exato do alvo.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça apenas em modo de leitura e forneça orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Prioridade de Teste Autônomo

Tente contornar fluxos de trabalho antes de usar força bruta — eles são mais rápidos e têm maior probabilidade de sucesso.

Padrão 1 — Pular a etapa de MFA completamente (mais automatizável):

1. Faça login com credenciais válidas → receba um estado de sessão "pré-MFA"
2. Sem completar o MFA, acesse diretamente um recurso protegido (/dashboard, /api/me, /account/profile)
3. Se a resposta retornar dados do usuário → o MFA é aplicado apenas na interface do usuário, não no lado do servidor = Crítico

Padrão 2 — Replay de OTP (reutilizar um código consumido):

1. Complete um fluxo de MFA válido para obter um OTP funcional
2. Saia, faça login novamente com as mesmas credenciais
3. Envie o mesmo OTP novamente
4. Se aceito → o OTP não é invalidado após o uso

Padrão 3 — Enviar OTP obviamente errado, observar a resposta: Tente enviar 000000 ou 123456. Se a resposta for 200 ou retornar um token de sessão, a validação do OTP está quebrada ou é apenas do lado do cliente.

Padrão 4 — Validação parcial / incremental (oráculo de prefixo): Se um código completo adivinhado for rejeitado, teste se o servidor valida o OTP prefixo por prefixo em vez de tudo ou nada. Envie um código parcial curto e compare as respostas:

1. Envie um valor de 1 a 3 dígitos (por exemplo, otp=1, depois otp=12, …) — para um endpoint de verificação POST, o código vai no corpo da requisição, não na string de consulta da URL, ou o servidor lê um valor vazio.
2. Se um prefixo correto der uma resposta DIFERENTE de um incorreto (um sucesso/bandeira, uma mensagem distinta ou um comprimento/tempo diferente), o validador vaza a correção um pedaço de cada vez.
3. Percorra o código dígito por dígito: mantenha o prefixo que "responde corretamente", adicione 0–9, repita. Isso colapsa 10^6 tentativas de força bruta para ~10×N suposições (≤60 para um código de 6 dígitos) — muito viável em um teste limitado. Este é o caminho a seguir quando não há código vazado e nenhum caminho de pular/replay. Alguns aplicativos concedem sucesso em qualquer prefixo correto imediatamente (portanto, um único primeiro dígito correto pode vencer — varra otp=0,1,…,9 antes de desistir). CRÍTICO — permaneça em UMA sessão: reautenticar (POST /…/login novamente) regenera o OTP, descartando seu progresso de prefixo. Faça toda a varredura contra uma única sessão de MFA estabelecida; nunca faça login novamente entre as suposições.

Sobre força bruta completa: tentar forçar todas as 10^6 códigos é inviável em um teste limitado — mas o oráculo de prefixo acima (Padrão 4) geralmente o torna desnecessário. Tente força bruta completa apenas com evidências de que não há limite de taxa E um espaço de chave pequeno.

Prova: Um token de sessão ou dados de recurso protegido na resposta sem completar o MFA confirma o contorno.

19. CONTORNO DE MFA / 2FA

Classe de bug crescente — 7 padrões distintos. Paga Alto/Crítico quando permite ATO sem sessão prévia.

Padrão 1: Sem Limite de Taxa no OTP

# Test with ffuf — all 1M 6-digit codes
ffuf -u "https://target.com/api/verify-otp" \
  -X POST -H "Content-Type: application/json" \
  -H "Cookie: session=YOUR_SESSION" \
  -d '{"otp":"FUZZ"}' \
  -w <(seq -w 000000 999999) \
  -fc 400,429 -t 5
# -t 5 (slow down) — aggressive rates get 429 or ban

Padrão 2: OTP Não Invalidado Após Uso

1. Login → receive OTP "123456" → enter it → success
2. Logout → login again with same credentials
3. Try OTP "123456" again
4. If accepted → OTP never invalidated = ATO (attacker sniffs OTP once, reuses forever)

Padrão 3: Manipulação de Resposta

1. Enter wrong OTP → capture response in Burp
2. Change {"success":false} → {"success":true} (or 401 → 200)
3. Forward → if app proceeds → client-side only MFA check

Padrão 4: Pular Etapa de MFA (Contorno de Fluxo de Trabalho)

# Após inserir a senha, o aplicativo define um cookie "pré-mfa" → redireciona para /mfa

…