As Amostras Vazadas

A CloudSEK divulgou que recebeu e analisou uma amostra de 10 mil linhas contendo:

• Usernames corporativos

• Hashes e hashes salted

• Chaves de API

• Arquivos de configuração

• Entradas de acesso interno a aplicações de tenants

Além disso, havia metadados do Oracle Enterprise Manager, como arquivos JPS, que são usados na gestão de identidade e permissões no ecossistema Oracle.

Essa amostra, enviada para empresas afetadas, teve confirmação de veracidade por pelo menos 3 corporações diferentes, segundo CloudSEK.

Oracle Nega, Mas Evidências Apontam o Contrário

A Oracle, em comunicado oficial publicado no dia 25 de março de 2025, afirmou que “não há evidências de violação de segurança em sua infraestrutura de nuvem”. Segundo a empresa:

“As credenciais e informações divulgadas não são provenientes de nossos sistemas, nem representam risco aos nossos clientes.”

Entretanto, especialistas em segurança como Vickram Singh (CloudSEK) e Jake Williams (ex-NSA, atualmente na Rendition Infosec) argumentam que:

• A estrutura dos dumps indica dados coletados diretamente de servidores da Oracle

• Alguns arquivos correspondem a endpoints reais da Oracle Cloud

• A ausência de MFA e segregação adequada pode ter facilitado a extração

Fontes adicionais:

• Clavis Segurança da Informação

• The Register

• SempreUpdate

Novas Evidências e Atualizações Reforçam a Veracidade do Ataque

No dia 24 de março de 2025, Alon Gal, CTO da empresa de cibersegurança Hudson Rock, publicou em seu LinkedIn que os dados vazados da Oracle Cloud são legítimos. Segundo ele, o próprio atacante “rose87168” enviou diretamente à empresa uma amostra contendo 10 mil credenciais.

A Hudson Rock entrou em contato com alguns dos clientes listados no sample e colheu as seguintes respostas:

• Três empresas confirmaram que os dados pertencem a seus ambientes em produção.

• Dois clientes validaram os tenant IDs.

• Todas afirmaram que as contas listadas têm acesso a dados sensíveis.

Além disso, Alon Gal afirma que o atacante mencionou ter explorado a mesma vulnerabilidade indicada pela CloudSEK: a CVE-2021-35587.

O próprio “rose87168” também publicou um vídeo em uma rede social como suposta prova do ataque, exibindo material interno da Oracle datado de 2019. Embora o vídeo ainda gere controvérsias, ele reforça a narrativa de que houve acesso a conteúdos internos.

Além disso, o atacante declarou publicamente que tentou contatar a Oracle antes de tornar o caso público, mas não recebeu resposta.

CloudSEK Publica Nova Análise Técnica

Em uma segunda parte da sua análise, a empresa CloudSEK compartilhou evidências técnicas importantes:

• Encontraram um repositório oficial da Oracle no GitHub (oracle-quickstart) com menções diretas à URL login.us2.oraclecloud.com, usado para autenticação OAuth2, geração de tokens e headers de autorização.

• Vários repositórios públicos continham credenciais hardcoded (em texto claro) apontando para o mesmo endpoint.

• A URL login.us2.oraclecloud.com foi referenciada na documentação oficial da OneLogin e da parceira Rainfocus, ambas indicando uso em ambientes de produção.

Isso fortalece a conclusão de que o subdomínio em questão não é apenas legítimo, como também estava exposto com funções críticas em produção.

Como o Ataque à Oracle Cloud Foi Executado

Após o surgimento do hacker "rose87168" e a revelação do vazamento de dados envolvendo a Oracle Cloud, a questão que passou a ecoar entre pesquisadores e especialistas foi: como ele fez isso?

Destrinchamos o método de ataque, explorando desde a identificação da vulnerabilidade, o provável passo a passo da exploração, até as ações pós-exfiltração de dados.

A Falha Explorada: CVE-2021-35587

A vulnerabilidade CVE-2021-35587 foi apontada como o vetor de ataque mais provável. Ela afeta o Oracle Access Manager (OAM) – componente do Oracle Fusion Middleware, utilizado por milhares de empresas para gerenciar autenticação federada e SSO (Single Sign-On).

Detalhes da CVE:

• Gravidade: 9.8 (crítica)

• Tipo de falha: RCE (Remote Code Execution)

• Vetor: Deserialização insegura em objetos Java (uma velha conhecida dos hackers)

• Pré-requisitos: Nenhuma autenticação necessária — ataque via HTTP

• Exploração: Envio de payloads maliciosos manipulando cabeçalhos e cookies de sessão para executar código no servidor vulnerable

Fonte: NIST CVE-2021-35587

Infraestrutura Vulnerável: Oracle Cloud e o Fusion Middleware

O alvo específico parece ter sido o endpoint:

Esse domínio é um dos principais pontos de autenticação da Oracle Cloud, usado para:

• Autenticação de clientes via SSO

• Redirecionamento de sessões

• Emissão de tokens de identidade

• Comunicação com servidores LDAP para verificação de identidade

Segundo registros do Internet Archive, esse servidor estava executando uma versão legada do Oracle Fusion Middleware 11g, já conhecida por falhas severas de segurança. A Oracle deixou de oferecer suporte completo a essa versão desde 2021, tornando-a um alvo perfeito para exploração.

Etapas Técnicas Prováveis do Ataque

1. Reconhecimento

O atacante fez um mapeamento da estrutura de endpoints da Oracle Cloud:

• login.us2.oraclecloud.com

• login.uk.oraclecloud.com

• login.jp.oraclecloud.com

Com esse mapeamento, "rose87168" descobriu que o domínio login.us2.oraclecloud.com respondia com headers e páginas que indicavam o uso do Oracle Access Manager 11g.

2. Exploração via CVE-2021-35587

Com base no exploit público da CVE-2021-35587 (e seus derivados), o atacante teria enviado um payload especialmente formatado via requisição HTTP:

Esse payload pode ter criado um shell reverso ou permitido execução direta de comandos no servidor, sem autenticação, devido à falha na verificação de objetos serializados.

3. Acesso ao Backend

Após ganhar execução remota (RCE), o atacante:

• Listou diretórios internos

• Acessou configurações sensíveis da aplicação

• Dumpou arquivos JKS contendo chaves privadas

• Extraíu arquivos de configuração contendo hashes LDAP e senhas criptografadas do SSO

Possivelmente, o servidor vulnerável tinha permissões internas para acessar múltiplos tenants (multi-tenancy mal configurado), permitindo a coleta de dados em larga escala.

O Que Foi Exfiltrado?

O pacote de dados à venda incluía:

• 6.032.408 registros de usuários autenticados

• Hashes LDAP com salt

• Chaves privadas de tenants

• Arquivos .jks, .jps, .cfg, .pem e .json

• Dumps parciais do Oracle Enterprise Manager

• Metadados de sessões SSO

Alguns registros exibiam a origem do tenant, sugerindo que o atacante usou as permissões do sistema principal para “pivotar” para os dados de clientes internos.

Pós-Exploração: Venda e Extorsão

Depois da coleta, "rose87168" publicou:

• Anúncios com previews dos dados (10.000 linhas gratuitas para teste)

• Requisições públicas de ajuda para descriptografar as senhas SSO

• Ofertas de "remoção" de dados de empresas específicas mediante pagamento

Esse comportamento indica não só motivação financeira, mas confiança no impacto e na veracidade do vazamento.

Falhas Críticas na Arquitetura

Este ataque expôs diversas fraquezas:

1. Falta de atualização do Oracle Fusion Middleware (versão 11g, obsoleta)

2. Ausência de WAF (Web Application Firewall) eficaz

3. Falta de segmentação entre tenants (falha de isolamento)

4. Chaves e senhas sensíveis armazenadas no mesmo servidor exposto

5. Não aplicação de patch para CVE-2021-35587

Tentativa de Contenção

Mesmo após o incidente ganhar visibilidade, a Oracle continuou negando violação. A comunidade reagiu com desconfiança, especialmente após empresas impactadas confirmarem a veracidade das amostras. Até o final de março, a Oracle não havia publicado nenhum CVE próprio relacionado, nem admitido que os endpoints estavam vulneráveis — uma abordagem questionada por muitos especialistas.

A análise técnica mostra um ataque limpo, direto e com uso de vulnerabilidade pública e crítica (CVE-2021-35587). Este não foi um “zero-day”, nem um ataque de cadeia de suprimentos ultra sofisticado — foi negligência básica de segurança combinada com inteligência ofensiva e conhecimento técnico do atacante.

A Oracle pode até tentar minimizar o incidente, mas os dados falam por si. Uma infraestrutura gigante, com recursos desatualizados e endpoints críticos abertos, tornou-se o alvo ideal para um ataque com impacto massivo.

Quando a Nuvem Vira um Furacão

O que parecia ser apenas “mais um vazamento de dados” se tornou uma bomba geopolítica e corporativa. O ataque realizado por rose87168 à Oracle Cloud provocou reações em governos, clientes empresariais e investidores — e pode alterar significativamente os rumos da segurança cibernética em ambientes de infraestrutura como serviço (IaaS).

Impacto nas Empresas e Tenants

A Oracle atende milhares de corporações globais, incluindo:

• Governos federais e estaduais (inclusive dos EUA)

• Setores financeiros (bancos e fintechs)

• Indústrias de energia, telecom e saúde

• Multinacionais com ambientes Oracle ERP e SaaS integrados à OCI

Com a violação de arquivos de autenticação, chaves JKS e metadados do Oracle Enterprise Manager, muitas dessas empresas tiveram que:

• Revogar chaves e certificados

• Reconfigurar integrações de SSO e LDAP

• Suspender autenticações federadas temporariamente

• Investigar e conter pivôs internos a partir dos dados exfiltrados

De acordo com a Bloomberg, várias organizações federais americanas relataram exposições internas causadas indiretamente pelo ataque à Oracle Cloud.

FBI, Governo e Pressão Política

No dia 28 de março de 2025, a Bloomberg confirmou que o FBI iniciou uma investigação formal sobre o incidente, sugerindo possível risco à infraestrutura crítica dos EUA.

O ataque à Oracle ocorre em um contexto de tensões geopolíticas digitais, especialmente entre EUA e grupos organizados ligados a países como China, Rússia, Irã e Coreia do Norte. Ainda não se sabe se rose87168 atua de forma independente ou como parte de uma operação de Estado (APT).

Especialistas levantam hipóteses:

• O padrão do ataque não indica amadorismo, mas também não tem as marcas clássicas de APTs (sem stealth, sem comprometimento lateral prolongado).

• A motivação parece financeira e ego-driven – o hacker inclusive usou linguagem provocativa nos fóruns, demonstrando certo orgulho da façanha.

Reação do Mercado

Após os rumores se tornarem públicos e o FBI entrar na jogada:

• As ações da Oracle ($ORCL) caíram cerca de 6,7% em uma semana.

• Grandes clientes começaram a exigir auditorias privadas nos contratos de nuvem.

• Concorrentes como AWS e Microsoft Azure exploraram o caso em campanhas de marketing focadas em "segurança como diferencial".

Implicações Técnicas para o Futuro da Nuvem

O incidente gera ondas longas no ecossistema cloud:

1. Fim da confiança cega em fornecedores

Empresas agora exigem:

• Visibilidade de segurança (dashboards em tempo real)

• Acesso a logs brutos

• Transparência em incidentes

2. Auditorias obrigatórias em ambientes federados

Soluções como o Oracle Access Manager perderam credibilidade. Muitas empresas estão migrando para:

• Autenticação baseada em OAuth2 e OpenID Connect com MFA obrigatória

• Desacoplamento de serviços críticos internos da autenticação em nuvem

3. Fim da tolerância com legados

A principal falha foi o uso do Oracle Fusion Middleware 11g, desatualizado há anos. A falha foi pública desde 2021. Esse tipo de complacência agora é inaceitável.

Questões Abertas

• Por que a Oracle ainda utilizava um software legado como o 11g em endpoints de autenticação pública?

• Por que a empresa negou o incidente mesmo diante de provas técnicas validadas?

• Haverá responsabilização legal e judicial das partes envolvidas?

• Quem, de fato, é "rose87168"? Até o momento, o autor do ataque não foi identificado, nem se manifestou desde o dia 26/03.

Conclusão: Um Caso para a História da Cibersegurança

Este ataque se torna um marco na história dos incidentes em nuvem, pela combinação explosiva de:

• Uso de vulnerabilidade conhecida e não corrigida (CVE-2021-35587)

• Acesso a dados de múltiplos tenants com privilégios indevidos

• Resposta fraca e negacionista da empresa atingida

• Vasta repercussão técnica, comercial e política

Se você acha que isso foi só “mais um vazamento”, pense de novo.

A Oracle sentiu. O mercado sentiu. E o mundo da segurança cibernética está agora mais alerta do que nunca para o que pode acontecer quando um serviço em nuvem com alcance global se torna um único ponto de falha.

Referências utilizadas neste artigo:

• CloudSEK – Análise do Incidente

• The Register – Oracle Breach Coverage

• Clavis – Investigação Brasileira

• Bloomberg – FBI Entra na Jogada

• NIST - CVE-2021-35587