Cloudflare hackeado

Cloudflare hackeado por suposto ator de ameaça patrocinado pelo Estado. 

A empresa de segurança da Web Cloudflare revelou dia 01 de fevereiro que um agente de ameaça usou credenciais roubadas para obter acesso a alguns de seus sistemas internos.

O incidente foi descoberto em 23 de novembro, nove dias depois que o ator da ameaça, supostamente patrocinado pelo Estado, usou credenciais comprometidas no hack Okta de outubro de 2023 para acessar o wiki interno e o banco de dados de bugs da Cloudflare.

As informações de login roubadas, um token de acesso e três credenciais de conta de serviço, não foram alternadas após o incidente do Okta, permitindo que os invasores investigassem e realizassem o reconhecimento dos sistemas Cloudflare a partir de 14 de novembro, explica a empresa de segurança .

De acordo com a Cloudflare, os invasores conseguiram acessar um ambiente AWS, bem como Atlassian Jira e Confluence, mas a segmentação da rede os impediu de acessar sua instância Okta e o painel Cloudflare.

Com acesso ao pacote Atlassian, o ator da ameaça começou a procurar informações na rede Cloudflare, pesquisando no wiki por “coisas como acesso remoto, segredo, segredo do cliente, openconnect, cloudflared e token”. No total, foram acessados ​​36 tickets Jira e 202 páginas wiki.

No dia 16 de novembro, os invasores criaram uma conta Atlassian para obter acesso persistente ao ambiente e, no dia 20 de novembro, retornaram para verificar se ainda tinham acesso.

Em 22 de novembro, o agente da ameaça instalou o Sliver Adversary Emulation Framework, obtendo acesso persistente ao servidor Atlassian, que foi então usado para movimentação lateral. Eles tentaram acessar um servidor de console que não era de produção em um data center de São Paulo, Brasil, que ainda não está operacional.

Os invasores visualizaram 120 repositórios de código e baixaram 76 deles para o servidor Atlassian, mas não os exfiltraram.

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 alternados imediatamente, embora eles próprios estivessem fortemente criptografados”, observa Cloudflare.

Os invasores usaram uma conta de serviço Smartsheet para acessar o pacote Atlassian da Cloudflare, e a conta foi encerrada em 23 de novembro, 35 minutos após a identificação do acesso não autorizado. A conta de usuário criada pelo invasor foi encontrada e desativada 48 minutos depois.

A Cloudflare afirma que também implementou regras de firewall para bloquear os endereços IP conhecidos dos invasores e que o Sliver Adversary Emulation Framework foi removido em 24 de novembro.

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”, afirma a empresa.

De acordo com a Cloudflare, não encontrou nenhuma evidência de que o ator da ameaça acessou sua rede global, banco de dados de clientes, informações de configuração, data centers, chaves SSL, funcionários implantados por clientes ou qualquer outra informação, exceto dos “dados da suíte Atlassian e do servidor”. no qual nosso Atlassian funciona”.

Em 24 de novembro, a Cloudflare também encarregou vários funcionários técnicos de melhorar a segurança e validar que o autor da ameaça não poderia mais acessar os sistemas da empresa.

Além disso, continuamos investigando cada sistema, conta e registro para garantir que o autor da ameaça não tivesse acesso persistente e que entendíamos completamente quais sistemas eles haviam tocado e quais haviam tentado acessar”, observa a empresa.

De acordo com a Cloudflare, mais de 5.000 credenciais de produção individuais foram alternadas após o incidente, cerca de 5.000 sistemas foram triados, os sistemas de teste e preparação foram segmentados fisicamente e todas as máquinas da rede global da Cloudflare foram recriadas e reinicializadas.

Os equipamentos do data center de São Paulo, embora não tenham sido acessados, foram devolvidos aos fabricantes para inspeção e substituídos, embora nenhuma evidência de comprometimento tenha sido descoberta.

O objetivo do ataque, diz Cloudflare, era obter informações sobre a infraestrutura da empresa, o que provavelmente ganharia uma posição mais profunda. A CrowdStrike realizou uma investigação separada sobre o incidente, mas não descobriu nenhuma evidência de comprometimento adicional.

Estamos confiantes de que, entre nossa investigação e a da CrowdStrike, entendemos perfeitamente as ações do ator da ameaça e que elas estavam limitadas aos sistemas nos quais vimos sua atividade”, observa Cloudflare.

Fonte: SecurityWeek

 

Veja também:

About mindsecblog 2774 Articles
Blog patrocinado por MindSec Segurança e Tecnologia da Informação Ltda.

4 Trackbacks / Pingbacks

  1. Cyberbulling: o papel dos pais e a responsabilidade das plataformas | Minuto da Segurança da Informação
  2. 5 etapas para melhorar sua postura de segurança no Microsoft Teams | Minuto da Segurança da Informação
  3. O Cérebro do seu roteador, por que atualizar! | Minuto da Segurança da Informação
  4. Novas falhas de desvio de autenticação Wi-Fi expõem redes | Minuto da Segurança da Informação

Deixe sua opinião!