Incidente de segurança da Cloudflare no Dia de Ação de Graças de 2023
(blog.cloudflare.com)- A Cloudflare anunciou que detectou um agente de ameaça em seu servidor Atlassian hospedado internamente em 23 de novembro de 2023, mas que os dados de clientes, os sistemas de clientes e os sistemas e configurações da rede global não foram afetados
- O vetor de invasão foi 1 token de acesso e 3 credenciais de contas de serviço que não foram rotacionados após a violação da Okta em outubro de 2023, e o acesso se concentrou no ambiente Atlassian, como Jira, Confluence e Bitbucket
- O agente de ameaça realizou reconhecimento e acessou documentos internos entre 14 e 17 de novembro e, em 22 de novembro, instalou o Sliver por meio do ScriptRunner for Jira para garantir acesso persistente
- Em resposta “Code Red”, a Cloudflare rotacionou mais de 5.000 credenciais de produção, realizou triagem forense em 4.893 sistemas e reimaginou e reiniciou todas as máquinas da rede global e todos os produtos Atlassian
- A investigação independente da CrowdStrike também não encontrou atividades não detectadas, e a última evidência de atividade da ameaça foi confirmada em 24 de novembro de 2023 às 10:44 UTC
Visão geral do incidente e escopo do impacto
- A Cloudflare detectou um agente de ameaça em seu servidor Atlassian hospedado internamente em 23 de novembro de 2023
- A equipe de segurança iniciou imediatamente a investigação e bloqueou o acesso
- Em 26 de novembro, chamou a equipe forense da CrowdStrike para realizar uma análise independente
- Dados de clientes e sistemas de clientes não foram afetados por este incidente
- Os serviços não estiveram envolvidos
- Também não houve alterações em sistemas ou configurações da rede global
- Controles de acesso, regras de firewall e chaves físicas de segurança impostas por suas próprias ferramentas de Zero Trust limitaram o movimento lateral
- O escopo de acesso do agente de ameaça ficou restrito ao Atlassian Confluence, wiki interna, ao banco de dados de bugs Jira, ao sistema de gerenciamento de código-fonte Bitbucket e aos servidores onde o Atlassian era executado
Credenciais usadas na invasão
- A invasão começou com 1 token de serviço e 3 contas de serviço que haviam vazado após a violação da Okta em outubro de 2023, mas não foram rotacionados
- Token de serviço do Moveworks: usado para acesso remoto aos sistemas Atlassian
- Conta de serviço do Smartsheet: tinha privilégios de administrador na instância Jira da Atlassian
- Conta de serviço do Bitbucket: usada para acessar o sistema de gerenciamento de código-fonte
- Conta do ambiente AWS: não tinha permissões de acesso à rede global, aos dados de clientes ou a dados sensíveis
- Esses tokens e contas foram excluídos da rotação porque se acreditou, por engano, que não estavam em uso
- A Cloudflare declarou explicitamente que o problema não foi um erro da Atlassian, AWS, Moveworks ou Smartsheet, mas resultado da falha da própria Cloudflare em rotacionar as credenciais
Linha do tempo do ataque
- A partir de 14 de novembro às 09:22:49, o agente de ameaça iniciou exploração do sistema e reconhecimento
- A tentativa de login na instância Okta foi negada
- O acesso ao Cloudflare Dashboard também foi bloqueado
- Houve acesso ao ambiente AWS que opera o marketplace Cloudflare Apps, mas esse ambiente estava isolado da rede global e dos dados de clientes
- Em 15 de novembro às 16:28:38, obteve sucesso ao acessar Atlassian Jira e Confluence
- Passou pelo gateway com o token de serviço do Moveworks e acessou a suíte Atlassian com a conta de serviço do Smartsheet
- Fez buscas na wiki por remote access, secret, client-secret, openconnect, cloudflared, token etc.
- Acessou 36 de 2.059.357 tickets do Jira e 202 de 194.100 páginas da wiki
- Os tickets do Jira acessados incluíam itens relacionados a gestão de vulnerabilidades, rotação de secret, bypass de MFA, acesso à rede e resposta ao incidente da Okta
- Em 16 de novembro às 14:36:37, usando as credenciais do Smartsheet, criou uma conta Atlassian que aparentava ser de um usuário comum da Cloudflare e a adicionou a vários grupos
- Era uma medida para manter acesso ao ambiente Atlassian mesmo que a conta de serviço do Smartsheet fosse removida
- De 17 de novembro às 14:33:52 até 20 de novembro às 09:26:53, o acesso aos sistemas da Cloudflare foi interrompido, exceto por breves testes de acesso
- Em 22 de novembro às 14:18:22, usando os privilégios de administrador do Jira da conta de serviço do Smartsheet, instalou o Sliver Adversary Emulation Framework por meio do plugin ScriptRunner for Jira
- O Sliver é uma ferramenta e framework usado por red teams e atacantes para C2, conectividade e acesso persistente e furtivo
- Isso permitiu acesso persistente ao servidor Atlassian e tentativas de movimento lateral
- Falhou a tentativa de acessar um servidor de console não produtivo em um datacenter de São Paulo, Brasil, que ainda não havia entrado em produção
Acesso a código-fonte e documentos
- Durante um dia após 22 de novembro, o agente de ameaça consultou 120 repositórios de código entre 11.904 repositórios
- Desses, 76 repositórios foram baixados para o servidor Atlassian usando a funcionalidade git archive do Atlassian Bitbucket
- A Cloudflare não conseguiu confirmar exfiltração externa, mas respondeu ao incidente assumindo que ela ocorreu
- Os 76 repositórios estavam relacionados principalmente às seguintes áreas
- Como os backups funcionam
- Configuração e gerenciamento da rede global
- Sistema de identidade da Cloudflare
- Acesso remoto
- Uso de Terraform e Kubernetes
- Alguns repositórios continham secret criptografados, e a Cloudflare os rotacionou imediatamente mesmo que estivessem fortemente criptografados
- A Cloudflare concentrou a investigação menos no código-fonte em si e mais em secret embutidos, vulnerabilidades e caminhos que poderiam ser explorados em ataques posteriores
- A Cloudflare explicou que já publicou muito código-fonte como open source e que também tratou publicamente, em seu blog, dos algoritmos e técnicas que utiliza
Detecção e bloqueio
- Em 23 de novembro às 16:00, a equipe de segurança recebeu um alerta sobre a presença do agente de ameaça
- 15:58: o agente de ameaça adicionou a conta de serviço do Smartsheet ao grupo de administradores
- 16:00: o alerta automático sobre essa alteração foi enviado à equipe de segurança
- 16:12: o SOC da Cloudflare iniciou a investigação
- 16:35: a conta de serviço do Smartsheet foi desativada
- 17:23: a conta de usuário Atlassian criada pelo agente de ameaça foi descoberta e desativada
- 17:43: o incidente interno da Cloudflare foi declarado
- 21:31: foi aplicada uma regra de firewall para bloquear os endereços IP conhecidos do agente de ameaça
- Em 24 de novembro, foram confirmadas a última atividade e a remoção do Sliver
- 10:44: última atividade conhecida do agente de ameaça
- 11:59: remoção do Sliver
- O agente de ameaça tentou acessar vários sistemas, como métricas internas, configurações de rede, sistema de build, sistema de alertas e sistema de gerenciamento de releases, mas não teve sucesso
- Não foram encontradas evidências de acesso à rede global, datacenters, chaves SSL, bancos de dados de clientes ou informações de configuração, Cloudflare Workers, modelos de IA, infraestrutura de rede ou armazenamentos de dados como Workers KV, R2 e Quicksilver
Resposta “Code Red” e trabalho de reforço
- Após remover o agente de ameaça do ambiente em 24 de novembro, a Cloudflare mobilizou equipes em toda a empresa para investigar a invasão e confirmar o escopo do acesso
- A partir de 27 de novembro, muitos profissionais técnicos de dentro e de fora da equipe de segurança se concentraram no projeto Code Red
- Reforçaram, validaram e corrigiram os controles do ambiente em preparação para futuras invasões
- Verificaram se o agente de ameaça não poderia continuar acessando o ambiente
- Investigaram todos os sistemas, contas e logs para confirmar persistência e identificar o que foi acessado ou alvo de tentativa de acesso
- As principais medidas foram as seguintes
- Rotação de mais de 5.000 credenciais de produção
- Separação física de sistemas de teste e staging
- Triagem forense em 4.893 sistemas
- Reimagem e reinicialização de todas as máquinas da rede global
- Reimagem e reinicialização de todos os produtos Atlassian, como Jira, Confluence e Bitbucket
- Os equipamentos do datacenter de São Paulo foram devolvidos ao fabricante
- A equipe forense do fabricante investigou se houve acesso ou estabelecimento de persistência
- Nada foi encontrado, mas a Cloudflare substituiu o hardware
- Além disso, foram investigados pacotes de software desatualizados, possíveis contas de usuário criadas, contas ativas de funcionários que não estavam em uso, secret que poderiam permanecer em tickets do Jira ou no código-fonte e arquivos HAR enviados à wiki
- Os arquivos HAR foram excluídos por precaução, devido à possibilidade de conter tokens
- O trabalho imediato do Code Red foi encerrado em 5 de janeiro de 2024, mas melhorias em gerenciamento de credenciais, hardening de software, gestão de vulnerabilidades e alertas adicionais continuam em andamento
Investigação da CrowdStrike e IOCs
- A CrowdStrike avaliou de forma independente o escopo da atividade do agente de ameaça e evidências de persistência
- Não foram encontradas atividades ignoradas pela investigação da Cloudflare
- Concluiu-se que a última evidência de atividade da ameaça foi em 24 de novembro de 2023 às 10:44 UTC
- Com base na cooperação com colegas da indústria e do governo, a Cloudflare concluiu que este ataque foi conduzido por um ator patrocinado por Estado que buscava obter acesso persistente e amplo à rede global da Cloudflare
- A Cloudflare divulgou indicadores de comprometimento para que outras organizações possivelmente afetadas pela violação da Okta possam verificar seus logs
193.142.58[.]126: infraestrutura principal do agente de ameaça, pertencente à M247 Europe SRL198.244.174[.]214: servidor C2 do Sliver, pertencente à OVH SASidowall[.]com: infraestrutura de entrega do payload do Sliverjvm-agent: nome do arquivo do payload do Sliver, SHA256bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf
1 comentários
Opiniões no Hacker News
É por causa desse tipo de análise pública e resposta da Cloudflare que acho que posso confiar meus dados e meu negócio a eles.
Não são perfeitos, e há coisas com as quais não concordo, mas sinto que são confiáveis por causa do mindset de engenharia compartilhado pela empresa como um todo e da postura de tratar esse tipo de coisa com seriedade.
A abordagem é enfatizar que eles têm mais integridade do que os concorrentes e compartilhar algumas investigações operacionais depois de um incidente de segurança recente.
Mas a Cloudflare não fornece uma análise de risco SOC como processadora de cartões de pagamento PCI/DSS, nem explica por que deixou passar contas com privilégios elevados ou como essas contas foram comprometidas inicialmente. Ela descreve remediation, não responsabilidade.
Eles mencionam uma auditoria de terceiros, mas não é porque estejam pensando nos usuários; é porque o PCI/DSS exige auditorias presenciais anuais de organizações cujos dados de cartão de pagamento foram comprometidos. Caso contrário, as principais bandeiras teriam interrompido o processamento de pagamentos.
É difícil acreditar que nada tenha sido perdido, e a maioria das instâncias de Jira/Confluence que vi estava cheia de informações secretas.
Pelo trecho “Ao analisar as páginas wiki, issues do banco de dados de bugs e repositórios de código-fonte acessados, parece que eles estavam procurando informações sobre a arquitetura, a segurança e a gestão da rede global”, o caminho mais fácil para um ator estatal é colocar um cidadão leal como funcionário na empresa-alvo e fazer essa pessoa enviar as informações.
Uma história interessante, embora de veracidade incerta, é que há mais de 10 anos, em um encontro social de SREs do Google, algumas pessoas teriam admitido que recebiam salário de agências de inteligência de seus países.
Se não, fico curioso para saber que drogas tão fortes circulavam nesse encontro para que ocorresse uma falha de segurança operacional tão terrível.
Australianos recebem a “oportunidade” de participar desse tipo de espionagem como se fosse uma condição básica de cidadania https://en.wikipedia.org/wiki/Mass_surveillance_in_Australia...
Se há uma vantagem, talvez seja ajudar a forçar boas práticas no desenvolvimento de procedimentos e sistemas zero trust.
Ao ver a parte “Fomos vítimas, pela segunda vez, de uma invasão aos sistemas da Okta”, fico me perguntando se a Cloudflare está reavaliando o uso da Okta.
A Okta também merece críticas, mas isso soa como a Cloudflare empurrando a culpa para baixo para encobrir o próprio erro.
Eu ainda uso um MacBook antigo que recebi “no começo”, então não há nenhum software de gerenciamento nele. Na época não havia TI, e eu simplesmente recebi um notebook novo intocado.
A empresa se ofereceu para me atualizar para um M1/M2 Pro, mas recusei porque, se houver qualquer senha ou chave pessoal no computador de trabalho, não quero usar o sistema de login da Okta.
Então não posso fazer upgrade até que isso comece a atrapalhar muito meu trabalho. Talvez eu possa usar esse tipo de incidente como justificativa para o departamento de TI sobre o que penso.
A frase “Um token de serviço e três contas não foram rotacionados porque acreditamos equivocadamente que não estavam em uso” soa estranha. Se não estavam em uso, não sei por que não foram simplesmente descartados.
Deve haver algo faltando ou que se perdeu na transmissão, mas, lida literalmente, a frase não é muito compreensível.
Por exemplo, pode ter havido, em algum lugar de um banco de dados, um estado inativo marcando aquela conta de serviço como “descartada” ou “limpa”, mas essa marcação estava errada. Então eles rotacionaram as senhas de todas as contas ativas, mas pularam as inativas.
Considerando apenas o contexto de infraestrutura de chave pública e revogação de certificados, que conheço bem, deixar um certificado expirar, marcá-lo como “não mais usado” e revogá-lo completamente são coisas bem diferentes. No primeiro caso, a autoridade certificadora não precisa fazer nada; no segundo, pode não fazer nada ou revogar; no terceiro, precisa manter e distribuir ativamente uma lista de revogação. Se alguém diz “sobrescrevi sem querer a chave privada, me dê um certificado para uma nova chave”, normalmente o certificado antigo não é colocado na lista de revogação.
Foi bom eles terem escrito claramente: “Isso não foi, de forma alguma, um erro da AWS, da Moveworks ou da Smartsheet; foram apenas credenciais que nós não conseguimos rotacionar”.
Embora a Cloudflare acreditasse — e depois tenha confirmado — que o acesso do invasor foi limitado, ela rotacionou mais de 5.000 credenciais de produção, separou fisicamente os sistemas de teste e staging, fez inspeção forense em 4.893 sistemas e recriou as imagens e reiniciou todas as máquinas da rede global
Uma tentativa de acesso ao servidor de console do datacenter de São Paulo, que ainda não havia entrado em produção, também falhou, mas a empresa enviou os equipamentos do datacenter no Brasil de volta ao fabricante para análise forense e, mesmo sem nada ser encontrado, substituiu o hardware
Não precisava ter ido tão longe, e teria sido fácil não fazer isso, mas o fato de terem feito é digno de elogio
Invadir um datacenter na fase inicial de implantação é praticamente o exploit definitivo. Imagine entrar no meio de uma nova Meet-Me room(https://en.wikipedia.org/wiki/Meet-me_room) e obter acesso persistente aos switches centrais
Datacenters da Cloudflare muitas vezes são hubs de enormes volumes de tráfego de dados. O fato de o invasor ter entendido o valor de um datacenter “pré-produção” provavelmente significa que a Cloudflare também percebeu que, se alguém conseguisse uma posição ali antes de a estrutura normal de segurança estar pronta, seria 100% game over. Se alguém consegue se instalar dentro de um datacenter em construção/inicialização, é um incidente que pode acabar com a empresa
Também é preciso lembrar que, no começo da implantação de um datacenter, todos os switches e equipamentos usam valores padrão ou senhas de root vazias (admin/admin), e o firmware também é antigo e cheio de vulnerabilidades. Se esse ataque tivesse acontecido antes de a automação aplicar patches em todo o firmware, seria um incidente do tipo “devolvam todos os equipamentos e façam o fabricante mandar novos”
Se você presumir que o invasor só acessou o escopo comprovável, está deixando brechas para ele sobreviver. Para dizer que não é necessário fazer isso, deveria ser preciso aprovação por quórum de várias pessoas
Claro, isso é um mundo ideal. Já fico grato quando meu time recebe tempo para implementar funcionalidades que não trazem ganho financeiro ou benefício direto ao usuário
Ter prontidão para executar esse tipo de rotação de credenciais exige disciplina e preparação e, francamente, a maioria das equipes não faz esse investimento. Mesmo equipes inteligentes e com muitos recursos
Se a equipe de segurança da Cloudflare consegue decidir rotacionar todos os segredos e recriar a imagem de todas as máquinas, e isso de fato acontece em um prazo razoável, é bastante impressionante
† https://twitter.com/badthingsdaily?lang=en
A parte mais surpreendente aqui é que a Cloudflare usa Bitbucket
Quando um vazamento de dados acontece, os dados já saíram; neste caso, o código-fonte fica permanentemente do lado de fora, e não há nenhum controle sobre quem o obtém
Você pode reforçar tudo o quanto quiser depois do incidente e falar disso o quanto quiser, mas o que se tentava impedir já aconteceu. Não dá para pôr o ovo quebrado de volta
Também dá para encontrar outros easter eggs em código antigo. Quase toda empresa tem backdoors não documentados
Um vazamento de dados de clientes seria pior, mas isso também é realmente ruim
Os dados de clientes do ano que vem também não são iguais aos dados de clientes deste ano
No Confluence da Atlassian, apenas o mecanismo de busca embutido Apache Lucene já pode fazer informações sensíveis vazarem, e esse tipo de acesso pode ser muito difícil de rastrear e identificar
Se as informações sensíveis já aparecem na página de resultados de busca, o invasor nem precisa abrir a página do Confluence
A parte que diz “um token de serviço e três contas não foram rotacionados porque se acreditou erroneamente que não eram usados” é estranha. Credenciais não usadas provavelmente deveriam ser excluídas, não rotacionadas
Foi algo como: “Que contas são essas?” “Ah, não são usadas. Nem aparecem nos logs” “Mesmo assim, temos que rotacionar” “Não, vamos deixar contas aleatórias com credenciais antigas que talvez tenham sido comprometidas… por algum motivo qualquer”?
Acho que, se tinham rotacionado as credenciais vazadas depois do incidente da Okta, deveriam ter colocado um honeypot em cima delas e esperado para ver o que os invasores fariam
Um honeypot também tem o efeito de impedir que o invasor continue por medo de ser descoberto