hunt-misc

⚠️ USO AUTORIZADO APENAS Esta habilidade destina-se apenas a 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 em, extraia dados de ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL exato do alvo, IP, conta ou recurso.
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 apenas orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Alvos Principais (Crown Jewel Targets)

Por que essa classe de vulnerabilidade compensa: Vulnerabilidades MISC abrangem falhas de controle de acesso, divulgação de informações, bugs de lógica de sessão/autenticação e má configuração — as categorias que consistentemente produzem os maiores pagamentos porque se mapeiam diretamente ao impacto nos negócios: exposição de dados, tomada de conta, escalonamento de privilégios e comprometimento de infraestrutura.

Alvos de maior valor:

• Plataformas SaaS com hierarquias de funções (Shopify, GitHub, GitLab) — qualquer limite entre proprietário/administrador/equipe/convidado é uma superfície de escalonamento de privilégios
• Fluxos de identidade/autenticação — links de convite, redefinição de senha, SAML SSO, escopos de token OAuth
• Sistemas multi-tenant — um tenant acessando dados de outro tenant
• APIs internas — endpoints LFS, ganchos pre-receive, GraphQL/REST interno que assume que o chamador é confiável
• Recursos de gerenciamento de domínio/DNS — controles de transferência, delegação de subdomínio
• Gerenciamento de tokens/credenciais — escopos de PAT, chaves de deploy, tokens de API armazenados em campos de configuração

Tipos de ativos que pagam mais:

• APIs do produto principal (não subdomínios de marketing)
• Edições empresariais/auto-hospedadas (GitHub Enterprise, GitLab EE)
• Sistemas de convite para parceiros/colaboradores
• Integrações de aplicativos OAuth e endpoints de webhook

Sinais da Superfície de Ataque

Padrões de URL para observar:

/admin/*/transfer
/invitations/*
/partners/*/accept
/api/v*/repos/*/lfs/*
/-/settings/integrations/sentry
/api/v*/user/installations
/hooks/pre-receive/*
/reset-password?token=
/auth/saml/callback
/api/v*/packages/pypi/*

Sinais de cabeçalho de resposta:

X-Request-Id (pitchfork/Rack — check for header injection)
X-Shopify-Shop-Api-Call-Limit
X-GitLab-*

Padrões de JS revelando superfícies internas:

// Look for hardcoded internal API paths
fetch('/internal/api/
graphql { installations(
"scope": [], // empty scopes on tokens
"permissions": {"contents": "read"} // minimal scope PATs

Sinais de stack de tecnologia:

• Middleware Ruby/Rack (risco de injeção CRLF em pitchfork)
• SAML SSO habilitado em instâncias empresariais
• Configurações de proxy/espelho PyPI (confusão de dependência)
• Campos de integração de rastreamento de erros Sentry (vetor de vazamento de SSRF/token)
• Sistemas de convite multi-função (parceiros, equipe, colaboradores)

Metodologia de Caça Passo a Passo

1. Mapear todos os limites de função/permissão — enumerar cada nível de função (proprietário → administrador → equipe → convidado → removido) e documentar o que cada função deve ver

   Disciplina de Marcadores: ao sondar limites de função injetando tokens / identificadores únicos em dados de teste por função, os marcadores DEVEM ser strings alfanuméricas aleatórias únicas (8+ caracteres, sem palavras em inglês, sem palavras-chave de protocolo). Marcadores ruins: test, marker, attacker, evil, admin, AAAA. Marcadores bons: cpmark987abc, x4hd2k9pq. Antes de reivindicar qualquer reflexão, pesquise a linha de base (resposta sem marcador) em busca do marcador — se ele aparecer naturalmente, altere seu marcador.

   Regra de Diferença de Corpo: uma reivindicação de bypass de privilégio requer uma diferença no CORPO da resposta, não apenas no código de status. 200 OK com corpo byte-a-byte idêntico à linha de base NÃO é um bypass. Sempre compare os corpos lado a lado antes de reivindicar o bypass. Reivindicações apenas por código de status são a categoria mais comum rejeitada como N/A em plataformas de bug-bounty.

2. Testar fluxos de convite de ponta a ponta — aceitar convites sem completar as etapas de verificação; modificar tokens de convite; testar se aceitar um convite como um usuário diferente concede acesso

3. Testar acesso pós-remoção — adicionar um usuário a um recurso, removê-lo e, em seguida, testar se a sessão/token dele ainda concede acesso (especialmente após a remoção da empresa/organização)

…