Este artigo foi escrito em colaboração com Zach Rice e Joe Leon, ambos da Aikido .
tl;dr Algumas credenciais destinam-se a ser públicas, mas os scanners de segredos continuam a identificá-las como secrets genéricos. Criámos regras de supressão para as mais comuns e reduzimos os falsos positivos em cerca de 2%. Estas regras estão agora incluídas por predefinição no Betterleaks.
Secrets baseiam-se em expressões regulares. Cada padrão identifica um tipo específico de credencial, como uma chave de acesso secreta da AWS, um PAT do GitHub ou um token do Stripe. Assim que o scanner identifica um potencial segredo, realiza uma verificação de validade, por exemplo, enviando um pedido HTTP para verificar se a credencial está ativa.
Este fluxo de trabalho falha quando os scanners de segredos tentam identificar secrets genéricos. secrets genéricos secrets as chaves de API e as credenciais que não possuem uma assinatura única ou conhecida. Os scanners podem ainda utilizar uma expressão regular para os detetar, mas, em vez de procurarem corresponder a um formato de credencial conhecido, utilizam um padrão genérico para recolher tudo o que pareça poder ser um segredo.
Reduzir o ruído na secrets e o problema com as expressões regulares
É bastante fácil escrever uma expressão regular sofisticada para identificar cadeias de caracteres no código (e noutros locais) que se assemelhem a secrets. No entanto, sem uma verificação de validade predefinida, o scanner não consegue determinar com certeza se um segredo genérico é, de facto, um segredo ativo.
Esta abordagem obriga os utilizadores a filtrar manualmente os falsos positivos. Mas isso não é nada divertido. Por isso, ao longo dos próximos meses, iremos lançar uma série de camadas de redução de ruído:
- Filtragem com base na eficiência dos tokens (última publicação)
- Lista de credenciais a excluir da publicação (esta publicação)
- secrets públicos
- Divisão das regras genéricas em dois tipos: tokens e nomes de utilizador/palavras-passe
- Triagem assistida por ML
Queremos seguir esta sequência específica porque pretendemos eliminar o maior número possível de falsos positivos com o menor custo possível e, em seguida, utilizar operações de ML mais dispendiosas para a ambiguidade remanescente. Nunca será perfeito, mas acreditamos secrets genéricos secrets a maior oportunidade na secrets . É o melhor ponto de partida para os investigadores descobrirem novos achados e para os defensores se anteciparem aos autores de ameaças. O objetivo desta série é tornar as regras predefinidas do Betterleaks suficientemente boas para permitir que investigadores e analistas classifiquem resultados de segredos genéricos em grande escala.
Por que razão algumas chaves são consideradas chaves publicáveis (não tão secretas)
Muitos fornecedores de SaaS e de serviços na nuvem criam credenciais para os utilizadores que foram concebidas para serem públicas. A Stripe, a empresa de processamento de pagamentos, disponibiliza aos utilizadores vários tipos de chaves, incluindo uma «chave API publicável». Estas chaves foram concebidas para serem «inseridas no código do front-end».
Uma regra genérica de deteção de segredos provavelmente identificaria isto como um possível segredo. Tem uma entropia elevada, está localizado perto de palavras-chave como «api_key» e, de um modo geral, parece uma credencial. Mas não é um segredo propriamente dito. Destina-se a ser público e não é algo que um investigador ou analista deva perder tempo a analisar manualmente.
Por isso, criámos uma expressão regular para remover este tipo de chave dos resultados genéricos de segredos do Betterleak.
Mas o Stripe é apenas um tipo de chave. Precisávamos de ampliar este processo. Investigámos os tipos de credenciais «públicas por conceção» mais populares e criámos manualmente assinaturas de deteção para cada um deles. Sim, manualmente. A IA revelou-se surpreendentemente inútil para esta tarefa.
Reduzir as taxas de falsos positivos entre secrets genéricos
Depois de horas a adicionar manualmente estas expressões, quisemos verificar se valia a pena. Para avaliar a diferença, descarregámos 100 GB do Common Crawl e analisámos esses dados duas vezes com o Betterleaks. Uma vez com as novas assinaturas e outra sem elas.
As novas assinaturas de credenciais publicáveis reduziram os falsos positivos em 2,37%. No nosso conjunto de dados, isso significou menos 27 886 secrets rever manualmente.
Custa cerca de 5% mais tempo de análise, mas evitar tantos falsos positivos compensa bem.
A sua taxa de redução irá variar consoante os dados que analisar. O Common Crawl concentra-se principalmente no HTML e no JavaScript do front-end, precisamente onde se encontram as credenciais publicáveis, pelo que é provável que isso exagere os nossos resultados. Seja como for, cada chave publicável que o filtro remove é uma que um investigador ou analista nunca terá de analisar.
Público nem sempre significa seguro
O desafio desta abordagem reside no facto de as credenciais que podem ser publicadas não significarem necessariamente que não haja risco. Cada tipo de chave requer uma análise manual da sua estrutura e do acesso que lhe é concedido no contexto da plataforma SaaS. Ao elaborar esta lista, deparámo-nos com cinco casos que merecem ser analisados, especialmente para quem estiver a pensar em enviar um PR para adicionar mais (por favor, façam-no!).
Forma única: fácil
Isto é fácil. A credencial publicável tem uma forma única e inconfundível. Escrevemos uma expressão regular única e temos a certeza de que isso não excluirá quaisquer secrets genéricos potencialmente válidos.
Sem forma específica: depende do contexto
Trata-se de cadeias de caracteres que podem, literalmente, surgir em qualquer lugar. Pode ser um UUID ou simplesmente quaisquer 32 caracteres hexadecimais. O formato, por si só, não identifica esta cadeia de caracteres como um tipo de credencial publicável. Nestes casos, baseamo-nos numa palavra-chave próxima que confirme que pertence a uma determinada plataforma SaaS ou a um determinado fornecedor de serviços na nuvem.
Esta abordagem não é nova. Fazemos isto constantemente com credenciais secretas.
Tem a mesma forma que um segredo: precisa de uma verificação de validade
Isto é complicado. Alguns fornecedores de SaaS decidem criar credenciais secretas e publicáveis com exatamente o mesmo formato. Sinceramente, preferíamos que não o fizessem. Isso dificulta a deteção de credenciais secretas e confunde os utilizadores. Mas deparámo-nos com muitos casos destes.
Nestes casos, a única forma de remover com segurança o tipo de chave passível de sanções é adicionar uma assinatura de deteção (através de um pedido de verificação de atividade HTTP) para a credencial secreta.
Uma vez que as chaves publicáveis e secretas têm a mesma forma, a assinatura de deteção do tipo de chave secreta identificaria ambas e, após uma verificação de validade, determinaria que a chave publicável não é secreta, descartando-a.
Vulnerável apenas se estiver mal configurado: necessita de uma verificação de atividade
Existem alguns tipos de chaves que os fornecedores de SaaS e de serviços na nuvem geram, em que, dependendo de o utilizador ter adicionado uma permissão específica, a chave pode ser considerada sensível ou isenta de risco. Já escrevi bastante sobre as chaves da API do Google e a sua capacidade de aceder ao Gemini. Esse é um dos casos. Mas já observei este padrão com as chaves da Algolia e outras.
Nestas situações, o melhor procedimento a seguir é semelhante ao que adotamos quando detetamos conflitos de formato entre chaves de publicação e chaves secretas: enviamos uma verificação de atividade para determinar se é possível aceder a qualquer informação sensível.
Credenciais de teste: requer triagem manual
Algumas plataformas SaaS, como o Stripe, disponibilizam aos utilizadores um ambiente de teste ou «sandbox». Inicialmente, considerámos excluir categoricamente estes resultados dos resultados gerais da deteção de segredos.
No entanto, ao analisar mais detalhadamente, tornou-se claro que algumas organizações introduzem dados de produção nos seus ambientes de teste. E embora uma chave Stripe de sandbox que tenha sido alvo de fuga de informação possa não ser capaz de enviar milhares de dólares para a conta de um agente malicioso, pode proporcionar a esse agente acesso a informações de identificação pessoal (PII) dos clientes ou a outros dados internos importantes. Uma vez que não podemos saber se uma credencial de teste proporciona acesso a dados internos sensíveis, mantemos estes resultados nas conclusões e recorremos à triagem manual.
Resolver secrets genéricos, passo a passo
A deteção genérica de segredos é um problema de filtragem, e a filtragem é alcançada através de uma série de pequenos avanços que se acumulam uns sobre os outros. Começamos por eliminar aquilo de que temos a certeza. A nossa esperança é que algumas destas pequenas alterações permitam uma deteção genérica de segredos eficaz em grande escala.
A versão atual do Betterleaks filtra, por predefinição, as chaves que podem ser publicadas dos resultados genéricos. Experimenta!
