
A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others - sprkyco
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
======
kohsuke
I'm from the Jenkins project.

I wish the authors of this post gave us a heads up beforehand. It put our
users at unnecessary risk.

At Jenkins project, We've published a mitigation script ([https://jenkins-
ci.org/content/mitigating-unauthenticated-re...](https://jenkins-
ci.org/content/mitigating-unauthenticated-remote-code-execution-0-day-jenkins-
cli)) while we work out a better fix for users.

~~~
wglb
It seems that users have already been at unnecessary risk, given _In fact,
even though proof of concept code was released OVER 9 MONTHS AGO, none of the
products mentioned in the title of this post have been patched, along with
many more._

~~~
needusername
Has anybody reported anything? The commons project seems to have been made
aware of this just this weekend through third parties. If nobody reported
anything no wonder it didn't get fixed.

~~~
wglb
See the talk given in January [http://frohoff.github.io/appseccali-
marshalling-pickles/](http://frohoff.github.io/appseccali-marshalling-
pickles/)

------
sprkyco
One thing I really liked about the write-up is the thoroughness that
everything was explained. Nothing was assumed. The author explains what burp
is why it was used. Broke down the basics in a high level and the touched on
the simple things. Showed exploits in multiple frameworks. Really a well done
article just from a write-up perspective let alone the impact of the issue.

------
devonkim
Anyone actually have a CVE I can reference in talks to leadership so I can not
look like a neckbeard security geek that's acting self-important?

~~~
wglb
Unclear if there is one yet: [https://cve.mitre.org/cgi-
bin/cvekey.cgi?keyword=InvokerTran...](https://cve.mitre.org/cgi-
bin/cvekey.cgi?keyword=InvokerTransformer)

------
el_duderino
Kenn White said it best: "This will get very ugly: unpatched, full remote exec
on Java-based web svcs that use a popular serialization library

~~~
toyg
To be fair, it's not really "remote": he attacked communication channels that
are almost invariably maintained deep "behind the firewall". If you are
exposing Weblogic's or Websphere's admin ports to the internet, you have
bigger problems. A competent setup (I know, a rarity in the enterprise world)
will also use encrypted channels for administrative protocols (both WL and WS
can do that very easily). A competent application developer (I know, a rarity
in the enterprise world) will not send serialized java objects on plaintext
over the internet (among other things, it's horribly inefficient).

This is just one of 23432542574358 attack vectors that can be deployed across
intranets and _already_ are routinely ignored, and a hard one at that. It
should be patched, and it's a bit shameful to leave it lingering for more than
a year, but it's hardly the end of the world.

~~~
nmehner
Well, true for websphere, but for weblogic the affected port is the default
listening port, not the admin port. So for a public facing weblogic
installation you have a problem.

~~~
toyg
That's because the default port of the Admin Console instance "doubles up" as
management port. At the very minimum, you would front that port with a
webserver that will only forward internet requests to the appropriate contexts
pointing to applications; but to be honest, if you're exposing the Admin
Console instance _at all_ , you have bigger problems from a design and
security perspective.

~~~
nmehner
I don't think this is about the admin console. The author only used the admin
tools to create a t3 server request. The only thing you really need is a
server accepting the t3 protocol (=Weblogic RMI). Which is every node, not
only the admin node / a node with a deployed admin console.

A load balancer / forwarding web server might filter the t3 requests, but I
wouldn't want to rely on this. Also t3 can be tunneled over http (although
this is not enabled in the default configuration).

------
btilly
This is very similar to the series of serialization vulnerabilities that hit
the Ruby on Rails world in early 2013.

Black hats are going to have fun with this one. :-(

------
based2
[https://www.reddit.com/r/netsec/comments/3rrr9z/what_do_webl...](https://www.reddit.com/r/netsec/comments/3rrr9z/what_do_weblogic_websphere_jboss_jenkins_opennms/)

[http://mail-archives.apache.org/mod_mbox/commons-dev/201511....](http://mail-
archives.apache.org/mod_mbox/commons-
dev/201511.mbox/%3C20151106222553.00002c57.ecki%40zusammenkunft.net%3E)

[https://www.owasp.org/index.php/Information_leak_through_ser...](https://www.owasp.org/index.php/Information_leak_through_serialization)

------
TazeTSchnitzel
The first thing I thought was "written in Java". The more straightforward
headline would have been better, I think.

~~~
tensor
The straightforward headline would be "Security flaw in commons-collection
deserialization". The anti-java snark really isn't welcome.

~~~
gebl
Its not really a problem with commons-collections and unfair to color it as
their issue. Its like blaming the library that is part of a ROP chain for the
exploit. The issue is what gets you in first, which is instantiating objects
without any thought as to what they are from un-trusted sources.

Something that is called out in the Java secure coding guidelines:

[http://www.oracle.com/technetwork/java/seccodeguide-139067.h...](http://www.oracle.com/technetwork/java/seccodeguide-139067.html#8)

and is something that goes way back in many languages. It seems to be a vuln
pattern that keeps getting repeated sadly.

~~~
alblue
It's also not specific to Commons Collections - the same escape is available
through Spring and Groovy as well.

[http://www.infoq.com/news/2015/11/commons-
exploit](http://www.infoq.com/news/2015/11/commons-exploit)

------
pythonistic
I had to backport a fix for a similar vulnerability in a Seam installation
three years ago. The solution at the time was to limit the directories and
sources from which serialized object representations could be read.

