Incidente de segurança no Dia de ação de graças de 2023

No Dia de ação de graças, 23 de novembro de 2023, a Cloudflare detectou um agente de ameaças em nosso servidor Atlassian auto-hospedado. Nossa equipe de segurança iniciou imediatamente uma investigação, cortou o acesso do agente da ameaça e, no domingo, 26 de novembro, trouxemos a equipe forense da CrowdStrike para realizar sua própria análise independente.

Ontem, a CrowdStrike concluiu sua investigação e estamos publicando este post no blog para falar sobre os detalhes desse incidente de segurança.

Queremos enfatizar aos nossos clientes que nenhum sistema ou dados de clientes da Cloudflare foram afetados por este evento.  Devido aos nossos controles de acesso, regras de firewall e uso de chaves de segurança rígidas aplicadas por meio de nossas próprias ferramentas Zero Trust, a capacidade do agente da ameaça de se mover lateralmente foi limitada.  Nenhum serviço foi implicado e nenhuma alteração foi feita em nossos sistemas ou configurações de rede global.  Esta é a promessa de uma arquitetura Zero Trust: é como compartimentos estanques em um navio, onde um comprometimento em um sistema é limitado para não comprometer toda a organização.

De 14 a 17 de novembro, um agente de ameaças fez reconhecimento e depois acessou nosso wiki interno (que usa o Atlassian Confluence) e nosso banco de dados de bugs (Atlassian Jira).  Nos dias 20 e 21 de novembro, observamos acesso adicional indicando que o agente poderia ter voltado para testar o acesso e garantir que tinha conectividade.

Ele então retornou em 22 de novembro e estabeleceu acesso persistente ao nosso servidor Atlassian usando ScriptRunner for Jira, obteve acesso ao nosso sistema de gerenciamento de código-fonte (que usa Atlassian Bitbucket) e tentou, sem sucesso, acessar um servidor de console que tinha acesso ao data center que a Cloudflare ainda não havia colocado em produção em São Paulo, Brasil.

O agente fez isso usando um token de acesso e três credenciais de conta de serviço que foram obtidas e que não conseguimos alternar, após o comprometimento do Okta de outubro de 2023. Todos os acessos e conexões do agente da ameaça foram encerrados em 24 de novembro e a CrowdStrike confirmou que o a última evidência de atividade de ameaça foi em 24 de novembro às 10h44.

(Em todo este post do blog, todas as datas e horários são UTC.)

Embora entendamos que o impacto operacional do incidente foi extremamente limitado, levamos esse incidente muito a sério porque um agente de ameaça usou credenciais roubadas para obter acesso ao nosso servidor Atlassian e acessou alguma documentação e uma quantidade limitada de código-fonte.  Com base em nossa colaboração com colegas do setor e do governo, acreditamos que este ataque foi realizado por um invasor de um estado-nação com o objetivo de obter acesso persistente e generalizado à rede global da Cloudflare.

Em 24 de novembro, depois que o agente da ameaça foi removido do nosso ambiente, nossa equipe de segurança reuniu todas as pessoas necessárias na empresa para investigar a intrusão e garantir que o acesso do agente da ameaça tinha sido completamente negado aos nossos sistemas, e para garantir que conhecíamos toda a extensão do que ele acessou ou tentou acessar.

Então, a partir de 27 de novembro, redirecionamos os esforços de grande parte do pessoal técnico da Cloudflare (dentro e fora da equipe de segurança) para trabalhar em um único projeto chamado de “Code Red”. O foco foi fortalecer, validar e corrigir qualquer controle em nosso ambiente para garantir que estamos seguros contra futuras intrusões e para validar que o agente da ameaça não poderia obter acesso ao nosso ambiente.  Além disso, continuamos investigando cada sistema, conta e registro para garantir que o agente da ameaça não tivesse acesso persistente e que conhecíamos completamente quais sistemas ele tinha tocado e quais tinha tentado acessar.

A CrowdStrike realizou uma avaliação independente do escopo e extensão da atividade do agente da ameaça, incluindo uma busca por qualquer evidência de que ele ainda persistia em nossos sistemas.  A investigação da CrowdStrike forneceu corroboração e apoio úteis para a nossa investigação, mas não trouxe à luz quaisquer atividades que não detectamos.  Este post do blog descreve em detalhes tudo o que nós e a CrowdStrike descobrimos sobre a atividade do agente da ameaça.

Os únicos sistemas de produção que o agente da ameaça conseguiu acessar usando as credenciais roubadas foi o nosso ambiente Atlassian.  Analisando as páginas wiki que ele acessou, problemas de banco de dados de bugs e repositórios de código-fonte, parece que ele estava procurando informações sobre a arquitetura, segurança e gerenciamento de nossa rede global; sem dúvida com o objetivo de ganhar uma posição mais profunda.  Por causa disso, decidimos que era necessário um grande esforço para fortalecer ainda mais nossos protocolos de segurança para evitar que o agente da ameaça conseguisse obter essa posição caso tivéssemos deixado passar algo em nossos arquivos de log.

Nosso objetivo era evitar que o invasor usasse as informações técnicas sobre as operações de nossa rede como um caminho para entrar novamente.  Embora acreditássemos, e posteriormente confirmamos, que o invasor tinha acesso limitado, empreendemos um esforço abrangente para alternar cada credencial de produção (mais de 5.000 credenciais individuais), segmentar fisicamente sistemas de teste e preparação, realizar triagens forenses em 4.893 sistemas, recriar imagens e reinicializar todas as máquinas em nossa rede global, incluindo todos os sistemas que o agente da ameaça acessou e todos os produtos Atlassian (Jira, Confluence e Bitbucket).

O agente da ameaça também tentou acessar um servidor de console em nosso novo data center, ainda não em produção, em São Paulo.  Todas as tentativas de obter acesso foram infrutíferas.  Para garantir que esses sistemas sejam 100% seguros, os equipamentos do data center brasileiro foram devolvidos aos fabricantes.  As equipes forenses dos fabricantes examinaram todos os nossos sistemas para garantir que nenhum acesso ou persistência foi obtido.  Nada foi encontrado, mas substituímos o hardware mesmo assim.

Também procuramos pacotes de software que não tenham sido atualizados, contas de usuários que possam ter sido criadas e contas ativas de funcionários não utilizadas; procuramos segredos que poderiam ter sido deixados em tickets do Jira ou no código-fonte, examinamos e excluímos todos os arquivos HAR carregados no wiki, caso contivessem tokens de qualquer tipo. Em caso de dúvida, presumimos o pior e fizemos alterações para garantir que qualquer coisa que o agente da ameaça conseguiu acessar não estaria mais em uso e, portanto, não teria mais valor para ele.

Cada membro da equipe foi incentivado a apontar áreas que o agente da ameaça poderia ter tocado, para que pudéssemos examinar os arquivos de log e determinar a extensão do acesso do agente da ameaça.  Ao incluir um número tão grande de pessoas em toda a empresa, pretendemos não deixar pedra sobre pedra em busca de evidências de acesso ou alterações que precisassem ser feitas para melhorar a segurança.

O esforço imediato do “Code Red” terminou em 5 de janeiro, mas o trabalho continua em toda a empresa em torno do gerenciamento de credenciais, proteção de software, gerenciamento de vulnerabilidades, alertas adicionais e muito mais.

O ataque começou em outubro com o comprometimento do Okta, mas o agente da ameaça só começou a atacar nossos sistemas usando essas credenciais do comprometimento do Okta em meados de novembro.

O cronograma a seguir mostra os principais eventos:

Já escrevemos sobre isso antes, mas, em resumo, fomos (pela segunda vez) vítimas de um comprometimento dos sistemas do Okta, que resultou no acesso de um agente de ameaça a um conjunto de credenciais. Essas credenciais deveriam todas ter sido alteradas.

Infelizmente, não conseguimos alterar um token de serviço e três contas de serviço (entre milhares) de credenciais que vazaram durante o comprometimento do Okta.

Um deles era um token de serviço Moveworks que concedia acesso remoto ao nosso sistema Atlassian.  A segunda credencial era uma conta de serviço usada pelo aplicativo Smartsheet baseado em SaaS que tinha acesso administrativo à nossa instância Atlassian Jira, a terceira conta era uma conta de serviço Bitbucket usada para acessar nosso sistema de gerenciamento de código-fonte e a quarta era um ambiente AWS que não tinha acesso à rede global e a nenhum dado confidencial ou de cliente.

O token de serviço e as três contas não foram alterados porque erroneamente se acreditou que não eram utilizados.  Isso estava incorreto e foi assim que o agente da ameaça entrou em nossos sistemas e ganhou persistência em nossos produtos Atlassian.  Observe que isso não foi de forma alguma um erro por parte da Atlassian, AWS, Moveworks ou Smartsheet.  Estas eram apenas credenciais que não deixamos de alterar.

Nossos registros mostram que o agente da ameaça começou a sondar e realizar o reconhecimento de nossos sistemas a partir de 14 de novembro, procurando uma maneira de usar as credenciais e quais sistemas estavam acessíveis.  Ele tentou fazer login em nossa instância do Okta e teve acesso negado.  Ele tentou acessar o painel da Cloudflare e teve acesso negado.

Além disso, o agente da ameaça acessou um ambiente AWS que é usado para alimentar o marketplace de aplicativos da Cloudflare.  Este ambiente foi segmentado sem acesso à rede global ou aos dados de clientes.  A conta de serviço para acessar este ambiente foi revogada e validamos a integridade do ambiente.

O agente da ameaça acessou com sucesso o Atlassian Jira e o Confluence em 15 de novembro usando o token de serviço Moveworks para se autenticar por meio de nosso gateway e, em seguida, usou a conta de serviços Smartsheet para obter acesso ao pacote Atlassian.  No dia seguinte, ele começou a procurar informações sobre a configuração e o gerenciamento da nossa rede global e acessou vários tickets do Jira.

O agente da ameaça pesquisou no wiki coisas como acesso remoto, segredo, segredo do cliente, openconnect, cloudflared e token.  Ele acessou 36 tickets do Jira (de um total de 2.059.357 tickets) e 202 páginas wiki (de um total de 194.100 páginas).

O agente da ameaça acessou tickets do Jira sobre gerenciamento de vulnerabilidades, rotação de segredos, desvio de MFA, acesso à rede e até mesmo nossa resposta ao próprio incidente do Okta.

As pesquisas no wiki e as páginas acessadas sugerem que o agente da ameaça estava muito interessado em todos os aspectos do acesso aos nossos sistemas: redefinições de senha, acesso remoto, configuração, nosso uso do Salt, mas ele não tinha como alvo os dados ou configurações de clientes.

O agente da ameaça usou a credencial do Smartsheet para criar uma conta Atlassian que parecia um usuário normal da Cloudflare.  Ele adicionou esse usuário a vários grupos no Atlassian para que tivesse acesso persistente ao ambiente Atlassian caso a conta de serviço do Smartsheet fosse removida.

Durante esse período, o invasor fez uma pausa no acesso aos nossos sistemas (além de aparentemente testar brevemente se ainda tinha acesso) e retornou pouco antes do Dia de ação de graças.

Como a conta de serviço do Smartsheet tinha acesso administrativo ao Atlassian Jira, o agente da ameaça conseguiu instalar o Sliver Adversary Emulation Framework, que é uma ferramenta e estrutura amplamente utilizada por equipes vermelhas e invasores para habilitar “C2” (comando e controle), estabelecendo uma conexão persistente e discreta a um computador no qual está instalado. O Sliver foi instalado utilizando o plugin ScriptRunner for Jira.

Isso permitiu que ele tivesse acesso contínuo ao servidor Atlassian, e ele usou isso para tentar movimento lateral.  Com esse acesso, o agente da ameaça tentou obter acesso a um servidor de console que não estava em produção em nosso data center de São Paulo, Brasil, devido a uma ACL não aplicada.  O acesso foi negado e ele não conseguiu acessar nenhuma rede global.

No dia seguinte, o agente da ameaça visualizou 120 repositórios de código (de um total de 11.904 repositórios).  Dos 120, o agente da ameaça usou o recurso de arquivo Atlassian Bitbucket git em 76 repositórios para baixá-los para o servidor Atlassian e, embora não tenhamos conseguido confirmar se eles foram ou não exfiltrados, decidimos tratá-los como tendo sido exfiltrados.

Os 76 repositórios de código-fonte estavam quase todos relacionados ao funcionamento dos backups, como a rede global é configurada e gerenciada, como funciona a identidade na Cloudflare, acesso remoto e nosso uso do Terraform e Kubernetes.  Um pequeno número de repositórios continha segredos criptografados que foram alterados imediatamente, embora eles próprios estivessem fortemente criptografados.

Nos concentramos particularmente nesses 76 repositórios de código-fonte para procurar segredos incorporados (os segredos armazenados no código foram alterados), vulnerabilidades e maneiras pelas quais um invasor poderia usá-los para montar um ataque subsequente.  Este trabalho foi realizado prioritariamente pelas equipes de engenharia de toda a empresa como parte do “Code Red”.

Como uma empresa de SaaS, há muito acreditamos que o nosso código-fonte em si não é tão precioso quanto o código-fonte das empresas de software que distribuem software aos usuários finais.  Na verdade, abrimos uma grande quantidade de nosso código-fonte e falamos abertamente em nosso blog sobre algoritmos e técnicas que usamos.  Portanto, nosso foco não estava em alguém ter acesso ao código-fonte, mas se esse código-fonte continha segredos incorporados (como uma chave ou token) e vulnerabilidades.

Nossa equipe de segurança foi alertada sobre a presença do agente da ameaça às 16h e desativou a conta de serviço do Smartsheet 35 minutos depois.  48 minutos depois, a conta de usuário criada pelo agente da ameaça foi encontrada e desativada.  Aqui está o cronograma detalhado das principais ações tomadas para bloquear o agente da ameaça assim que o primeiro alerta foi acionado.

15h58 - O agente da ameaça adiciona a conta de serviço do Smartsheet a um grupo de administradores.16h - Alerta automático sobre a alteração às 15h58 para nossa equipe de segurança.16h12 - A Cloudflare SOC começa a investigar o alerta.16h35 - Conta de serviço Smartsheet desativada pela Cloudflare SOC.17h23 - A conta de usuário Atlassian criada pelo agente da ameaça é encontrada e desativada.17h43 - Incidente interno da Cloudflare declarado.21:31 - Regras de firewall implementadas para bloquear os endereços de IP conhecidos do agente da ameaça.

10:44 - Última atividade conhecida do agente da ameaça.11:59 - Sliver removido.

Ao longo deste cronograma, o agente da ameaça tentou acessar uma infinidade de outros sistemas na Cloudflare, mas falhou devido aos nossos controles de acesso, regras de firewall e uso de chaves de segurança rígidas aplicadas por meio de nossas próprias ferramentas Zero Trust.

Para ser claro, não vimos nenhuma evidência de que o agente da ameaça obteve acesso à nossa rede global, data centers, chaves SSL, bancos de dados de clientes ou informações de configuração, o Cloudflare Workers implantado por nós ou por clientes, modelos de IA, infraestrutura de rede ou qualquer um de nossos armazenamentos de dados como Workers KV, R2 ou Quicksilver. O acesso dele foi limitado ao pacote Atlassian e ao servidor no qual nosso Atlassian é executado.

Uma grande parte do nosso esforço “Code Red” foi entender ao que o agente da ameaça teve acesso e o que tentou acessar.  Ao observar o registro em log nos sistemas, conseguimos rastrear tentativas de acesso às nossas métricas internas, configuração de rede, sistema de compilação, sistemas de alerta e sistema de gerenciamento de liberação.  Com base na nossa análise, nenhuma das tentativas dele de acessar estes sistemas foi bem sucedida.  De forma independente, a CrowdStrike realizou uma avaliação do escopo e extensão da atividade do agente da ameaça, não identificando atividades que tínhamos deixado passar, e concluiu que a última evidência de atividade de ameaça foi em 24 de novembro às 10:44.

Estamos confiantes de que, entre a nossa investigação e a da CrowdStrike, compreendemos perfeitamente as ações do autor da ameaça e que elas se limitaram aos sistemas nos quais observamos sua atividade.

Este foi um incidente de segurança envolvendo um agente sofisticado, provavelmente um estado-nação, que agiu de forma calculada e metódica.  Os esforços que desenvolvemos garantem que o impacto contínuo do incidente foi limitado e que estamos bem preparados para evitar quaisquer ataques sofisticados no futuro.  Isso exigiu os esforços de grande parte da equipe de engenharia da Cloudflare e, por mais de um mês, essa foi a maior prioridade da Cloudflare.  Toda a equipe da Cloudflare trabalhou para garantir que nossos sistemas estivessem seguros, que o acesso do agente da ameaça fosse conhecido, para corrigir prioridades imediatas (como rotação de credenciais em massa) e para criar um plano de trabalho de longa duração para melhorar nossa segurança geral com base em áreas para melhorias descobertas durante este processo.

Somos extremamente gratos a todos na Cloudflare que responderam rapidamente durante o feriado de Ação de Graças para realizar uma análise inicial e bloquear o agente da ameaça, e a todos aqueles que contribuíram para esse esforço.  Seria impossível nomear todos os envolvidos, mas suas longas horas de trabalho e dedicação tornaram possível realizar uma análise e uma mudança essencial na segurança da Cloudflare, mantendo nossa rede global e o serviço de nossos clientes funcionando.

Agradecemos à CrowdStrike por estar imediatamente disponível para realizar uma avaliação independente. Agora que o relatório final foi concluído, estamos confiantes em nossa análise interna e na correção da intrusão e disponibilizamos esta postagem no blog.

IOCs

Abaixo estão as indicações de comprometimento (IOCs) que observamos deste agente de ameaça.  Estamos publicando tais indicações para que outras organizações, e especialmente aquelas que possam ter sido afetadas pela violação do Okta, possam pesquisar seus logs para confirmar se o mesmo agente da ameaça não acessou seus sistemas.

.tg {border-collapse:collapse;border-color:#ccc;border-spacing:0;} .tg td{background-color:#fff;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;overflow:hidden;padding:10px 5px;word-break:normal;} .tg th{background-color:#f0f0f0;border-color:#ccc;border-style:solid;border-width:1px;color:#333; font-family:Arial, sans-serif;font-size:14px;font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;} .tg .tg-c3ow{border-color:inherit;text-align:center;vertical-align:top} .tg .tg-0pky{border-color:inherit;text-align:left;vertical-align:top}

Indicador

Tipo de indicador

SHA256

Descrição

193.142.58[.]126

IPv4

N/A

Agente da ameaça principalInfraestrutura, de propriedade daM247 Europe SRL (Bucareste,Romênia

198.244.174[.]214

IPv4

N/A

Servidor Sliver C2, propriedade daOVH SAS (Londres, Inglaterra)

idowall[.].com

Domínio

N/A

Infraestrutura servindo conteúdo maliciosoPayload

jvm-agent

Nome do arquivo

bdd1a085d651082ad567b03e5186d1d46d822bb7794157ab8cce95d850a3caaf

Conteúdo malicioso do Sliver