Clientes da Oracle confirmam que dados vazados em violação da nuvem são autênticos

• A Oracle negou a invasão do servidor de login SSO da Oracle Cloud e o roubo de dados de 6 milhões de contas, mas confirmações com várias empresas verificaram que as amostras de dados compartilhadas pelo agente da ameaça são válidas
• Um indivíduo chamado 'rose87168' afirmou ter invadido servidores da Oracle Cloud e começou a vender dados de autenticação e senhas criptografadas de 6 milhões de usuários. Esse agente da ameaça afirma que pode descriptografar as senhas SSO e LDAP roubadas e se ofereceu para compartilhar os dados com quem ajudasse a recuperá-las.
• O agente da ameaça divulgou vários arquivos de texto contendo bancos de dados, dados LDAP e uma lista de 140.621 domínios de empresas e órgãos governamentais supostamente afetados pela invasão. Alguns domínios de empresas parecem ser para testes, e há vários domínios por empresa.
• O agente da ameaça compartilhou com o BleepingComputer uma URL do Archive.org de um arquivo de texto hospedado no servidor "login.us2.oraclecloud.com". Esse arquivo indica que o agente da ameaça conseguiu criar arquivos em um servidor da Oracle, sugerindo uma invasão real.
• No entanto, a Oracle negou que tenha havido uma invasão da Oracle Cloud e não respondeu a perguntas adicionais sobre o incidente. A Oracle disse ao BleepingComputer: "Não houve nenhuma invasão da Oracle Cloud. As credenciais publicadas não são da Oracle Cloud. Nenhum cliente da Oracle Cloud sofreu invasão ou perda de dados".
• Essa negativa contradiz as descobertas do BleepingComputer. O BleepingComputer recebeu amostras adicionais do agente da ameaça e entrou em contato com as empresas relacionadas para verificar a autenticidade dos dados. Representantes de empresas que confirmaram os dados sob condição de anonimato disseram que informações identificáveis, como nomes exibidos no LDAP, endereços de e-mail e nomes, estavam corretas e pertenciam a elas.
• O agente da ameaça compartilhou com o BleepingComputer trocas de e-mail com a Oracle. Em um dos e-mails, o agente da ameaça relatou o comprometimento do servidor para o e-mail de segurança da Oracle ([e-mail]).
• Em outra troca de e-mails, o agente da ameaça compartilhou uma conversa com alguém usando um endereço de e-mail @proton.me da Oracle. O BleepingComputer não conseguiu verificar a identidade desse endereço nem a autenticidade da troca de e-mails, então removeu o endereço.
• A empresa de cibersegurança Cloudsek encontrou uma URL do Archive.org mostrando que o servidor "login.us2.oraclecloud.com" estava executando Oracle Fusion Middleware 11g em 17 de fevereiro de 2025. A Oracle tirou esse servidor do ar depois que a notícia da invasão foi publicada.
• Essa versão do software é afetada por uma vulnerabilidade rastreada como CVE-2021-35587, que pode permitir que um invasor não autenticado comprometa o Oracle Access Manager. O agente da ameaça afirma que essa vulnerabilidade foi usada para invadir o servidor da Oracle.
• O BleepingComputer enviou vários e-mails à Oracle sobre essas informações, mas não recebeu resposta.

[GN⁺]

Comentários do Hacker News

• A BleepingComputer confirmou com várias empresas que as amostras de dados compartilhadas pelo agente de ameaça são válidas
• rose87168 compartilhou com a BleepingComputer uma URL do Archive.org, que contém um arquivo de texto hospedado no servidor login.us2.oraclecloud.com. Esse arquivo indica que o agente de ameaça conseguiu criar arquivos em um servidor da Oracle, sugerindo uma invasão real
• A Oracle deveria ter reconhecido a validade desde o início
• Não há punição real por uma invasão, e mentir pode gerar um impacto de PR pior do que a própria invasão
• Só o fato de a Oracle ter hospedado um gateway de login em um produto com uma vulnerabilidade conhecida desde 2021 já é bastante preocupante
• É típico da Oracle negar a invasão apesar das evidências claras
• Fico curioso sobre o perfil demográfico de quem usa os produtos de nuvem da Oracle, e as histórias sobre eles sugerem sofrimento de longo prazo
• Este incidente não ajuda a aumentar a confiança nos produtos deles
• Se você já operou Oracle, entenderia por que isso não foi corrigido. Eles não facilitam as coisas
• O agente de ameaça afirma ter recebido de alguém usando um endereço de e-mail @proton.me da Oracle a mensagem: "Recebi seu e-mail. Vamos usar este e-mail daqui para frente. Me avise quando receber."
• E-mail é uma das fontes que a maioria das empresas de capital aberto precisa reter por um período de tempo (7 anos?). Provavelmente foi uma tentativa de evitar registros
• Infelizmente, vazamentos de dados não afetam o preço das ações. É improvável que empresas que usam produtos Oracle migrem imediatamente
• Vendas futuras podem ser afetadas, e algumas empresas menores podem migrar. Mas a Oracle vai minimizar isso o máximo possível
• "Negar. Adiar. Defender." não é apenas um slogan de seguro de saúde
• Fico curioso se dados de clientes do Oracle Opera Cloud e do Oracle NetSuite Cloud também foram roubados. Muitos hotéis no mundo todo usam Opera + NetSuite
• Trabalhei em uma das 3 maiores corretoras de seguros há 10 anos, quando as apólices “cyber” estavam sendo introduzidas. Fico curioso sobre quem subscreveu a apólice da Oracle e quanto isso custou nessa torre. Eles não tinham apólice? Espero que o D&O possa cobrir processos de acionistas. Há espaço para interpretação das regras, dada a proximidade com o governo
• A Tyler Technologies culpou o Judyrecords.com por expor casos sigilosos na Califórnia e alegou que foi uma violação de segurança por causa do sistema defeituoso de ofuscação deles. Fugindo da responsabilidade
• A regra nº 1 de uma invasão é não usar a palavra invasão em e-mails. Então imagino que tenham discutido isso fora do domínio deles
• Fico curioso há quanto tempo a Oracle vem negando isso. 3 dias?
• Larry e Trump são próximos. A Oracle vai demitir (ou deveria demitir) os CISOs de OCI e SaaS