O primeiro semestre de 2024 viu algumas das maiores violações dos últimos anos. O denominador comum delas? Credenciais comprometidas e falta de MFA. A violação mais proeminente até o momento é a violação Snowflake, que afetou continuamente algumas das principais organizações desde maio. Neste artigo, vamos nos concentrar em algumas das organizações mais atingidas e resumir com uma violação diferente – embora igualmente evitável.
Snowflake: A cadeia de suprimentos é tão forte quanto seu elo mais fraco
Uma das violações mais notáveis de 2024 até agora é a violação que teve como alvo a plataforma de armazenamento em nuvem, Snowflake. Na verdade, o alvo aqui não era a Snowflake em si, mas sim os clientes da Snowflake, incluindo AT&T, Ticketmaster, Santander Bank e Neiman Marcus, entre outros.
Conforme relatado por vários meios de comunicação cibernéticos, este foi um livro didático ataque à cadeia de abastecimento. Os invasores obtiveram acesso aos clientes da Snowflake por meio de uma máquina comprometida, possivelmente por meio de e-mails de phishing e anexos maliciosos. Estima-se que mais de 500 credenciais foram descobertas dessa forma e colocadas à venda na dark web, incluindo nomes de usuários, senhas e URLs dos ambientes da Snowflake associados a essas credenciais.
De acordo com a Wired, em alguns casos, os invasores usaram uma máquina comprometida de um funcionário ou contratado da Snowflake como seu ponto de entrada inicial. Em outros casos, no entanto, as credenciais usadas por esses indivíduos foram roubadas e vendidas já em 2020 e ainda eram válidas em 2024.
Descobertas da investigação de Snowflake
O investigação conduzido pela Snowflake e Mandiant descobriu que pelo menos 79.7% das contas usadas pelos invasores foram comprometidas anos antes do ataque atual e que suas senhas nunca foram alteradas ou rotacionadas. A investigação também confirmou que centenas de credenciais de clientes da Snowflake foram expostas desde 2020 e que as instâncias impactadas não tinham políticas de acesso em vigor para permitir acesso apenas de locais confiáveis.
A investigação também descobriu que os invasores obtiveram credenciais e as usaram para acessar contas de demonstração de um ex-funcionário da Snowflake. “Esta parece ser uma campanha direcionada a usuários com autenticação de fator único”, confirmou Brad Jones, CISO da Snowflake, em um comunicado emitido pela Snowflake. “Não continha dados sensíveis”.
Jones afirmou ainda que o “acesso foi possível porque a conta demo não estava por trás da Okta ou MFA”, e que “as contas demo não estão conectadas aos sistemas corporativos ou de produção da Snowflake”. Ele também anunciou que a Snowflake está “desenvolvendo um plano para exigir que nossos clientes implementem controles de segurança avançados, como MFA ou políticas de rede, especialmente para contas de clientes Snowflake privilegiadas.
AT&T: Deixe para lá até conseguir
Aproximadamente 110 milhões de clientes da AT&T números de telefone e registros de chamadas foram obtidos por meio de uma conta Snowflake da AT&T. Essas informações incluíam o número de chamadas e mensagens de texto que os clientes fizeram, para qual destino e a duração de cada chamada. Isso significa que os dados também incluíam informações sobre clientes não AT&T que estavam do outro lado da chamada ou mensagem de texto. Os dados não foram vazados ou tornados públicos, e de acordo com alguns relatórios isso ocorreu porque a AT&T supostamente pagou US$ 370,000 em resgate após negociar com o invasor.
Foi um ano difícil para a AT&T. Apenas quatro meses antes a violação Snowflake, um banco de dados de mais de 70 milhões de clientes da AT&T vazou online, revelando nomes, endereços, números de telefone, números de previdência social e datas de nascimento. De acordo com relatos, o banco de dados foi roubado em 2021 e mantido pelo invasor praticamente intacto até março deste ano, quando foi divulgado na íntegra.
Ticketmaster: Mais um Floco na Nevasca
Em maio, os dados sobre 560 milhões de usuários do Ticketmaster foram relatados como tendo sido roubados. Em Em julho, a empresa enviou e-mails aos seus clientes notificando que um usuário não autorizado obteve informações “de um banco de dados em nuvem isolado hospedado por um provedor de serviços de dados de terceiros”, e que as informações “podem ter incluído seu nome, informações básicas de contato e informações de cartão de pagamento, como números de cartão de crédito ou débito criptografados e datas de expiração”. BBC que perguntou à Ticketmaster por que demorou tanto para notificar seus clientes, mas não recebeu resposta.
Change Healthcare (UnitedHealth Group): Uma lição sobre higiene de identidade
Em fevereiro, um ataque de ransomware na Change Healthcare resultou no roubo de 4 TB de dados confidenciais de até 1 em cada 3 americanos, bem como em interrupções generalizadas em hospitais, farmácias e consultórios de saúde nos Estados Unidos.
Embora o UnitedHealth Group (UHG) tenha pago a ALPHV/Blackcat, o ransomware grupo que assumiu a responsabilidade pelo ataque, um resgate de US$ 22 milhões para garantir que os dados seriam excluídos, o grupo supostamente passou os dados roubados para outro grupo, o RansomHub, que exigiu outro resgate.
Como parte de seu depoimento perante o House Energy and Commerce Committee, o CEO da UHG, Andrew Witty, confirmou que os invasores acessaram a rede por meio de um servidor que não tinha MFA. Os invasores compraram credenciais na dark web ou usaram força bruta para obter acesso inicial. De qualquer forma, o MFA os teria impedido. Depois que obtiveram acesso à rede, eles se moveram lateralmente de uma máquina para a outra – e todos nós sabemos como isso terminou.
Melhores práticas de mitigação
Existem certas precauções que as organizações podem tomar para mitigar e conter tais violações, nomeadamente ITDR (ITDR - Detecção e Resposta a Ameaças à Identidade) e ISPM (Identity Security Posture Management). Gady Svahjman, líder global de caça a ameaças na Silverfort, oferece alguns conselhos de especialistas:
Detecção
- Os invasores provavelmente usaram as credenciais roubadas de maneiras diferentes das do usuário legítimo; por exemplo, em momentos diferentes, geolocalizações de origem e máquinas de origem/destino.
- Se detecções e atributos de segurança para autenticações anormais tivessem sido implementados, as violações poderiam ter sido detectadas e um alerta poderia ter sido acionado.
- Contas que não foram usadas por um longo período de tempo, mas cujas credenciais estão subitamente autenticando, ou contas com senhas que não expiram também devem ter levantado uma bandeira vermelha. Indicadores de risco e políticas de acesso adequados disparariam um alerta em tais casos.
Prevenção
- A detecção por si só não é suficiente, e as organizações não devem confiar exclusivamente em alertas. Rever milhares de alertas todos os dias não é sustentável, e a detecção retrospectiva não é suficiente.
- Políticas de acesso poderia ter negado o acesso com base na análise comportamental e de padrões.
- A falta de MFA foi um fator crucial para permitir que os invasores obtivessem acesso a essas instâncias do Snowflake e Change Assistência médica rede.
- Ao exigir mais de um fator para autenticação, controles fortes de MFA poderiam ter parado os invasores. Suas credenciais legítimas de usuário não eram suficientes, pois eles teriam que lidar com uma camada extra de segurança.
Resposta
- Criando muros: para conter o ataque e congelar a situação quando ele for descoberto, o primeiro princípio de segurança que você deve implementar é criar políticas para negar qualquer acesso que não seja necessário para operações comerciais críticas.
- Conter contas e máquinas comprometidas pode envolver negar completamente o acesso a máquinas e contas, ou apenas parcialmente; por exemplo, permitindo apenas que fontes e destinos especificados acessem a infraestrutura crítica.
- Em caso de dúvida sobre se um conta de usuário foi comprometido ou se a organização deve permitir que o usuário continue trabalhando, redefinir a senha desse usuário e aplicar uma política para permitir operações com essa conta usando MFA é outra opção em vez de negar o acesso.
Considerações Finais
Pode ser desconfortável admitir, mas essas violações poderiam ter sido evitadas, ou pelo menos os danos mantidos no mínimo. Tudo o que precisava ser feito era atualizar senhas, habilitar MFA e definir políticas de acesso. Isso pode parecer fácil o suficiente, mas na verdade nem sempre é tão simples.
Por exemplo, organizações que contratam terceiros e usam contas gerenciadas por esses terceiros têm capacidade muito limitada de verificar as permissões das contas ou mesmo se elas ainda estão ativas.
Da descoberta à contenção, segurança de identidade é um ciclo. Coordenação e unificação são necessárias, assim como um esforço constante para ficar por dentro das coisas. Essas violações não expuseram apenas números de cartão de crédito, informações médicas pessoais e registros de chamadas de milhões de clientes – elas expuseram o quão pouco sabemos e estamos comprometidos com a segurança de identidade versus o quão crítica ela realmente é.