Upset with the vulnerability handling process at Oracle, researchers yesterday disclosed more than two dozen outstanding issues with the company’s Java Cloud Service platform.

Researchers at Security Explorations published two reports, complete with proof of concept codes, explaining 30 different vulnerabilities in the platform, including implementation and configuration weaknesses, problems that could let users access other users’ applications, and an issue that could leave the service open to a remote code execution attack.

The Polish firm released the information after Oracle apparently failed to produce a monthly status report, a document that usually surfaces around the 24th of each month, for the reported vulnerabilities in March.

Adam Gowdiak, the company’s founder and CEO believes that Oracle is on the fence regarding the way it handles its cloud vulnerability handling policies.

“The company openly admits it cannot promise whether it will be communicating resolution of security vulnerabilities affecting their cloud data centers in the future,” Gowdiak said in an open letter posted to Security Explorations’ site on Tuesday.

Researchers dug up the following bugs in both US1 and EMEA1 versions of Oracle Java Cloud data centers.

  • The first block of issues, 1-16, stem from an insecure implementation of the perpetually fickle Java Reflection API in the service’s chief server, WebLogic. If exploited the vulnerabilities could lead to a full compromise of the Java security sandbox.
  • The second batch of vulnerabilities, issues 17-20, ties into a problem with the platform’s whitelisting functionality, which can also be bypassed thanks to the Java Reflection API.
  • Issue 21 revolves around shared WebLogic administrator credentials. Usernames and passwords, which are usually encrypted, can be decrypted with a “standard API,” and are also present across the platform.
  • Issue 22 pertains to the insecurity of the platform’s Policy Store. Sensitive usernames and passwords – often times those belonging to users with admin privileges – are exposed in plaintext form.
  • Issue 23 exposes several WebLogic applications to the public internet. These internal applications are usually only accessible by authenticated Oracle Access Managers (OAM) but a problem the platform could put them at risk.
  • Issue 24 is a Directory Traversal Vulnerability that could let anyone access files that wouldn’t otherwise be deployed on WebLogic from a public internet.
  • Issue 25 exploits a year-old version of Java SE, a problem that opens the platform up to even more vulnerabilities, since all of the fixes from the tail end of 2012 and 2013 have not been applied yet.
  • The 26th issue also involves an authentication bypass, this time via the T3 protocol. While it sounds a little more complicated to exploit, Security Explorations researchers discovered it’s possible to send a “a specially crafted object instance to a remote server identified by a given object identifier (OID) value and successfully impersonate the WebLogic kernelIdentity.”
  • Issue 27 makes it possible to tunnel T3 protocol requests through Oracle’s HTTP Server (OHS) to mimic HTTPS requests.
  • Issue 28 also deals with T3 protocol messages, as they relate to an out of bounds vulnerability with chunk data.

Researchers argue a remote code execution attack would be quite easy to pull off if an attacker combined several of the aforementioned vulnerabilities.

“As a result of the combination of the implementation and configuration flaws outlined… arbitrary code execution access could be gained on a WebLogic server instance hosting Java Cloud services of other users from the same regional data center,” the report, which gets much more in depth regarding attack vectors, reads.

Essentially the attack would involve having a custom .JSP (JavaServer Page) file uploaded to a target WebLogic server, which could later be called upon to trigger the execution of Java code embedded in it.

Security Explorations initially got in touch with Oracle about the preceding vulnerabilities (.PDF) in late January but while it waiting on Oracle’s response, managed to find two additional issues.

Those bugs, 29 and 30 (.PDF), like several of the other 28, involve the service’s whitelisting implementation and can ultimately lead to its API being bypassed.

Oracle’s next batch of updates is set to be bundled together in its quarterly Critical Patch Update on April 15 although it’s unclear if the vulnerabilities from Java Cloud Service, a service the company introduced in 2012 to assist businesses in managing data and building database applications across the cloud will be addressed.

Categories: Cloud Security, Vulnerabilities