Lições aprendidas sobre proteção de segredos após a violação do Sisense

Sisense é uma ferramenta de monitoramento popular que permite aos usuários monitorar métricas de negócios de várias fontes de terceiros em um único painel. Em 10 de abril, a empresa informou aos clientes que as informações confidenciais que eles confiaram ao Sisense poderiam ter sido comprometidas e os instou a redefinir suas senhas e alternar seus segredos.

De acordo com KrebsOnSecurity, os invasores supostamente conseguiram acessar os repositórios GitLab hospedados pelo Sisense, onde segredos codificados podem ter sido encontrados. Esses segredos eram as chaves para acessar dados confidenciais de clientes em buckets AWS S3 que continham tokens de acesso, senhas de e-mail e certificados SSL.

Este cenário, se for verdade, é mais um exemplo de atores mal-intencionados explorando uma cadeia de problemas de segurança – desde o acesso aos repositórios GitLab até os dados do cliente por meio de tokens codificados. Se o método usado para acessar os repositórios não for público e puder ter sido sofisticado (sendo, portanto, difícil de parar), os tokens codificados serão bastante fáceis de descobrir com as ferramentas e processos adequados implementados.

A raiz da violação: segredos codificados

Os segredos contêm as informações que os hackers precisam, como senhas, chaves de API e chaves de criptografia, para obter acesso a dados confidenciais, como números de cartão de crédito, informações de seguridade social e registros de saúde. É por isso que eles devem ser armazenados em um cofre seguro e recuperados apenas ad hoc em tempo de execução. Eles nunca devem ser armazenados em texto simples no código-fonte, que pode ser encontrado por qualquer pessoa com acesso ao repositório, ou passado como variáveis ​​de ambiente.

Na recente violação do Sisense, a especulação atual é que os hackers de alguma forma obtiveram acesso aos repositórios GitLab auto-hospedados do Sisense e encontraram segredos codificados em alguns repositórios que lhes deram acesso a um balde contendo dados do cliente. Dito isso, segredos codificados também podem ser descobertos em vários locais, inclusive em bancos de dados, arquivos de log e muito mais.

Esses segredos permitiriam que os hackers acessassem os buckets AWS S3 que armazenavam informações confidenciais dos clientes, que deveriam ser monitoradas pelos clientes usando os painéis do Sisense e mais ninguém.

Então, o que você pode fazer para evitar esse tipo de ataque?

Como evitar que hackers acessem seus segredos

Existem muitas práticas recomendadas para gerenciamento de segredos para evitar que caiam em mãos erradas.

No nível mais básico, os desenvolvedores devem aproveitar os sistemas de gerenciamento de segredos fornecidos por fornecedores comerciais ou aqueles hospedados diretamente por provedores de nuvem. Os segredos devem então ser extraídos ad hoc pelo serviço que precisa deles, em vez de passados ​​como variáveis ​​de ambiente, que podem ser comprometidas. Além disso, apenas os serviços que precisam recuperar esses valores precisam de acesso a eles (acesso com privilégios mínimos), a fim de reduzir o raio de explosão de uma possível violação.

A maioria dos desenvolvedores sabe disso. Segredos codificados passam despercebidos pelos mesmos motivos pelos quais a maioria das vulnerabilidades de produtos chegam à produção: os desenvolvedores precisam de tempo e são constantemente pressionados para fornecer novos recursos com mais rapidez, o que pode levar a erros, como adicionar segredos codificados aos repositórios.

Erros acontecem a todas as equipes de desenvolvimento de software do mundo, então como podemos evitar que eles introduzam riscos reais aos negócios?

Use a automação para revelar segredos (e muito mais)

Ótimas ferramentas de código aberto, como Gileaks e TruffleHog, podem escanear automaticamente seu código em busca de segredos codificados. Assim, você pode verificar seus repositórios e capturar segredos antes que seu código seja mesclado na produção. Melhor ainda, se você integrá-los em seu IDE e associá-los a algum gancho de pré-confirmação, poderá garantir que esses valores confidenciais não serão confirmados.

Ao manter continuamente um dicionário de expressões regulares de padrões e strings específicos em código-fonte comum, essas ferramentas permitem que os desenvolvedores saibam se um segredo foi exposto antes de enviar o código para produção. Por exemplo, se essas ferramentas virem uma string de 16 caracteres em seu código que começa com AKIA ou ASIA, elas usarão um de seus muitos detectores para determinar se você tem um segredo da AWS exposto.

Usando Gileaks, você pode verificar seus repositórios existentes usando o detect comando para encontrar segredos codificados:

gitleaksdetect --source <path to local cloned repo> --report-path=report.json

Você pode usar o protect comando para verificar o código não confirmado e procurar segredos codificados:

gitleaksprotect --source <path to local cloned repo>

Isso criará um arquivo chamado .pre-commit-config.yaml no diretório raiz do repositório. Este arquivo deve ser colocado no diretório raiz para que o gancho esteja ativo.

Embora essas ferramentas sejam um ótimo começo para detectar vulnerabilidades antes da produção, elas se concentram exclusivamente em segredos codificados, que são apenas uma fração das vulnerabilidades potenciais do produto que poderiam, em última análise, expor dados confidenciais a atores mal-intencionados.

Existem muitos outros controles de segurança que encontram outros tipos de vulnerabilidades, incluindo testes estáticos de segurança de aplicativos (SAST) para problemas de código como injeções, análise de composição de software (SCA) para vulnerabilidades de código aberto, verificação de infraestrutura como código (IaC) para vulnerabilidades de infraestrutura em nuvem e muito mais.

A implementação de todas essas ferramentas em seu pipeline de CI/CD pode ser demorada. Eles também têm formatos de dados e UXes separados, o que pode dificultar sua adoção pelos desenvolvedores. Os desenvolvedores preferem trabalhar em sua próxima solicitação pull (PR) do que percorrer UIs para priorizar e resolver problemas de segurança.

No exemplo abaixo, você verá um exemplo de como revelar um segredo codificado em um PR, para que possa ser resolvido rapidamente antes da produção.

Isso torna mais fácil para os desenvolvedores capturarem segredos codificados desde o início.

Conclusões da recente violação no Sisense

A pressão para fornecer novos recursos rapidamente é implacável, o que inevitavelmente resultará em erros de codificação que poderão expor informações confidenciais aos invasores. Embora seja fácil apontar a culpa em retrospectiva, os erros de codificação são inevitáveis ​​– alguns serão explorados e a maioria nunca o será.

Para eliminar o impacto comercial de tais erros, as empresas podem tomar medidas para capacitar seus desenvolvedores a fornecer código mais seguro sem comprometer a velocidade. Abaixo estão algumas dicas para proteger os aplicativos em produção contra esses tipos de ataques:

• Ferramentas como Gileaks e TruffleHog oferecem maneiras fáceis e eficazes de escanear o código em busca de segredos codificados, o que lembra os desenvolvedores de armazenar os segredos em sistemas de gerenciamento de segredos
• Para unificar a detecção de segredos junto com outros scanners de segurança de produtos que revelam outros tipos de vulnerabilidades, considere plataformas como o Jit, que fornecem um balcão único que pode ser facilmente adotado pelos desenvolvedores.
• Considere a automação para ajudar os desenvolvedores a proteger seu código antes da produção, sem atrasá-los. Ao integrar a verificação de segurança do produto com a criação de relações públicas ou ganchos de pré-comprometimento, os desenvolvedores podem detectar e resolver vulnerabilidades antes que se tornem riscos para os negócios.

Além de ter um método de prevenção eficiente, você precisa pensar no que acontecerá quando ocorrerem incidentes de segurança – a questão não é se, mas quando – para reduzir o raio da explosão e tapar rapidamente o buraco que foi explorado. Portanto, ter uma resposta adequada a incidentes desde o primeiro dia é essencial para a higiene da sua segurança cibernética.

A postagem Lições aprendidas sobre proteção de segredos após a violação do Sisense apareceu pela primeira vez no The New Stack.