Oracle Cloud Infrastructure Client Data Leaked to Cybercrime Forum
Executive Summary
On March 20th, a user on BreachForums claimed to have compromised Oracle Cloud Infrastructure (OCI). The breach reportedly affected servers responsible for authenticating users to Oracle Cloud services. The individual provided sample data to support their claim and offered to sell access to “about 6 million” credentials and authentication materials for 100,000 Monero (XMR), a cryptocurrency considered more difficult to trace than bitcoin. The threat actor is offering to remove any compromised accounts from the data dump for an unspecified payment and to trade breach information for 0-day exploits.
In response, security researchers have been working to validate and confirm these findings while Oracle has denied any breach to multiple security reporters at BleepingComputer, TheRegister, and Dark Reading. While the extent of the breach is still unclear, they claimed to have access to a authentication server hosted at login.us2.oraclecloud.com and samples of the data they were attempting to sell included various types of authentication data and files related to Oracle Cloud systems. This would contain data for authentication to Oracle Cloud services, as an authenticator provider not only stores authentication for users but includes credentials and grants for automated systems. In short, LDAP user data, certificate information in Java Keystore files, Enterprise manager JPS keys, and access to any service backing its authentication with Oracle's cloud services.
The entire collection of stolen authentication data was not leaked in the BreachForums post, rather a list of impacted Oracle clients was shared. Beazley Security Labs has collected and correlated the list with Beazley insured organizations and Beazley Security direct clients to communicate with potentially impacted organizations.
At the time of writing, Oracle claims that their cloud service was not compromised. However, Beazley Security strongly recommends organizations that use Oracle Cloud verify how they are authenticating to Oracle Cloud applications and rotate any passwords or secrets that are shared amongst different services. Without additional information from Oracle, the security community lacks sufficient data to determine if this threat actor has been successfully eradicated. As a result, it is possible that they may still have access to Oracle's Cloud Infrastructure. Therefore, rotating unique passwords used only on OCI before Oracle provides more details may not be an adequate solution. Please refer to the Mitigation Steps section of this advisory for further details.
This is a developing situation, and this advisory will be updated as more information is available.
Affected Systems and Products
Based on the data we have so far, Beazley Security believes OCI is affected, specifically their Authentication Platform on login.us2.oraclecloud.com.
Beazley Security Labs has identified that the vulnerability may extend beyond this specific cloud region; therefore, it is advised to consider all Oracle Cloud services as potentially compromised. The affected server was seemingly Oracle Fusion Middleware 11g, which is vulnerable to CVE-2021-35587. While it’s possible that Oracle had deployed mitigating controls to this system, the Threat Actor has claimed that they compromised the Oracle using a known CVE no publicly available Proof of Concept (POC).
If the attack utilized this vulnerability, it is recommended that users of Oracle Fusion Middleware update their software with the latest patches immediately.
Mitigation Steps
Effective mitigation steps depend on how an organization authenticates to Oracle Cloud Infrastructure. Organizations should determine which OCI products they are using and what authentication systems are in place.
SAML
If an organization is using SAML authentication, the threat actor may have access to public keys used to verify SAML assertions signed by your identity provider. This situation presents somewhat less risk, as the threat actor would not be able to forge authentication requests. However, if SAML assertions were encrypted and the threat actor is in possession of Oracle Cloud’s private decryption keys, they could decrypt authentication assertions.
Regardless of how these assertions are sent (signed or signed and encrypted), these assertions contain sensitive user information such as email addresses, group memberships, and potentially other identity attributes such as Oracle Cloud services permissions that could be exploited for targeted attacks. Regardless, actions related to administration of Oracle’s infrastructure are Oracle’s responsibility, and without further information from Oracle, little can be done from the position of a user.
OIDC
If an organization is using Open Connect (OIDC), there may be slightly higher risk. If this threat actor has obtained the OIDC client secret for Oracle Cloud, they could impersonate Oracle Cloud’s authentication requests to your identity provider. This would allow them to request valid sessions and authenticate as your users to Oracle Cloud. We recommend rotating any OIDC secrets for any organization using this authentication mechanism.
General Recommendations
Regardless of implemented authentication strategies for Oracle Cloud applications and connected services, organizations should consider any credentials or secrets in Oracle Cloud compromised and should rotate any that may be reused elsewhere within the organization.
While we would also normally recommend credential rotation in Oracle Cloud as well, we need to reiterate that at the time of writing, Oracle denies that a breach actually occurred. This means that while Beazley Security reasonably concludes that Oracle Cloud authentication systems are compromised, we cannot conclude that the threat actors have been removed from those systems as again, Oracle denies that a breach occurred.
Technical Details
Much of what is written here is a summarization of a two-part post from Rahul Sasi on CloudSEK, If you find interest in our additional findings please give them the attention they deserve. [Part1] [Part2]. However, there are some interesting findings that we’re publishing for the first time 👀.
After the initial BreachForums post from “rose87168” security researchers began working to validate the reported breach. Rose87168 had confirmed access to at least one of the affected servers login.us2.oraclecloud.com by creating a publicly accessible link on the server at the address `https[:]//login.us2.oraclecloud.com/oamfed/x.txt?x.` This would imply that rose87168 had access to modify and read files on at least one of Oracle’s authentication systems. While this file is no longer available, proof of its existence can be found on the Web Archive’s WayBack Machine
To confirm that login.us2 was a legitimate Oracle production server, CloudSEK validated oracle’s quickstart documentation code on Github to show the url of the affected server was used. Following this, CloudSEK searched publicly available Github repositories for API keys to Oracle, finding five such cases, and correlated them to domains in the leak from rose87168.
This leads security researchers to a reasonable conclusion of sketchy behavior for the login.us2.oraclecloud.com server. However, we now must work to validate a mechanism for the attack that could have compromised this server. Some researchers have guessed that the version of Oracle Fusion Middleware was old enough on this server assert that it may have been impacted by a critical vulnerability (CVE-2021-35587). Beazley Security Labs has not validated this assumption at the time of reporting.
Rose87168 spoke with Bleeping Computer and claimed to have been on this server for 40 days before attempting to sell this data. In order to investigate this, Beazley Security leveraged the Wayback Machine in an attempt to get insight into the version of Oracle Fusion Middleware that was running on this host during the threat actors purported access.
We can find an archived page from February 17th of this year showing this server was running “ORACLE FUSION MIDDLEWARE 11g”. Using this information, we can start to find other Oracle Fusion Middleware 11g servers matching the pattern of login.*.oraclecloud.com. Below are several examples of what appear to be Oracle managed systems that are online as of this writing:
- login.us9.oraclecloud.com
- login.us8.oraclecloud.com
- cldadmininternal.us8.oraclecloud.com 👀
Navigating on this site we can see a section labeled ”Online Documentation” showing the version on some Oracle Cloud Services to be 11.1.1.5, which appears to be software released in 2009 according to Oracle’s documentation.
It’s worth noting here that there are many more services that we know are running this software but are do not appear to be directly related to Oracle Cloud Infrastructure. If rose87168 had leveraged a vulnerability within Oracle Fusion Middleware for us2, we can reasonably assume that these other services are currently vulnerable if not affected.
Additionally, a twitter account by the same name started posting information that seemingly corroborates the BreachForum’s account. This includes a link to video shared through Anonfile.io that seemingly shows internal administrative training that rose87168 claims to have pulled from the server. While the connection between this twitter user and our BreachForum’s user is not confirmed, it would behoove one to keep an eye out continued TA activity on this Twitter account.
At this point we as users have little actionable work to do to remediate this issue. Oracle denies any breach of data, and without a public statement from Oracle explaining the archived pages presented above, end users have little recourse to know if there will be action from Oracle moving forward. This includes whether rose87168 still has access to login.us2. Making password rotation potentially fruitless. Doubly so, while patches exist for Oracle Fusion Middleware that address currently known vulnerabilities, without acknowledgement of a vulnerability or attack, users running on premise versions of this software have little to do to mitigate risk. This places security researchers in a precarious situation of reporting potentially incorrect information, while Oracle can continue to deny any potential impact.
How Beazley Security is Responding
Beazley Security Labs has collected the list of supposedly impacted organizations and correlated the list with Beazley insured organizations and Beazley Security direct clients to communicate with potentially impacted organizations.
Sources
Aware of an incident impacting your industry? Let us know: