Usando IA para encontrar bugs de autorização
Programas de bug bounty estão mudando. Alguns programas pararam de pagar recompensas. Outros cortaram os pagamentos em 80%. O motivo não é que a IA encontra bugs demais. O motivo é que a IA encontra bugs errados demais. As equipes de triagem estão se afogando em relatórios de baixa qualidade.
Neste cenário, a habilidade mais importante não é encontrar bugs. É provar que um bug não existe. Você deve encontrar os negativos corretos.
Eu utilizo um método de dois estágios para alvos de código disponível (source-available).
Estágio 1: Fan-out Use modelos de IA baratos para ler o código. Divida o alvo em pequenos pedaços. Peça ao modelo para encontrar invariantes quebradas. Procure por locais onde um objeto é carregado sem uma verificação de proprietário ou onde um controle de segurança é ignorado. Foque em alto recall. Espere muitos erros.
Estágio 2: Verificação Adversária Use um modelo caro, de alto raciocínio, para eliminar os candidatos. Assuma que cada candidato é refutado. Um candidato só sobrevive se você puder citar linhas específicas de código. Você deve provar que o caminho é alcançável e que nenhum outro controle o bloqueia.
O resultado mais valioso é uma lista de refutações. Essa lista constrói confiança com os triadores.
Eu testei o Ory Kratos, um servidor de identidade de código aberto. Analisei o fluxo de configurações. Esta área gerencia alterações de senha e atualizações de e-mail. Um único erro aqui leva ao sequestro de conta (account takeover).
O primeiro estágio encontrou um bug tentador. Na estratégia OIDC, um contêiner específico carece de um vínculo de identidade (identity binding). Se você procurasse apenas por verificações ausentes, reportaria isso como um bug de alta severidade.
Isso seria um erro.
O vínculo ausente não é explorável. O sistema obtém a identidade de destino de um cookie de sessão ativo ou de um token assinado. Os atributos do contêiner nunca se aplicam ao alvo de escrita real. O design se mantém.
Reportar isso desperdiçaria tempo e prejudicaria sua credibilidade. O valor que eu entreguei foi a confiança para não enviar um relatório.
Quando usei esse mesmo método em um alvo diferente, encontrei um bug real. Um ponto de entrada alternativo não possuía uma verificação de autorização que o caminho principal exigia. Um usuário revogado ainda poderia entrar por uma porta lateral. Este bug era de alto impacto e invisível para scanners padrão.
Os gatekeepers estão construindo muros contra o volume. Para ter sucesso, seu trabalho com IA deve ser rigoroso. Use a IA para ler mais código do que um humano consegue. Depois, use a IA para provar que você está errado antes de clicar em enviar.
Foque no sinal, não no volume.