Vazamento de dados da Snowflake: hackers confirmam acesso por meio de infecção por infostealer
(hudsonrock.com)- Em 31 de maio de 2024, a empresa de nuvem Snowflake sofreu um grande vazamento de dados
- Os hackers confirmaram à Hudson Rock que obtiveram acesso por meio de uma infecção por infostealer
- Os hackers venderam dados de várias grandes empresas, incluindo Ticketmaster e o banco Santander, em um fórum russo de cibercrime
Método do ataque
- Os hackers fizeram login na conta ServiceNow de um funcionário da Snowflake usando credenciais roubadas.
- Eles burlaram o Okta para gerar tokens de sessão e exfiltrar grandes volumes de dados.
- Os hackers afirmam que cerca de 400 empresas foram afetadas.
Evidências adicionais
- Os hackers compartilharam com pesquisadores da Hudson Rock um arquivo CSV que mostra acesso aos servidores da Snowflake.
- O arquivo documenta mais de 2.000 instâncias de clientes relacionadas aos servidores europeus da Snowflake.
Objetivo dos hackers
- Os hackers exigiram US$ 20 milhões da Snowflake em troca da recuperação dos dados.
- A empresa não respondeu a isso.
Aumento das infecções por infostealer
- As infecções por infostealer aumentaram 6000% desde 2018, tornando-se um dos principais vetores de ataque inicial.
- Isso é usado para executar ataques cibernéticos, incluindo ransomware, vazamento de dados, sequestro de contas e espionagem corporativa.
Opinião do GN⁺
- Importância da cibersegurança: este caso mostra que as empresas precisam dar ainda mais atenção à cibersegurança. Em especial, a gestão das credenciais dos funcionários é crucial.
- Ameaça dos infostealers: os infostealers estão se espalhando muito rapidamente, e as empresas precisam preparar medidas de defesa contra isso.
- Estratégia de resposta: quando ocorre um incidente de invasão, é necessária uma resposta rápida e uma estratégia para minimizar os danos. A resposta tardia da Snowflake ampliou o impacto.
- Treinamento de segurança: é importante reforçar o treinamento de segurança dos funcionários para aumentar a conscientização sobre gestão de credenciais e ataques de phishing.
- Soluções alternativas: é possível considerar outras soluções de armazenamento em nuvem com recursos semelhantes aos da Snowflake, como AWS S3 ou Google Cloud Storage.
1 comentários
Opiniões do Hacker News
A URL vinculada atualmente está fazendo redirecionamento 302 para
/. @dang, parece melhor trocar pelo link arquivado abaixohttps://web.archive.org/web/20240531140540/https://www.hudso...
Mas o fato de a Hudson Rock ter tirado o post do blog do ar também é um sinal interessante, então não dá para simplesmente trocar pelo link arquivado e seguir em frente. O que mudou?
Atualização: a resposta oficial da Snowflake parece negar, na prática, quase todas as principais alegações do texto original. Pode ser que a Hudson Rock tenha sido enganada por uma fonte desonesta e, ao perceber o erro, tenha removido o post
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Aqui é o Felipe, da Snowflake. A posição mais recente da Snowflake sobre este problema está aqui: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Continuaremos atualizando essa URL se houver novidades
Mas a frase da Snowflake — “De forma semelhante às contas de clientes afetadas, encontramos evidências de que o agente de ameaça obteve acesso a uma conta de demonstração pertencente a um ex-funcionário da Snowflake usando credenciais pessoais obtidas. Não havia dados sensíveis” — dá a entender que a Snowflake considera falsa a explicação da Hudson Rock. Esse entendimento está correto?
Já o texto da Snowflake parece dizer que credenciais de contas de clientes vazaram, e que foi só isso, sem acesso a uma conta central ou a outras contas. Não diz nada sobre o uso de credenciais de uma conta de funcionário sem autenticação de dois fatores
É claro que a Snowflake deve querer autenticação de dois fatores em todas as credenciais de acesso de funcionários internos. Antigamente, se o cliente quisesse, podia criar apenas um nome de usuário/senha para fazer login em seus próprios dados, sem autenticação de dois fatores
Os screenshots dos logs de chat são realmente impressionantes. A empresa afirma estar se comunicando com um criminoso de verdade, e esse criminoso diz que, se tivessem usado a empresa, isso teria ajudado a evitar a invasão
Então atualizei meu julgamento sobre a credibilidade dessa empresa
A Hudson Rock parece ter embarcado nisso e inflado a história, fazendo-a parecer uma violação maior do que realmente foi. Também fico curioso se o hacker procurou a Hudson Rock primeiro, ou se a Hudson Rock foi a primeira empresa que deu atenção
“Vocês deveriam ter comprado a proteção da Hudson Rock, e então este caso poderia ter sido evitado”
“Correto, certamente teria ajudado”
“Parabéns. Sua empresa passou por uma auditoria surpresa de segurança da informação e se tornou vítima de ransomware.”
[...]
Itens oferecidos: 1) suporte completo à descriptografia 2) prova de exclusão dos dados 3) relatório de segurança sobre as vulnerabilidades encontradas 4) garantia de que os dados não serão publicados nem vendidos 5) garantia de que não haverá ataques futuros
No fim, é só uma empresa de consultoria de segurança que você não sabia que tinha colocado na folha de pagamento
A propósito, fui ver o que eles forneciam como prova de exclusão dos dados, e era literalmente apenas a saída padrão de
rm -vrf data. Entendo que é impossível fornecer prova de ausência e que a vítima não tem poder de negociação, mas eu gosto bastante dessa encenaçãoMesmo que seja real, o bom senso seria remover as mensagens da Hudson Rock. Coloquei essa empresa na minha blacklist mental
Pela forma como o autor do ataque descreve, parece que a Snowflake projetou o sistema de modo a dar poder total sobre tudo a uma única conta de administrador
O fato de a Snowflake ter dito, em um comunicado de 31 de maio, que estava investigando “ataques baseados em identidade em todo o setor que afetaram alguns clientes” também dá mais credibilidade às histórias da Ticketmaster e do Santander
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Se o agente de ameaça tiver feito tudo direito, isso pode se tornar um dos maiores vazamentos de dados da história
Os dados parecem ter vindo da conta Snowflake dessa pessoa, usada para criar demos para clientes ou potenciais clientes. É possível que clientes tenham dado acesso a parte de seus dados reais para uso em demos, mas isso está longe de significar acesso ilimitado aos próprios bancos de dados Snowflake dos clientes
Também é bem possível que o hacker tenha extraído dados falsos de demo, embora convincentes, e não saiba distinguir a diferença
Um único engenheiro de vendas atende várias contas. Engenheiros de vendas da Snowflake normalmente não constroem dentro do ambiente do cliente; eles configuram uma conta demo com US$ 400 em créditos, que qualquer pessoa pode criar. Como contas demo expiram com o tempo, eles continuam criando novas
O engenheiro de vendas constrói dentro da conta demo que criou e mostra ao cliente. Depois de 30 dias, se não houver cartão de crédito, a Snowflake bloqueia a conta e, posteriormente, exclui a instância de demo e os dados
Para o trabalho, o cliente pode compartilhar dados da sua própria instância Snowflake para a instância demo criada pelo engenheiro de vendas, ou conceder acesso a esse engenheiro de vendas da Snowflake via SSO
Em ambos os casos, parece mais um problema de organizações que não operaram sua postura de segurança de forma suficientemente restritiva. Não há nada de novo no ataque, além de terem encontrado um engenheiro de vendas esforçado e clientes que não limitaram adequadamente o escopo de permissões de funcionários/contratados/convidados
Curiosamente, na primeira página também há uma história adjacente sobre o uso do Pegasus contra ONGs do Leste Europeu. O princípio do menor privilégio é importante, mas a segurança dos dispositivos também é
https://news.ycombinator.com/item?id=40535912
Não sou funcionário da Snowflake, mas trabalhei bastante com a Snowflake e sua organização de engenheiros de vendas
Ao criar demos com clientes, os engenheiros de vendas montam um ambiente de demonstração usando uma conta demo da Snowflake com US$ 400, que qualquer pessoa pode criar. Para montar a demo, o cliente concede acesso a esse engenheiro de vendas, e ele leva parte dos dados para o ambiente de demo e trabalha com eles. Os nomes dos ambientes divulgados pela Hudson Rock também corroboram isso
Na minha visão, foi um problema de processo: o cliente não expirou o ID da pessoa com quem compartilhava dados, e o agente de ameaça roubou as credenciais. Como não foi exploração de vulnerabilidade, não há nada de novo
E parabéns à Hudson Rock por expor publicamente alguém que foi prejudicado por ter malware no computador. Não é diferente de dar credenciais a um contratado e elas serem roubadas. É uma atitude bem maldosa
A Snowflake pode ter credenciais de seus engenheiros de vendas roubadas, essas credenciais podem contornar a autenticação multifator e, segundo o artigo, não expiram. Isso é strike 1, 2 e 3
As práticas de segurança da Snowflake criaram uma situação em que clientes são obrigados, ou pelo menos incentivados, a compartilhar acesso a conjuntos amplos de dados com funcionários da Snowflake. Strike 4
Os clientes também têm responsabilidade por conceder acesso amplo demais, mas a Snowflake também é responsável por não criar um sistema melhor que tornasse esse acesso desnecessário, ou ao menos por não supervisionar e controlar melhor esse acesso transitivo
No momento em que uma conta dessas recebe acesso a dados de clientes, ela deixa de ser uma “conta demo”. É uma conta real, com dados reais e muito valiosos, e deve ser tratada como tal
Adendo: a Snowflake afirma que essa conta demo não acessou dados de clientes e não foi a origem do vazamento, o que contradiz a alegação do atacante
“Imagine ter acesso a uma plataforma de prospecção com centenas de milhares de empresas comprometidas no mundo todo e vulnerabilidades ativas, para que você possa convertê-las em clientes.”
Já vi e lidei com algumas empresas desse tipo; é uma tática bem rasteira e, tecnicamente, também mostra baixo nível de habilidade ou esforço
A resposta oficial da Snowflake diz o seguinte:
“Acreditamos que isso seja resultado de ataques baseados em identidade em andamento em todo o setor, com a intenção de obter dados de clientes. Segundo a investigação, esses ataques são realizados com credenciais de usuários de clientes expostas por meio de atividades de ameaças cibernéticas não relacionadas. Até o momento, não acreditamos que essa atividade tenha sido causada por uma vulnerabilidade, erro de configuração ou atividade maliciosa dentro do produto Snowflake.”
[0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Parece que o artigo foi colocado como privado, mas ainda está no Wayback Machine: https://web.archive.org/web/20240531140540/https://www.hudso...
Este texto afirma que a violação da Ticketmaster de alguns dias atrás, na verdade, fazia parte de um hack muito mais amplo que afetou mais de 400 empresas por meio de credenciais roubadas de um funcionário da Snowflake.
Por enquanto, parece ser uma grande história noticiada apenas pelo hudsonrock.com. Nunca tinha ouvido falar da Hudson Rock; alguém sabe se é uma fonte confiável?
Várias contas foram banidas por operadores e administradores do Reddit. Pessoalmente, não a vejo como uma fonte confiável ou digna de crédito.
https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
A Snowflake parece estar dizendo que a culpa não é dela, mas dos clientes.
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Se https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... não for uma história totalmente inventada, a Snowflake está sendo um pouco menos honesta sobre os fatos.
A expressão “segundo a investigação…” é ambígua: não fica claro se é uma investigação própria ou pesquisa de segurança em geral. A frase “não acreditamos que tenha sido causada por vulnerabilidade, erro de configuração ou atividade maliciosa dentro do produto Snowflake” também lista cenários possíveis para negá-los, mas habilmente deixa de fora como isso de fato aconteceu.
Se você acreditar na Hudson Rock, a Snowflake foi contatada pelo agente malicioso, então é bem provável que soubesse bastante bem como isso ocorreu.
Ela diz que foi “realizado com credenciais de usuários de clientes expostas por meio de atividades de ameaças cibernéticas não relacionadas”, então, se isso não foi inventado, parece que as credenciais foram obtidas em outro lugar.
No fim, eles pediram aos clientes para revisar as configurações das contas, então a direção é tirar a responsabilidade deles. Dito isso, no momento as fontes são uma empresa que foi hackeada e outra que está usando o caso para promover seu próprio produto enquanto expõe descaradamente a identidade de um funcionário; acho melhor esperar por informações mais detalhadas.
O hacker afirma que eles nem invalidaram os tokens de atualização; se for verdade, isso é um problema enorme e óbvio.
O artigo não parece muito consistente com o título de “centenas de clientes comprometidos”.
Primeiro, a senha do lift/okta parece permitir apenas acesso ao portal do ServiceNow, não acesso às contas dos clientes; portanto, o problema dos tokens de atualização parece limitado ao portal ServiceNow e não relacionado à exposição de dados em contas Snowflake reais de clientes.
Segundo, a captura de tela dizendo que contas de 10 empresas foram comprometidas mostra 4 credenciais diferentes de contas Snowflake, e uma delas parece ser uma conta demo pessoal. Portanto, no máximo isso explicaria algo como 3 clientes comprometidos, mas não há detalhes mostrando a violação de outros clientes.
Mesmo supondo que todas as credenciais de todos os clientes com que o engenheiro de vendas trabalhava tenham sido comprometidas, o número de clientes afetados provavelmente ficaria na casa das dezenas baixas. Isso porque cada conta de cliente teria de ter concedido acesso individualmente ao engenheiro de vendas.
Dizer que todos os clientes da Snowflake foram comprometidos com base em um problema de token de atualização no portal interno do Okta é um grande salto, e esse problema não está conectado a nenhuma conta Snowflake de cliente.