Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
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:
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:
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/
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.
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.
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:
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.
