O que Aprendemos sobre a Segurança de Segredos no AppSec Village na DEF CON 32

Se você cresceu nos EUA, é provável que tenha uma memória de ir a um acampamento de verão. Mesmo se você não frequentou um, a experiência de acampamento de se afastar de casa, aprender todo o tipo de artes e ofícios, conhecer novos melhores amigos e embarcar em aventuras memoráveis está integrado à população e mídia. Todo Agosto, o maior acampamento de verão de hackers do mundo acontece no calor de Las Vegas. Este ano marcou a trigésima segunda iteração do DEF CON.

É difícil explicar o DEF CON sem o experiê-lo. Sim, há tracks de palestras, oficinas oficiais e vários capture-the-flags (CTFs), mas existe muito mais. Nenhuma outra conferência contém tantas subconferências e eventos dirigidos por comunidades. Até mesmo os participantes que já estão há anos dizem que ainda não pensam ter experimentado tudo que está disponível.

Embora não haja número oficial divulgado pelos organizadores, eventos anteriores têm variavido de 25.000 a 30.000 participantes. Cada e cada participante traz consigo um amor por tecnologia e muitos conhecimentos para compartilhar. As hallways estão cheias de pessoas hackando hardware, escrevendo software, fazendo música, compartilhando seláculos e fazendo todo o divertimento do DEF CON acontecer.

As Vilas

Houve 33 vilas dentro do DEF CON 32. Essas abrangem uma ampla diversidade de interesses,从a pirataria aeroespacial, Engenharia Social e Desinformação até Equipes Vermelhas e AppSec. Cada vila é organizada independentemente e oferece um conjunto único de palestras, workshops e atividades práticas para que os participantes interajam com a área específica de seu interesse.

Vila AppSec foi um espaço valioso dentro da comunidade maior de piratas e de segurança que se concentra na defesa das aplicações que movimentam todas as nossas vidas. O autor deste texto foi uma das pessoas afortunadas que ajudaram a organizar e gerenciar a Vila AppSec 2024.

Spot the Secrets

Voltando à Vila AppSec na RSA Conference 2024, GitGuardian revelou o Spot the Secrets, um jogo de cartas que simula a experiência de revisão de código manual para encontrar credenciais de texto simples. Os jogadores são solicitados a competir para encontrar todas as chaves de API ocultas, senhas e outros segredos de texto simples que os atacantes poderiam usar para obter acesso adicional a uma coleção de amostras de código, tickets Jira, arquivos de log e mensagens de Slack.

Spot the Secrets na Vila AppSec, editado para atender às regras de fotografia do DEF CON

No DEF CON, durante 2 dias, mais de 120 pessoas passaram pelo nosso POD no AppSec Village para experimentar este exercício em primeira mão. Até mesmo tivemos uma tabela de classificação onde os jogadores mais rápidos, que cometeram menos erros, ganharam prêmios de mercadoria especial.

As Perguntas de Segurança Secretas Mais Comuns

Ao começarmos a examinar as cartas que contêm o código, tivemos uma ampla variedade de perguntas. Acreditamos que seria benéfico partilhar algumas dessas perguntas, caso você ainda não tenha ouvido as respostas a esses questionamentos.

Aqui estão as 11 perguntas mais comuns que ouvimos e as nossas respostas.

1. O que é exatamente um commit?

Um commit é uma unidade de trabalho no Git, o sistema de controle de versão usado por mais de 97% dos desenvolvedores globais. É uma foto de snapshot do sistema de arquivos em um determinado momento de tempo, abrangendo todo o trabalho que o desenvolvedor fez desde o último commit. Se você colocar commit em cima do outro, você obtém a história do Git, que permite que você examine cada mudança feita incrementalmente na vida do código-fonte. Um dos desafios de segurança secreta de usar o Git é que a história é um registro permanente compartilhado. Se um segredo for adicionado em um commit e removido no commit seguinte, o commit com o segredo ainda é preservado.

2. Como você pode saber se algo é um segredo?

Um segredo é qualquer credencial que dá acesso direto the um sistema ou dados. Estes podem assumir a forma de chaves API, senhas, certificados e tokens, por nomes. Parte do motivo para eles serem difíceis de localizar é que são usados de várias maneiras dentro do código e a partir da linha de comando. Por exemplo, dentro de um arquivo de configuração, uma variável específica pode ser definida para uma chave API. Mas para sistemas como o Slack, o token API está embutido na URL mesma, o que significa que você precisaria estar familiarizado com esse sistema para saber que é um segredo.

Muitos sistemas usam números longos e únicos em suas URLs de interface de usuário, que podem se parecer muito com tokens em linha. As URLs do Figma, por exemplo, pode parecer conter uma string codificada em base64 no caminho. No entanto, se você acompanhar um link aleatório do Figma, você encontrará uma tela de login, já que você precisa ser um usuário autenticado para se conectar a essa página. Como isso não concede acesso ao sistema automaticamente, mas sim apenas identifica a localização da página, um atacante sem um ponto de apoio no Figma retornaria o erro “Sem Acesso” e seguiria em frente. Este é outro motivo para adotar ferramentas para identificar segredos, já que existem plataformas que conseguem rapidamente diferenciar entre uma URL que contém um token de autorização e uma que apenas parece que talvez o faça.

3. O que Significa Válido?

“Válido”, no nosso uso, significa que um credencial em particular ainda funciona para conceder acesso ao sistema ou dados relacionados. Se encontrado por um atacante, um segredo válido poderia ser imediatamente usado. Embora segredos não válidos possam dar a um atacante insights sobre a arquitetura global e sistemas interconectados, apenas segredos válidos oferecem a eles um caminho direto para essas fontes. Esses tipos de movimentos laterais podem ser difíceis de detectar, também.

4. Como é que eu sou suposto saber quais segredos são os certos para procurar?

A melhor resposta é encontrar e remover qualquer segredo válido. No entanto, como o Spot the Secrets prova, este é um problema difícil de resolver sem as ferramentas certas. Revisões de código manuais ou ferramentas que dependem apenas de correspondências de padrões simples podem você gastar tempo corrigindo segredos já invalidados em vez de se concentrar em segredos válidos. Chaves expiradas não representam muito perigo, portanto, esforços para eliminá-las devem ter prioridade menor que os credenciais válidos que você descobre.

5. Qual a diferença entre um segredo e apenas um código mal escrito?

Atacantes provavelmente não estão lendo seu código na maioria do tempo; eles estão procurando por maneiras específicas de ganhar acesso mais amplo o quanto antes. Código mal escrito pode conter muitas vulnerabilidades que um atacante pode usar, especialmente em configurações de “Infraestrutura como Código”. No entanto, a exploração desses defeitos requer que o atacante tire o tempo para entender o defeito e executar um ataque específico contra esses problemas, em vez de apenas usar credenciais em texto claro.

Nomes de variáveis e nomes de usuário podem ser usados como parte de um ataque mais elaborado. Por exemplo, nomes de usuário e e-mails encontrados no código podem ser usados em ataques de spray de senhas ou tentativas de força bruta, mas estes são muito mais fáceis de detectar do que o uso direto de segredos e consumem muito tempo do atacante.

6. Mas O Que Eu Fiz Com Isso Uma Vez que Encontrei um Segredo?

Primeiro, pare e respire. Isso acontece com os melhores de nós, então não se preocupe muito se você encontrou um segredo divulgado. É bom agir com urgência, mas não desesperar e revogar um segredo encontrado sem saber o que acontecerá. Isso pode causar muitos outros problemas.

Nós recomendamos seguir o caminho do:

1. Entender o que o segredo abre.
2. Descobrir quão crítico qualquer dado associado ou sistema é.
3. Verificar seus logs para o uso não autorizado do segredo.
4. Determinar se qualquer acesso de dados ou serviço foi divulgado.
5. Achar o que quebrará quando você rotacionar o segredo.
6. Rotacionar o segredo e armazenar as novas credenciais com segurança.
7. Corrigir quaisquer fluxos de trabalho quebrados ou implantações de produção.
8. Revisar o incidente e criar um plano de ação para evitar a divulgação de segredos adicionais.

Leia mais sobre o processo de remediação no artigo, “O que Fazer Se Você Exposi um Segredo: Como Manter-se Calmo e Responder a um Incidente“.

7. A Minha Equipe Sempre Reescreve a História do Git Quando um Segredo é Descoberto. É Tudo O que Precisamos Fazer?

Infelizmente, não. Enquanto nós adoramos a etapa de limpeza do Git no processo de remediação, é verdadeiramente a última etapa e é vista por muitas organizações como opcional. Recomendamos que qualquer segredo exposto como texto claro seja rotacionado (veja o link acima para conselhos de processo de remediação).

8. Eu Simplesmente Remove o Repo do Público. Isso Não é Oficial?

Honestamente, nós queríamos que isso fosse o caso, mas infelizmente para todos nós, assim que é exposto publicamente no GitHub, deve sempre ser considerado comprometido. Os Scans do GitGuardian verificam cada novo commit e evento isPublic que acontece na API pública do GitHub.

Isso é o que nós usamos para construir nosso relatório anual Estado da Expansão de Segredos e é a base para o oferecimento de Monitoramento Público do GitGuardian. Enquanto nossos objetivos são alertar os committers que eles fizeram algo potencialmente perigoso, nós não somos os únicos atores a monitorar essa API pública. Você deve sempre assumir que há uma cópia de qualquer código ou arquivos que você já publicou publicamente, feita por alguém que você não conhece, e armazenada em algum lugar que você não sabe de. Nós sempre recomendamos a rotação de qualquer segredo potencialmente exposto.

9. Porque é um Problema ter Falsos Positivos?

No nosso exercício Encontre os Segredos, pedimos aos usuários que encontrem todos os segredos colocados dentro de 100 possíveis commits, Jira, Slack e cartões de Log, aplicando uma penalidade de tempo por cada falso positivo. qualquer cartão onde o jogador erroneamente achou que o cartão continha um segredo quando não o fez teria que ser multado em 10 segundos por cada erro.

Enquanto no contexto limitado do exercício, pode parecer bom ser muito cauteloso e marcar coisas que não contêm segredos, na verdade, isso é um desperdício de tempo valioso, tanto para você, o relator, quanto para qualquer pessoa que está designada para trabalhar em uma solução.

Qualquer ferramenta ou processo que relata muitos falsos positivos leva à fatiga de alerta. Os usuários são inundados de alertas e começam a ignorá-los. Isto leva à desconfiança das ferramentas e ao uso inconsistente. Também pode atrapalhar o processo de remediação global e significar que alguns segredos verdadeiros relatados não são cuidados a tempo de tempo.

10. O que a Descrição do Arquivo Tem a Ver com a Identificação de um Segredo?

Bem, simplesmente: contexto. Segredos genéricos podem ser particularmente difíceis de encontrar através de correspondência de padrões sozinha. Se houver uma cadeia longa em um arquivo de marcador de revisão, nossos achados apontam para uma probabilidade alta de que seja uma senha de exemplo, portanto, provavelmente não precisaria lidar com isso. Caso contrário, se a mesma cadeia aparece depois da string password= em um arquivo chamado project.env, então há uma chance muito maior de ter um segredo real nas mãos.

O nome do arquivo é apenas um dos elementos que consideramos com Pre- e Pós-Validação no Motor de Detecção de Segredos GitGuardian e é um dos fatores que nos ajudam a eliminar falsos positivos internamente à plataforma FP remover.

11. As pessoas realmente fazem revisões de código manual para encontrar segredos?

Sim. Um total de 27% dos decisores de tecnologia da informação que nós questionamos disseram que eles dependem de revisões de código manual para corrigir a expansão de segredos, mesmo que 75% tenham dito que foram afetados por uma divulgação de segredo.

O Spot the Secrets foi projetado para mostrar os problemas de confiar em humanos para identificar estes problemas. As máquinas são muito melhores em identificar padrões em milhares ou milhões de linhas de código.

Aprender juntos é o que o DEF CON é sobre

Nós aprendemos muitas lições diferentes no DEF CON, incluindo manter-nos hidratados, conseguir pelo menos algumas horas de sono por noite e manter-nos dentro quando for acima de 110°F/43°C fora.

Havia tantas Palestras excelentes no programa; não podemos esperar para as gravações serem disponibilizadas para revisitar o conteúdo que perdemos enquanto ajudávamos as pessoas a aprender sobre a Expansão de Segredos. Ao longo do caminho, nós aprendemos muito sobre como as pessoas da segurança, desenvolvedores e pessoas em geral olham para este problema e pensam nas soluções. Na GitGuardian, esperamos incorporar essas lições para tornar a resolução deste problema mais acessível e fácil para todos nós.

Se você nunca considerou ir ao DEF CON, nós recomendamos fortemente que você o faça, mesmo que para nenhum outro motivo que para participar no AppSec Village e encontrar sua tribo no acampamento de verão de hackers.