O que Aprendemos Sobre 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 campo de férias. Mesmo se você não frequentou um, a experiência de férias de ir longe 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 campo de férias para hackers do mundo acontece no calor de Las Vegas. Este ano marcou a trigésima segunda iteração de DEF CON.

É difícil explicar o DEF CON sem experiência. 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 liderados pela comunidade. Até mesmo os participantes que já estão há anos dizem que ainda não pensam ter tido tudo que a oferece.

Embora não haja número oficial divulgado pelos organizadores, eventos anteriores têm variado de 25.000-30.000 participantes. Cada e todos os participantes trazem com eles um amor por tecnologia e muito conhecimento para compartilhar. As hallways estão cheias de pessoas acessando hardware, escrevendo software, tocando música, compartilhando stickers e fazendo todo o divertimento acontecer no DEF CON.

As Villages

Havia 33 vilarejos dentro do DEF CON 32. Estes abrangem uma ampla diversidade de interesses,从a pirataria espacial, Engenharia Social e Desinformação até Equipes Vermelhas e Aplicações de Segurança. Cada vilarejo é organizado 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.

Vilarejo de Aplicações de Segurança era um espaço valioso dentro da comunidade maior de hacking e de segurança que se concentra na defesa das aplicações que movem todas as nossas vidas. O autor deste texto foi uma das pessoas afortunadas que ajudaram a organizar e a gerenciar o Vilarejo de Aplicações de Segurança de 2024.

Encontre os Segredos

Voltando ao Vilarejo de Aplicações de Segurança na RSA Conference de 2024, o GitGuardian revelou o Encontre os Segredos, um jogo de cartas que simula a experiência de revisão de código manual para encontrar credenciais em texto claro. Os jogadores são solicitados a competir para encontrar todas as chaves de API ocultas, senhas e outros segredos em texto claro que os atacantes poderiam usar para obter acesso adicional a uma coleção de amostras de código, tickets do Jira, arquivos de log e mensagens do Slack.

Encontre os Segredos no Vilarejo de Aplicações de Segurança, editado para atender às regras de fotografia do DEF CON

No DEF CON, em dois dias, mais de 120 pessoas passaram pelo nosso POD no AppSec Village para experimentar pessoalmente este exercício. Até mesmo tivemos uma tabela de classificação onde os jogadores mais rápidos, que fizeram menos erros, ganharam prêmios demergencial especiais.

Perguntas Mais Comuns sobre Segredos de Segurança

Assim que as pessoas começaram a examinar as cartas com o código, nós 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 estas preocupações.

Aqui estão as 11 perguntas mais comuns que ouvimos e 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 momento dado, abrangendo todo o trabalho que o desenvolvedor fez desde o último commit. Se você juntar commits um atrás do outro, você obtém a história do Git, que permite que você examine cada mudança feita incrementamente na vida do código-fonte. Um dos desafios de segurança secretos de usar o Git é que a história é um registro permanente compartilhado. Se um segredo é 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 a 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 detectar é que são usados de várias formas dentro do código e 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 do usuário, que podem se parecer muito com tokens embutidos. Por exemplo, as URLs do Figma podem parecer conter uma string codificada em base64 no caminho. No entanto, se você acompanhar um link de Figma aleatório, você encontrará uma tela de login, já que é necessário ser um usuário autenticado para se conectar a essa página. Como isso não concede acesso ao sistema automaticamente, mas apenas identifica a localização da página, um atacante sem foothold no Figma retornaria o erro “Sem Acesso” e seguiria em frente. Essa é outra razão para abraçar ferramentas para identificar segredos, já que existem plataformas que podem rapidamente diferenciar entre uma URL que contém um token de autorização e uma que apenas parece ter.

3. O que Significa Válido?

“Válido”, no contexto de nosso uso, significa que um credencial 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 na arquitetura global e sistemas interconectados, apenas segredos válidos oferecem a eles um caminho direto para aqueles recursos. Esses tipos de movimentos laterais podem ser difíceis de detectar, além disso.

4. Como é que eu devo 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 te levar a gastar tempo corrigindo segredos já invalidados em vez de se concentrar em segredos válidos. Chaves expiradas não representam muito risco, portanto, esforços para eliminá-las devem ter uma 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?

Os atacantes provavelmente não estão lendo seu código na maioria do tempo; eles estão escaneando por maneiras específicas de obter 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, explorar esses defeitos requer que o atacante take o tempo para entender o defeito e executar um ataque específico contra essas questões, em vez de simplesmente usar credenciais em texto claro.

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 esses são muito mais fáceis de detectar do que o uso direto de segredos e demoram muito tempo para o atacante.

6. Mas O que Eu faço Com Isso Uma vez que Encontro 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 fique em pânico e revogue 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 desbloqueia.
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 algum 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 deployments de produção.
8. Revisar o incidente e criar um plano de ação para evitar futuras divulgações de segredos.

Leia mais sobre o processo de remediação no artigo, “O que Fazer Se Você Exposi um Segredo: Como Manter Calma 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. Embora nós adoramos a etapa de limpeza do Git no processo de remediação, é honestamente a última etapa e é vista por muitas organizações como opcional. Recomendamos que você rodeia qualquer segredo exposto como texto simples (veja o link acima para conselhos de processo de remediação).

8. Eu simplesmente removo o repositório do público. Isso não é o suficiente?

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

É assim que nós construímos nosso relatório anual Estado da Descontrolada de Segredos e é a base para a oferta de Monitoramento Público GitGuardian. Enquanto nossos fins 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 existe 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. Nós sempre recomendamos que você rodeie qualquer segredo potencialmente exposto.

9. Por que os falso positivos são um problema?

Em nosso exercício Spot the Secrets, nós 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 no qual o jogador pensou que o cartão continha um segredo quando não tinha, incidiria uma penalidade de 10 segundos por erro.

Enquanto no contexto limitado deste exercício, pode parecer bom ter muito cuidado e marcar coisas que não contêm segredos, na realidade, isso é um desperdício de tempo valioso, tanto para você, o relator, quanto para qualquer pessoa que está encarregada de trabalhar na solução.

Qualquer ferramenta ou processo que relata muitos falsos positivos leva à fatiga de alerta. Os usuários ficam inundados de alertas e começam a ignorá-los. Isso 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 reportados não são resolvidos a tempo.

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

Bem, em resumo: contexto. Segredos genéricos podem ser especialmente difíceis de encontrar por meio de correspondência de padrões sozinho. Se houver uma cadeia longa em um arquivo markdown, as nossas descobertas indicam que é altamente provável que seja um exemplo de senha, portanto, você provavelmente não precisaria lidar com isso. Caso contrário, se a mesma cadeia aparece após a string password= em um arquivo chamado project.env, então há uma chance muito maior de ter um verdadeiro segredo na mão.

A string de arquivo é apenas um dos elementos que consideramos com Pré- 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 TI que nós entrevistamos 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 um vazamento de segredo.

O Spot the Secrets foi projetado para mostrar os problemas de confiar em humanos para identificar esses 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-se hidratado, 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 estarem disponíveis para catch up no conteúdo que perdemos enquanto ajudávamos as pessoas a aprender sobre a Expansão de Segredos. Ao longo do caminho, aprendemos muito sobre como as pessoas da segurança, desenvolvedores e em geral, veem este problema e pensam em soluções. Na GitGuardian, esperamos incorporar essas lições para tornar a solução the 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 participar do AppSec Village e encontrar sua tribo no campo de férias de hacker.