Incidente de segurança no Dia de Ação de Graças de 2023

Incidente de segurança no Dia de Ação de Graças de 2023

• Em 23 de novembro de 2023, no Dia de Ação de Graças, a Cloudflare detectou um agente de ameaça em seus servidores Atlassian hospedados internamente.
• A equipe de segurança iniciou imediatamente a investigação e bloqueou o acesso do agente de ameaça.
• Em 26 de novembro, a equipe forense da CrowdStrike foi acionada para realizar uma análise independente.
• A CrowdStrike concluiu a investigação, e a Cloudflare compartilha os detalhes do incidente de segurança por meio deste post no blog.
• A Cloudflare enfatiza que os dados e sistemas dos clientes não foram afetados por este incidente.
• Controles de acesso, regras de firewall e a aplicação obrigatória de chaves de segurança físicas com ferramentas de Zero Trust limitaram a capacidade de movimentação lateral do agente de ameaça.

Trabalho de recuperação e reforço “Code Red”

• Depois que o agente de ameaça foi removido do ambiente, a equipe de segurança mobilizou todas as pessoas necessárias em toda a empresa para concluir a investigação da invasão e o bloqueio de acesso.
• A partir de 27 de novembro, equipes técnicas foram mobilizadas para se concentrar em um projeto chamado "Code Red".
• O objetivo desse projeto era reforçar e verificar todos os controles no ambiente para se preparar para futuras invasões e impedir que o agente de ameaça voltasse a acessar o ambiente.
• A CrowdStrike realizou uma avaliação independente sobre o escopo e a extensão das atividades do agente de ameaça.

Linha do tempo do ataque

• O ataque começou com a violação de segurança da Okta em outubro, e o agente de ameaça passou a mirar os sistemas da Cloudflare em meados de novembro usando credenciais obtidas nessa violação.
• Em 18 de outubro, a violação da Okta permitiu que o agente de ameaça acessasse credenciais.
• A partir de 14 de novembro, o agente de ameaça começou a explorar os sistemas e tentar obter acesso.
• Em 15 de novembro, conseguiu acessar com sucesso o Atlassian Jira e o Confluence.
• Em 16 de novembro, criou uma conta de usuário Atlassian.
• De 17 a 20 de novembro, não acessou sistemas da Cloudflare.
• Em 22 de novembro, instalou o Sliver Adversary Emulation Framework para manter acesso persistente.
• Em 23 de novembro, a equipe de segurança detectou a presença do agente de ameaça e iniciou o bloqueio de acesso.

Conclusão

• Presume-se que este incidente tenha sido obra de um atacante patrocinado por um Estado, e a Cloudflare fez grandes esforços para limitar o impacto do incidente e se preparar para ataques futuros.
• A equipe de engenharia da Cloudflare protegeu os sistemas, buscou entender o acesso do agente de ameaça, resolveu prioridades imediatas e elaborou um plano para melhorar a segurança de forma geral.
• A CrowdStrike realizou uma avaliação independente e, após a conclusão do relatório final, a Cloudflare publicou este post no blog com confiança em sua análise interna e nas medidas tomadas em resposta à invasão.

GN⁺ opina:

1. Este incidente destaca a importância da arquitetura Zero Trust da Cloudflare. Ela funciona limitando a propagação da ameaça por toda a organização por meio do isolamento entre sistemas.
2. A resposta rápida da Cloudflare e os esforços de reforço de segurança por meio do projeto "Code Red" oferecem insights sobre como empresas respondem a ameaças de cibersegurança.
3. Este texto serve como um caso útil para entender como uma organização deve responder quando ocorre um incidente de cibersegurança e quais medidas precisam ser adotadas.

[GN⁺]

Opiniões do Hacker News

• Por que ações como a postagem no blog da Cloudflare geram confiança

  • A Cloudflare não é perfeita, mas é confiável por sua mentalidade de engenharia e pela forma como lida com problemas sérios.
  • Expressão de agradecimento pela postagem no blog.

• O problema do vazamento de dados

  • Quando os dados vazam uma vez, eles ficam permanentemente fora de controle.
  • O trabalho de reforço e a conversa após o incidente são importantes, mas não podem impedir o que já aconteceu.

• Problemas de segurança nos sistemas da Okta

  • Preocupação com o fato de os sistemas da Okta terem sido atingidos pela segunda vez.

• Tokens de serviço e contas que não foram rotacionados

  • Não foram rotacionados porque se acreditava erroneamente que não estavam em uso.
  • Questionamento sobre por que não foram totalmente revogados.

• Acesso limitado do invasor e medidas de resposta

  • Acreditava-se que o acesso do invasor era limitado, mas ainda assim foram tomadas medidas amplas, como rotacionar todas as credenciais de produção, fazer análise forense dos sistemas, reimaginar e reiniciar.
  • A tentativa de acesso a um novo sistema no data center do Brasil falhou, e o equipamento foi devolvido ao fabricante para inspeção e substituição.

• Análise do objetivo do invasor

  • Com base na análise de páginas wiki, banco de dados de bugs e repositórios de código-fonte, parece que o objetivo era encontrar informações sobre a arquitetura, segurança e administração da rede global da Cloudflare.

• Surpresa com o uso de BitBucket pela Cloudflare

  • Expressão de surpresa pelo fato de a Cloudflare usar BitBucket.

• Tratamento adequado para credenciais sem uso

  • Para credenciais consideradas sem uso, teria sido mais apropriado excluí-las em vez de rotacioná-las.

• Rotação de credenciais após o incidente da Okta e sugestão de honeypot

  • Sugestão de usar um honeypot após rotacionar as credenciais vazadas para observar o comportamento do invasor.

• Dúvidas sobre zero trust (ZT)

  • Aponta-se que poder acessar uma aplicação com um único bearer token não corresponde à definição de zero trust.

Conhecimento de contexto: A Cloudflare é uma empresa que fornece serviços de segurança para a internet e serviços distribuídos de DNS, a Okta fornece serviços de gerenciamento de identidade e acesso, e zero trust é um modelo de segurança de rede baseado em não confiar por padrão em nenhum usuário ou dispositivo e sempre verificar.