Este artigo foi coescrito por Zach Rice e Joe Leon, ambos na Aikido Security.
tl;dr Algumas credenciais são destinadas a serem públicas, mas scanners de Secrets ainda as sinalizam como generic secrets. Escrevemos regras de supressão para as mais comuns e reduzimos os falsos positivos em aproximadamente 2%. Essas regras agora são distribuídas por padrão no Betterleaks.
Scanners de Secrets são baseados em expressões regulares. Cada padrão visa um tipo específico de credencial, como uma chave de acesso secreta da AWS, um PAT do GitHub ou um token do Stripe. Uma vez que o scanner identifica um potencial secret, ele realiza uma checagem de liveness, por exemplo, enviando uma requisição HTTP para verificar se a credencial está ativa.
Este fluxo de trabalho falha quando scanners de Secrets tentam identificar generic secrets. Generic secrets são as chaves de API e credenciais que não possuem uma assinatura única ou conhecida. Os scanners ainda podem usar uma expressão regular para encontrá-los, mas em vez de procurar corresponder a um formato de credencial conhecido, ele usa um padrão genérico para capturar qualquer coisa que pareça ser um secret.
Reduzindo o ruído na varredura de Secrets e o problema com expressões regulares
É relativamente fácil escrever uma expressão regular sofisticada para identificar strings no código (e em outros lugares) que se parecem com Secrets. Mas, sem uma verificação de vivacidade predefinida, o scanner não pode afirmar com certeza se um Secret genérico é realmente um Secret ativo.
Essa abordagem exige que os usuários filtrem manualmente os falsos positivos. Mas isso não é divertido. Por isso, nos próximos meses, lançaremos uma série de camadas de redução de ruído:
- Filtragem de eficiência de tokens (última publicação)
- Lista de negação de credenciais publicáveis (esta publicação)
- Lista de negação de Secrets públicos
- Dividindo regras genéricas em dois tipos: tokens e nomes de usuário/senhas
- Triagem assistida por ML
Queremos fazer as coisas nesta sequência particular porque estamos procurando remover o maior número possível de falsos positivos da forma mais barata, e então usar operações de ML caras para a ambiguidade restante. Nunca será perfeito, mas acreditamos que os generic secrets são onde reside a maior oportunidade na varredura de Secrets. É o melhor lugar para pesquisadores descobrirem novas descobertas e para defensores superarem os agentes de ameaça. O objetivo desta série é tornar as regras padrão do Betterleaks boas o suficiente para permitir que pesquisadores e analistas triem resultados de generic secrets em escala.
Por que algumas chaves são consideradas publicáveis (não tão secretas)
Muitos provedores de SaaS e Cloud criam credenciais para usuários que são projetadas para serem públicas. A Stripe, o processador de pagamentos, oferece aos usuários múltiplos tipos de chave, incluindo uma "chave de API publicável". Essas chaves são projetadas para serem "colocadas no código de front-end".
Uma regra de detecção de Secret genérico provavelmente identificaria isso como um Secret candidato. Possui alta entropia, está localizado perto de palavras-chave como "api_key" e, de modo geral, parece uma credencial. Mas não é um Secret real. É destinado a ser público e não é algo que um pesquisador ou analista deveria perder tempo revisando manualmente.
Então, escrevemos uma expressão regular para remover este tipo de chave dos resultados de Secrets genéricos do Betterleaks.
Mas a Stripe é apenas um tipo de chave. Precisávamos escalar este processo. Pesquisamos os tipos de credenciais públicas por design mais populares e criamos manualmente assinaturas de detecção para cada um. Sim, manualmente. A IA foi surpreendentemente inútil para esta tarefa.
Reduzindo as taxas de falsos positivos entre generic secrets
Após horas adicionando manualmente essas expressões, queríamos ver se valia a pena. Para medir a mudança, baixamos 100GB do Common Crawl e o escaneamos duas vezes com o Betterleaks. Uma vez com as novas assinaturas, uma vez sem.
As novas assinaturas de credenciais publicáveis reduziram os falsos positivos em 2,37%. Em nosso conjunto de dados, isso representou 27.886 Secrets a menos para revisar manualmente.
Custa cerca de 5% a mais de tempo de varredura, mas evitar tantos falsos positivos vale muito a pena.
Sua taxa de redução variará com os dados que você varrer. O Common Crawl tende para HTML e JavaScript de front-end, exatamente onde as credenciais publicáveis residem, então isso provavelmente infla nossos resultados. De qualquer forma, cada chave publicável que o filtro remove é uma que um pesquisador ou analista nunca terá que triar.
Público nem sempre significa seguro
O desafio de adotar essa abordagem é que credenciais publicáveis não significam necessariamente que não há risco. Cada tipo de chave requer uma revisão manual da forma da chave e do acesso concedido a ela dentro do contexto da plataforma SaaS. Ao construir esta lista, encontramos cinco casos que valem a pena revisar, especialmente para qualquer pessoa que esteja considerando enviar um PR para adicionar mais (por favor, faça!).
Formato único: fácil
Estes são fáceis. A credencial publicável tem um formato único e inconfundível. Escrevemos uma expressão regular única e estamos confiantes de que isso não excluirá quaisquer Secrets genéricos potencialmente válidos.
Sem formato único: precisa de contexto
Estas são strings que literalmente poderiam aparecer em qualquer lugar. Talvez seja um UUID, ou talvez apenas 32 caracteres hexadecimais. O formato por si só não identifica esta string como um tipo de credencial publicável. Nestes casos, contamos com uma palavra-chave próxima que confirme que ela pertence a uma plataforma SaaS ou provedor Cloud específico.
Esta abordagem não é nova. Fazemos isso o tempo todo para credenciais de Secrets.
Mesmo formato que um secret: precisa de uma checagem de liveness
Estes são difíceis. Alguns provedores de SaaS decidem criar credenciais secretas e publicáveis com o mesmo formato exato. Honestamente, gostaríamos que não fizessem isso. Isso torna a detecção de secrets mais difícil e confunde os usuários. Mas encontramos muitos desses.
Nestes casos, a única maneira de remover com segurança o tipo de chave publicável é adicionar uma assinatura de detecção (com uma requisição de verificação de atividade HTTP) para a credencial de Secret.
Como as chaves publicáveis e de Secrets têm o mesmo formato, a assinatura de detecção do tipo de chave de Secret detectaria ambas e, após uma verificação de atividade, determinaria que a chave publicável não é um Secret e a descartaria.
Sensível apenas se mal configurado: precisa de uma checagem de liveness
Existem alguns tipos de chave que provedores de SaaS e Cloud criam onde, dependendo se um usuário adicionou uma permissão específica, a chave pode ser sensível ou sem risco. Escrevi bastante sobre chaves de API do Google e sua capacidade de acessar o Gemini. Esse é um caso. Mas vi esse padrão com chaves da Algolia e outras.
Nessas situações, o melhor caminho a seguir é semelhante a quando vemos colisões de formato entre chaves publicáveis e secretas: enviamos uma checagem de liveness para determinar se ela pode acessar algo sensível.
Credenciais de teste: precisam de triagem manual
Algumas plataformas SaaS, como a Stripe, fornecem aos usuários um ambiente de teste ou sandbox. A princípio, consideramos remover categoricamente esses resultados dos resultados de detecção de Secrets genéricos.
No entanto, em uma análise mais detalhada, ficou claro que algumas organizações colocam dados de produção em seus ambientes de teste. E embora uma chave Stripe de sandbox vazada possa não ser capaz de enviar milhares de dólares para a conta de um agente de ameaças, ela pode fornecer a um agente de ameaças acesso a PII do cliente ou outros dados internos importantes. Como não podemos saber se uma credencial de teste fornece acesso a dados internos sensíveis, deixamos esses resultados nos achados e contamos com a triagem manual.
Corrigindo a detecção de generic secrets um passo de cada vez
A detecção de Secrets genéricos é um problema de filtragem, e a filtragem é vencida por uma série de pequenas vitórias empilhadas umas sobre as outras. Estamos começando por remover o que temos certeza. Nossa esperança é que algumas dessas pequenas mudanças permitam uma detecção eficaz de Secrets genéricos em escala.
A versão atual do Betterleaks filtra chaves publicáveis dos resultados genéricos por padrão. Experimente!
