hunt-auth-bypass

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

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

1. Peça ao usuário para declarar a URL exata 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 somente leitura e forneça apenas orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Alvos Principais (Crown Jewel Targets)

A bypass de autenticação é consistentemente uma das classes de vulnerabilidade com maior recompensa em bug bounty, pois viola diretamente o controle de segurança mais fundamental. Alvos de alto valor incluem:

• Implementações de SSO/SAML em empresas de SaaS corporativo (integrações Slack, Okta, OneLogin) — pagamentos regularmente na faixa de US$ 5.000–US$ 25.000+
• Painéis de administração e portais de parceiros/internos — superfícies de administração separadas por subdomínio como partners.shopify.com, admin.company.com
• Integrações de plugins de autenticação de terceiros — plugins WordPress (OneLogin, WP-SAML-Auth), módulos Drupal SSO, qualquer CMS com autenticação plugável
• Endpoints XMLRPC no WordPress — frequentemente esquecidos, ignoram completamente os fluxos de autenticação padrão do WP
• Fluxos de callback OAuth — mau manuseio do parâmetro state, incompatibilidades de redirect_uri
• Camadas de autenticação de API — especialmente onde a autenticação foi adicionada posteriormente

Prioridade de ativos: Alvos com identidade federada (SAML, OAuth, OIDC) conectados a grandes populações de usuários. Portais de parceiros/revendedores são particularmente interessantes porque geralmente têm permissões elevadas e menos escrutínio de segurança do que o produto principal.

Falsificação de confiança de autoridade de certificado SSH (Git-hosting / plataformas corporativas)

Quando uma organização ou instância registra uma autoridade de certificado SSH, o certificado principals pode não ser vinculado no lado do servidor à identidade solicitante — um membro pode criar um certificado afirmando ser outro usuário e autenticar-se como ele (por exemplo, modificar o recurso de outro usuário com apenas sua URL). Adicione a confiança SSH-CA à lista de superfícies de autenticação em alvos de Git-hosting; nicho/específico da plataforma. Divulgado: reports/1901040.

Sinais de Superfície de Ataque

Padrões de URL para caçar:

/xmlrpc.php
/wp-login.php
/saml/
/sso/
/auth/saml/callback
/oauth/callback
/partners.*
/admin.*
/?wc-api=
/api/v*/auth
/login?redirect=
/accounts/login

Cabeçalhos de resposta sinalizando SSO:

X-Frame-Options: SAMEORIGIN (common on SSO portals)
Set-Cookie: SAMLResponse=
Location: https://idp.company.com/saml
WWW-Authenticate: Bearer realm="partners"

Padrões de JS indicando autenticação federada:

// Look for in page source
samlRequest
RelayState
SAMLResponse
onelogin
shibboleth
okta
passport.js authenticate

Sinais de stack de tecnologia:

• WordPress + qualquer plugin SSO → verifique XMLRPC separadamente
• Exposição da API do Shopify Partner → risco de escalonamento de privilégios entre locatários
• Qualquer aplicativo anunciando "SSO habilitado" ou "Login com [Enterprise IdP]"
• Subdomínios separados para admin/parceiro que compartilham cookies de sessão com o domínio principal
• Aplicações usando SimpleSAMLphp, ruby-saml, python-saml

Gatilhos de varredura passiva do Burp:

• SAMLResponse em qualquer corpo POST
• openid_connect ou id_token em respostas
• Domínios de cookie definidos como .company.com (wildcard)

Metodologia de Caça Passo a Passo

1. Mapear todos os pontos de entrada de autenticação

   • rastrear o alvo para cada superfície de login: login principal, login de administrador, login de API, portal de parceiros, endpoints de API móvel
   • verificar robots.txt, arquivos JS e a Wayback Machine para endpoints esquecidos como /xmlrpc.php

2. Identificar o mecanismo de autenticação por ponto de entrada

   • É baseado em formulário, SAML, OAuth, chave de API, token de sessão?
   • Para WordPress: sempre sondar /xmlrpc.php mesmo que o login principal seja protegido por SSO

3. Testar XMLRPC independentemente do SSO

   • Se o site usa SSO (por exemplo, OneLogin), envie manualmente POST para /xmlrpc.php
   • XMLRPC usa credenciais nativas do WordPress, não SSO — teste com system.listMethods primeiro, depois wp.getUsersBlogs

4. Enumerar implementação SAML

   • Capturar um SAMLResponse válido via Burp
   • Decodificar a carga Base64, inspecionar o XML

…