Quando a violação de um fornecedor se torna sua: lições do incidente da Klue

Existe uma verdade incômoda que toda equipe de segurança acaba enfrentando: a violação que mais prejudica você pode nem acontecer dentro dos seus próprios limites. Você pode corrigir seu código, alternar seus segredos periodicamente e manter seu perímetro bem protegido — e, ainda assim, acordar diante de um incidente causado por um sistema que não é seu.

Esse é o cenário do incidente envolvendo a Klue, uma plataforma de inteligência de mercado usada por diversas empresas para obter informações sobre a concorrência. De acordo com o que foi divulgado publicamente, um agente de ameaça comprometeu o back-end da Klue e usou esse acesso para chegar aos sistemas conectados de seus clientes — incluindo os ambientes Salesforce que eles haviam integrado à plataforma. Além disso, outros fornecedores de segurança, como Recorded Future, Tanium, Huntress e Jamf, também foram afetados e compartilharam atualizações publicamente. Vale a pena analisar o que aconteceu, pois a mecânica do incidente ilustra com clareza como ecossistemas modernos de software como serviço (SaaS) podem ser comprometidos.

A anatomia do incidente

De acordo com as informações divulgadas até agora, a sequência foi mais ou menos assim:

O ponto de entrada inicial na Klue foi uma credencial antiga — supostamente criada em algum momento para um protótipo de integração que acabou sendo abandonado e nunca foi desativada. O acesso permaneceu ativo mesmo depois do fim do projeto para o qual havia sido criado. Um agente de ameaça o encontrou, e ele ainda funcionava.

A partir daí, o invasor chegou à parte da infraestrutura da Klue que conecta a plataforma às ferramentas de seus clientes. Essas conexões usam tokens OAuth: credenciais permanentes que permitem à Klue ler e gravar em sistemas como o Salesforce em nome dos clientes. O invasor inseriu código desenvolvido para capturar esses tokens. Com eles em mãos, não precisava mais invadir cada cliente individualmente. Podia se autenticar como a conta de serviço descoberta, usando o segredo da integração, consultar diretamente os dados de gestão de relacionamento com o cliente (CRM) de cada cliente e, em seguida, exfiltrá-los. Depois, vieram as tentativas de extorsão.

Deixando os detalhes de lado, fica um padrão conhecido: um elo fraco, um conjunto de chaves emprestadas e um raio de impacto que alcança todos os conectados a jusante. O comprometimento de uma única empresa não ficou restrito a ela. Ele se propagou.

Uma observação sobre a Snyk

Em nome da transparência que esperamos de qualquer fornecedor, queremos ser diretos: a Snyk foi uma das organizações afetadas pelo incidente da Klue. Nossa investigação indica que, até o momento, o impacto se limitou principalmente a campos de dados comerciais nos ambientes Salesforce. Isso inclui informações comerciais de contato de clientes e apenas o título e a descrição de um conjunto limitado de solicitações de suporte de clientes. O corpo ou o conteúdo dessas solicitações não foi incluído, e os produtos da Snyk não foram afetados. Nossa capacidade de atender nossos clientes permaneceu intacta.

Após receber a notificação, desativamos a integração da Klue no Salesforce, iniciamos nossa própria análise e acionamos as partes apropriadas. Para consultar o status atual e as informações mais recentes, acesse status.snyk.io ou o Snyk Trust Center. Manteremos ambos atualizados à medida que nossa análise avançar.

Se há algo que gostaríamos que você levasse deste incidente, além do que aconteceu conosco, é: verifique as chaves que você concedeu — e aquelas que já nem lembrava que havia criado.