Source: JHVEPhoto via Shutterstock
After weeks of carefully worded denials, Oracle on April 7 appears to have notified an unknown number of its customers of a breach involving two servers containing usernames and passwords.
A supposed copy of Oracle's breach notification appeared on social media this week, but the company has yet to confirm to Dark Reading whether it indeed issued the advisory to customers — or how widely disseminated it was.
Hacker Accessed Obsolete Oracle Servers
The brief note, like the company's previous statements on the issue, begins by "unequivocally" denying any breach of Oracle Cloud Infrastructure (OCI) servers, or of any OCI customer environments or of their data. However, it then goes on to add that a hacker had indeed accessed and published data obtained from two servers that were never part of OCI.
Oracle described the affected servers as "obsolete" and the data that the hacker accessed as useless. "The hacker did not expose usable passwords because the passwords on those two servers were either encrypted and/or hashed," the notification said. "Therefore, the hacker was not able to access any customer environments or customer data."
The notification advised recipients to get in touch with Oracle customer support if they had questions but offered no suggestions on whether or how organizations might want to protect themselves against attackers potentially misusing the compromised credentials.
Related:Pall Mall Process Progresses but Leads to More Questions
What Happened
A hacker using the handle "rose87168" claimed responsibility for the intrusion nearly three weeks ago. In a post on BreachForums, the hacker said they had accessed some 6 million records from "Oracle traditional servers." The hacker described the data as coming from Oracle SSO and LDAP servers, and allegedly included JKS files, passwords, key files, and enterprise manager JPS keys. Rose87168 identified the LDAP passwords as hashed and the SSO passwords as encrypted but likely possible to decrypt with files accessed during the compromise.
CloudSEK, the first to report on the breach after observing rose87169 attempting to sell the stolen data, identified the credential data as belonging to more than 140,000 Oracle cloud tenants. Oracle flatly denied any breach of its cloud environment — and doubled down on its denials — even as CloudSEK, Trustwave, and others surfaced more evidence of what they said was a potentially severe compromise involving even personally identifiable information (PII). With Oracle remaining silent, several of these vendors offered their advice and assessments on what organizations needed to do to verify if they had been affected and how to mitigate risk from any potential fallout.
Related:Organizations Lack Incident Response Plans, but Answers Are on the Way
Carefully Worded Denials
Oracle's denials consistently noted only how there had been no breach of its OCI environment. This led some to conclude that the company was likely deliberately crafting narrow denials to leave room for breaches elsewhere in its infrastructure — like its older Oracle Classic.
It remains unclear how affected Oracle customers might react now that the company seems to have finally conceded a breach on its older servers. The main concern is whether the company's delayed disclosure might have put some customers at risk.
Already, at least one law firm — Lynch Carpenter LLC in Pittsburgh — is investigating potential claims against Oracle. "If you received a data breach notification from Oracle, or believe you have been impacted by this breach, you may be entitled to compensation," the law firm said in a press release this week.
Oracle did not respond to a Dark Reading request for comment on the alleged breach notification's authenticity, the number of customers it might have contacted, or why the company didn't disclose the incident earlier.
For context, most US data breach notifications offer an encryption safe harbor. The rules generally don't require notifying customers or regulators if passwords and usernames are encrypted or hashed, provided the encryption key wasn't compromised and the hashing is secure.
Related:What Should the US Do About Salt Typhoon?
Darren Guccione, CEO and co-founderat Keeper Security, says even when passwords are encrypted, cybercriminals have several potential attack vectors. "When passwords are properly protected with strong encryption, cybercriminals cannot directly read them; however, they may try other techniques, including brute force and password hash attacks," he says. "Cybercriminals may also try to launch password hash attacks using rainbow tables or other methods."
The takeaway for affected organizations using cloud services is to ensure strong password management policies, enforce least-privilege access, and protect credentials with robust encryption. "A zero-trust approach, where access is continuously verified, helps mitigate the risk of unauthorized access, even if credentials are compromised," Guccione says.
Oracle's recent admission about the breach involving two outdated servers brings up several critical points worth unpacking, adds Casey Ellis, founder of Bugcrowd.
While encryption and hashing — which is how Oracle claims to have protected the data in the servers involved in the breach — are "foundational security practices, their effectiveness hinges on the algorithms and implementations used," Ellis says. "Without specifics, it's hard to gauge the actual security of the exposed data." The attacker, rose87168, has claimed to have been unable to crack the credentials, suggesting a strong protection mechanism, but the absence of detailed information leaves room for doubt, Ellis says.
Although the attacker admitted they couldn't crack the passwords, the exposure of usernames alone isn't harmless. "Usernames can be weaponized in social engineering attacks or combined with other breached data to facilitate credential stuffing," Ellis warns. "Even seemingly benign data can become dangerous when aggregated, so organizations should treat this as a potential risk."
