A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others | Hacker News Reader

A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others

foxglovesecurity.com

125 pointssprkyco24 comments

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...) while we work out a better fix for users.

Geez. That sucks.

I guess they really wanted those minutes of fame.

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.

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.

See the talk given in January http://frohoff.github.io/appseccali-marshalling-pickles/

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.

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?

Unclear if there is one yet: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=InvokerTran...

https://cubistramblings.wordpress.com/2015/11/10/weblogic-vu...

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

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.

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.

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.

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).

A big problem with a lot of enterprise application security models nowadays is that if you don't assume that your network has been compromised and that there's active attackers in your network already, you're pretty much setting yourself up for a Home Depot and Target situation. Nevermind that both of these companies are having record sales and stock valuations, enterprise security in practice is more about compliance and dealing with the cost of auditors / regulators showing up and slowing your business down than about loss of revenue and customer safety. Because if people really cared that much about companies that messed up their security, Apple would have had tanking iPhone sales, everyone would have flocked to Lowe's, and Wal-Mart would be picking up where Target's market share went down - none of these things are true at all, in fact the precise opposite.

Companies use deep packet inspection systems on their networks that can actively block packets that look malicious like this attack though, and it's how a lot of enterprises aren't hacked to smithereens every day despite the unfathomable incompetence of so many people working on "critical" applications. I had to deal with an issue where an application was not sending back Ajax requests on occasion that was causing a lot of panic, and it turned out that the reply sent back was being blocked due to a network packet inspection device actively blocking the response because it detected HTTP headers that matched an Apache vulnerability from 2002.

To me, this counts as "remote" because you can build up a big library of dozens of enterprise BS-ware applications that enterprises fail to patch all the time and probably find something that people didn't secure right. Qualys probably won't even be catching this stuff (it's stupid enough to think that a Chef server is running Django and continue to keep probing)

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. :-(

https://www.reddit.com/r/netsec/comments/3rrr9z/what_do_webl...

http://mail-archives.apache.org/mod_mbox/commons-dev/201511....

https://www.owasp.org/index.php/Information_leak_through_ser...

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

Not to get too pedantic, but Java need not be involved, though it will certainly be the most common language involved. Anything running on a JVM (including Clojure, Scala, JRuby, etc.) could have the vulnerability if it uses the Apache Commons Collections library, or some other library that does (which is probably a lengthy list).

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

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...

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

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

That wasn't anti-Java snark. I was complaining that the headline format suggests some unusual thing in common for those projects. But it would immediately occur to you that they are all Java-based.

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.

Reply on news.ycombinator.com