Weblogic and OIM are vulnerable to Java deserialization attacks over the network.
This vulnerability was reported to Oracle in 2015 and assigned CVE-2015-4852. Oracle has released a series of patches to address the issue, but many systems continue to be vulnerable. The attack is easy and the steps are publicly available. An attack does not require authentication and can result in complete compromise of your OIM installation. We recommend immediate action to secure your system using the outline below.
- Patch Weblogic and Java to the latest versions
- Block unneeded network access to the T3 protocol
- (Optional) Monitor your logs and network for attack signatures
Weblogic patches
Install the most recent Weblogic patch that is compatible with your OIM installation. As of October 2016, the most recent patch is PSU 161018, which has Patch ID 23743997. We have seen some cosmetic issues with images on OIM’s administrative IT Resource and Access Policy screens after patching, but no functional problems. End-user / self service pages do not appear to be affected. Weblogic patches are easy to remove, so there is no risk to installing the patch on a development or QA system.
Java patches
Oracle also routinely publishes Java patches and updates, which you should install. Although JDKs 6 and 7 have reached their public end-of-life, Oracle continues to make new versions available via My Oracle Support. The latest updates of Java include some hardening against this vulnerability. As of 18 October 2016, the latest version of Oracle JDK 7 was 7u111 build 32, which has patch ID 24558841. The latest version of Oracle JDK 6 was 6u121, which has patch ID 23739936. For up to date information, visit MOS Doc ID 1439822.1, which lists all JDK downloads.
Block network traffic
Now that research has begun on deserialization vulnerabilities, it’s probable that new variants of the exploits will be discovered in the future. Blocking network access entirely will help defend against those future exploits. Weblogic has a unique feature where various network protocols (like HTTP, T3, and IIOP) all share a single port. It routes the messages based on their content. If someone can access your OIM system in a web browser, they can probably access it via T3, which is natively vulnerable to deserialization attacks.
Weblogic provides a network connection filter feature, which allows you to selectively firewall certain protocols. You should allow T3 traffic only from those hosts which need them. This is typically other servers in the cluster, the local host, and any custom code outside of OIM using its J2EE API. Additionally, the OIM Design Console and LDAP gateway use T3 to communicate.
To set the domain-wide connection filter:
- Open the Weblogic Administrative Console (typically at admin-host:7001/console) in a web browser.
- Click your domain name in the sidebar.
- Click the “Security” tab, then the “Filter” tab.
- Type your connection filter (see below) into the “Connection Filter Rules” box. Leave the smaller “Connection Filter” box blank, because you want to use the default.
- Save and restart your OIM installation.
The following is an example connection filter for a two-node cluster. It allows T3, T3S, and unencrypted HTTP from the cluster nodes and from localhost, and denies everything except encrypted HTTPS from all other IPs.
192.168.1.100 * * allow t3 t3s http
192.168.1.101 * * allow t3 t3s http
127.0.0.1 * * allow t3 t3s http
0.0.0.0/0 * * deny t3 t3s http
You can, of course, also use traditional firewalls to narrow the number of people who can access your OIM system on any protocol as much as possible for your organization.
Monitoring
You can proactively monitor your logs and your network for deserialization attacks. Snort rules are available for detecting serialized Java objects. If you want to customize your rules, serialized Java objects will start with the bytes AC ED 00 05. If encoded to Base64, they will start with the text rO0. Note that many applications also communicate legitimately using serialized Java objects. Most deserialization attacks (but not all) will show up in your Weblogic or OIM logs as ClassCastException error messages. If you see AnnotationInvocationHandler in a ClassCastException stack trace, or if java.lang.UNIXProcess is part of the error message, this is almost certainly an attack attempt.
Additional steps
There are more invasive, unsupported ways to defend your system against deserialization attacks, such as JVM agents. While effective, these are beyond the scope of this article. Contact Identity Works LLC for an evaluation of your OIM installation.