3

I have Java applications served by Oracle WebLogic servers that are after a load balancer. The WebLogic t3 protocol (vulnerable) is not tunneled to the WebLogic servers, only the HTTP requests.

In this scenario, can my Java applications server by the WebLogic servers be exploited using CVE-2015-4852 (Java serialization/deserialization vulnerabilities)?

The vulnerability is critical (pre-auth RCE). You can find more information here:

http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001

http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/

Improve this question

4 Answers 4

Reset to default
4

Ok, Let's get to the point: vulnerability CVE-2015-4852 is not about the T3 protocol. The problem lies in the serialization/deserialization routines used by WebLogic and the underlying libraries that compose the java classpath.

So, just to make a few points clear:

  • The T3 protocol is cited because it is a point of entrance to user-provided serialized data.
  • WebLogic is cited because it comes bundled with the affected Apache Commons library and it is loaded in the classpath when WebLogic is run. It needs to be updated so that the affected bundled library can be updated too. Or you could update it yourself.
  • The real problem lies within the Apache Commons library itself.

Therefore answering to your question, yes, your application still might be affected by deserialization vulnerabilities if the attacker is able to find somewhere else to enter serialized malicious data. Some Java applications rely heavily in serialization. Lots of them also send it through HTTP/S connections being base64-encoded or with some other type of encoding. Java JSP applications also make use of Viewstates (base64'd too, although it uses a structure that differs from ASP.NET Viewstates).

I've even seen Oracle's HCM (Human Capital Management) module use base64-encoded serialization to define a page title (yes, i was able to change it to whatever i wanted, but by the time a examined it, i wasn't much aware of the inner workings of deserialization flaws)

UPDATE:

There has been some development on this issue. Not in this CVE itself, but some folks found out that there are more libraries (very common ones also) that are vulnerable to the whole serialization/deserialization matter.

http://www.theregister.co.uk/2015/12/07/java_deserialisation_research_library_vulnerable/

Improve this answer
2
  • I would like to add that not only Apache Commons is vulnerable. Other libraries and custom code that uses deserialization may be vulnerable. A more generic way of looking for this kind of vulnerability is search for InvokerTransformer but other classes may be also vulnerable.
    – Eloy Roldán Paredes
    Nov 20, 2015 at 7:40
  • Well, in the mentioned CVE, only the Apache Commons library was mentioned besides WebLogic. Therefore, i cannot know if or say that there are others libraries involved in this specific vulnerability.
    – DarkLighting
    Nov 23, 2015 at 11:41
1

From my understanding of the vulnerability as mentioned here https://stackoverflow.com/questions/33679614/cve-2015-4852-evaluating-apps-for-vunerability, if you are able reach ObjectStream.readObject() of your Java application, it will be possible to exploit this. So if you have a url say example.com/sample and sample is referred to the load balancer as http://host1:9003/sample, you should be safe from a weblogic perspective for anyone accessing example.com and not host1.

I guess all you need to worry about is if your load balancer allows t3 connections through. If so, do request that it be blocked. As Oracle's document suggests(Doc ID 2076338.1) block t3 access and you should be good.

Improve this answer
1

You are only exploitable (different to 'vulnerable') if serialized data can reach your application. In this case if the T3 traffic is not passed through then no, you would not be exploitable via this avenue.

Be warned though, any other location where user controlled serialized data is recieved is equally vulnerable, and this may take place over http.

Improve this answer
1

CVE-2015-4852 is a specific vulnerability in the Oracle WebLogic software. It has been discovered that the t3 protocol is vulnerable because it may receive untrusted serialized objects from a potential attacker. If the t3 protocol is not tunneled from the load balancers, malicious traffic is not passed to the Weblogic portal preventing the threat in this case.

However, the serialize/deserialize vulnerabilities are a full category of vulnerabilities. Other components of the Oracle WebLogic software may be vulnerable, not only the t3 protocol. The fact is that no other components in WebLogic have been identified to be vulnerable.

In the other hand, standard or custom Java applications served by Oracle WebLogic server (or other application servers) may be vulnerable to serialize/deserialize vulnerabilities. Althought it is not frequent to pass serialized objects through HTTP but it may be possible to include them in headers, cookies, post or get data, etc.

The recommended way to know if your application is vulnerable is:

  1. Go to application directory
  2. grep -R InvokerTransformer .
  3. Sniff or intercept traffic and look for serialized objects from the user to the application:
    • rO0AB (base64)
    • ac ed 00 05 (hexadecimal)
  4. Develop a specific proof-of-concept and check

This is not the deffinitive way of finding this kind of vulnerability as other ways of exploiting dangerous readObject() calls may be discovered not using InvokerTransformer.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .