Vazamentos de segredos: Um passo para o disaster

Dar as chaves da sua casa a criminosos definitivamente não é a melhor ideia. Mas é isso que ocorre frequentemente na maioria das organizações que desenvolvem software moderno.

Neste primeiro post sobre vazamentos de segredos, analisaremos por que isso acontece com tanta frequência, quais são as consequências e quais ações tomar para prevenir ou mitigar o problema e lidar com incidentes de vazamento de segredos.

OH MEU DEUS! Enviei minhas chaves de acesso à nuvem para um repositório público

Segredos codificados no código-fonte ou nos arquivos de configuração nas ferramentas DevOps pode acabar em mãos erradas. Se o segredo é commitinstalado em um repositório de fontes públicas, você está condenado com certeza. Mas mesmo os repositórios privados não são seguros, pois os segredos também vazam através de binários de aplicativos, logs ou código-fonte roubado.

Em retrospecto, é perturbador quantas vezes um simples descuido levou a uma violação grave de segurança. Basta pesquisar no Google “Vazamentos de chave da AWS","Vazamentos de token de acesso do GitHub", e assim por diante. Não tome esses exemplos como recomendações ocultas para este ou aquele fornecedor. Use o seu !

Por exemplo, o (in)famoso Ataque Codecov de abril de 2021 foi possível porque a imagem Codecov Docker continha credenciais git que permitiam a um invasor obter acesso aos repositórios git privados do Codecov e adicionar uma única linha no script bash uploader do Codecov para variáveis ​​​​de ambiente de coleta e URLs de repositório git.

Lembre-se de que parte da recompensa nos ataques são os segredos para obter acesso a sistemas adicionais, e muitos ataques investem pesadamente em credenciais, chaves criptográficas e exfiltração de tokens. 

O problema é que segredos codificados são lugar comum. Em março de 2022 o Lapsus$ APT vazou 189 GB do código-fonte da Samsung e outros arquivos confidenciais. A análise revelou que continha alguns 6,600 segredos codificados: 90% para sistemas internos, mas 10% para serviços e ferramentas externas como GitHub, AWS ou Google. Esses segredos incluíam chaves de API AWS/Twilio/Google, cadeias de conexão de banco de dados e outras informações confidenciais. Este é o que há de mais moderno na maioria das bases de código.

Vazamentos de segredos são o caminho mais fácil para ataques à cadeia de suprimentos

As dependências de pacotes são atualmente o alvo mais frequente, embora não o único, dos ataques à cadeia de abastecimento. Os bandidos podem criar um novo pacote que será instalado no software das vítimas (usando typosquatting e outras técnicas), mas normalmente eles tentam infectar um pacote existente adicionando modificações ao código-fonte em repositórios de software (SCM) como GitHub, GitLab ou BitBucket, ou adicionando versões maliciosas a registros públicos como NPM, PyPI, RubyGems, Maven Central.

Mas injetar código malicioso ou uma dependência maliciosa escondida em um intrincado gráfico de dependências exige Conecte-se credenciais como nome de usuário/senha, tokens ou chaves de acesso (vamos chamá-los de “chaves” para abreviar), para o repositório de origem de destino ou registro público, respectivamente. 

Os bandidos às vezes ganham as chaves através engenharia social. O ataque ao event-stream O popular pacote NPM fornece um bom exemplo. Mas procurando por vazamento Conecte-se credenciais ou chaves de acesso são a técnica de ataque mais frequente para ataques à cadeia de suprimentos de software.

Repositórios de origem e registros de pacotes são dois sistemas essenciais na construção de software pipeline. Mas existem muitas ferramentas no DevOps: CI/CD sistemas, ferramentas para executar testes, automação de configuração e provisionamento ou implantação e lançamento. Todos eles podem ser usados ​​indevidamente para injetar código malicioso em software. O vazamento de chaves válidas para essas ferramentas leva diretamente à miséria e agonia. Imagine o vazamento de chaves de acesso root com controle total sobre seus recursos de nuvem pública…

As recomendações habituais

Não dizemos nada de novo aqui, todos vocês sabem disso. Mas tomem uma atitude! Lembrem-se de que os bots estão escaneando regularmente todas as informações públicas SCM repositórios. Algumas recomendações, sem nenhuma ordem específica.

• Se você é responsável pelo gerenciamento de segurança de TI, definir como os segredos devem ser tratados na política de segurança. Mas as políticas são tão boas quanto a aplicação: garanta que uma diretriz de tratamento de segredos seja aplicada em sua organização, incluindo não apenas suas equipes de DevOps, mas também seus fornecedores de software, e que o plano de resposta a incidentes de sua organização contenha disposições para incidentes de vazamento de segredos.
• Implementar e fazer cumprir Autenticação multifatorial (MFA, 2FA ou qualquer sigla). E sem cortes na segurança: uma chave de segurança USB vale os poucos dólares que custa. Você tem que enviar qualquer uma de suas milhares de credenciais (fácil) e depois ficar bêbado e deixar suas chaves em um bar com algo vinculado a você (as chances são um pouco menores, principalmente se você for abstêmio).
• Use um gerenciador de senhas com uma senha forte e não salva. Para lidar com segredos no uso de sistemas Cofres Secretos. CI/CD sistemas, provedores de nuvem, SCMs e outras ferramentas DevOps fornecem esse serviço, mas você pode optar por uma solução genérica Secret Vault.
• Prefere de curta duração tokens para chaves de acesso de longa duração. São mais fáceis de revogar e expõem uma janela mais limitada ao mal.
• Limitar a reutilização de credenciais: os invasores reutilizarão as credenciais coletadas de um alvo em outros sistemas, outro ponto para usar um gerenciador de senhas. Os gerenciadores de senhas e os cofres secretos devem tornar a reutilização de credenciais uma coisa do passado.
• Limitar e monitorar o uso de admin senhas. Eles são poderosos o suficiente para merecerem um rastreamento especial.
• Executar hashing e criptografia fortes. Voltando às chaves USB (criptográficas), procedimentos rígidos para transmissão de credenciais com parceiros e colegas de trabalho e assim por diante.
• Usar um scanner de segredos, por exemplo, executado em um pre-commit gancho para evitar vazamentos em sistemas de controle de versão, como porta de segurança. Antes da coisa é importante aqui. Como alternativa, use varreduras post-hoc para detectar segredos vazados, por exemplo, como uma verificação antes pull request mescla. Nota: Nossa plataforma Xygeni inclui um scanner de segredos que permite ambos os modos de operação. 
• A alternativa manual de usar revisões de código procurar segredos codificados tem custos mais elevados e funciona pós-commit (mas espero que pelo menos antes que o segredo esteja disponível para estranhos). Mas as revisões podem detectar segredos não convencionais que podem escapar dos scanners de segredos.       
• Evite acidentalmente committing arquivos comuns com segredos para controle de versão com apropriado excluir padrões (como o modelo `gitignore`), levando em consideração arquivos como .env, .npmrc, .pypirc, arquivos temporários… De fato, uma camada adicional na cebola de segurança.
• E o último desta longa lista: permitir que os provedores de nuvem realizem verificações em busca de vazamentos de suas chaves, quando disponíveis. Pelo menos, isso pode informá-lo sobre o vazamento quando acontecer, mas a segurança é uma obrigação para os provedores de nuvem. Esse post-hoc a varredura secreta não é muito transparente em relação a onde e com que frequência a varredura é executada e muitas vezes precisa de configuração explícita, mas certamente é o último recurso quando todo o resto falha.

OH MEU DEUS! Enviei minhas chaves de acesso à nuvem para um repositório público, tomada nº 2

Isso pode acontecer com os melhores de nós. Arregaçar as mangas !

Renove/revogue/desabilite imediatamente o segredo vazado! Se a conta tiver um MFA decente, o risco será muito menor. Isso poderia ser mais difícil, por exemplo, com chaves privadas em sites (você precisa emitir um novo certificado para uma nova chave privada e revogar a existente), mas as ferramentas modernas têm uma maneira rápida de renovar credenciais ou revogar tokens. 

Siga as etapas recomendadas pelo provedor quando disponíveis, como AWS neste exemplo.

Identifique a causa do vazamento. Saber como isso aconteceu é essencial para atividades de divulgação, análise, contenção e lições aprendidas.

Em seguida, relate o vazamento às partes afetadas, explicando as ações que você está tomando para tapar o vazamento e reduzir os danos. Não há como reverter o dano causado, o que vazou vazou. Seja transparente e informe outras pessoas para que possam agir. 

Então comece com o forense. O janela de exposição é o tempo entre o vazamento e o momento em que o segredo não era válido. Esteja pronto para ler os registros e rastrear atividades incomuns na conta afetada durante esse período. Remova contas e chaves geradas usando a conta afetada. Lembre-se de que se a conta afetada tiver privilégios de administrador, a correção será muito mais complexa. 

Reescrevendo o histórico (controle de versão) é complexo. Mesmo os estados totalitários tentam isto sem sucesso (trocadilho intencional). E provavelmente irrelevante: os hackers ou os bots em repositórios públicos podem ter clonado o repositório ou já terem extraído o ouro, em particular se a janela de exposição for suficientemente grande. 

Se você é aventureiro e quer ver por si mesmo quanto tempo leva para os bots detectarem um segredo vazado, armadilhas como Tokens Canário deixe você experimentar. Lembre-se, os bots colocam na lista negra o padrão canarytokens.org domínio…