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.
A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
11–20 of 27 posts
Re: A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
#12Anyone 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?
Re: A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
#13Kenn 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.
Re: A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
#14I'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.
Re: A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
#15The first thing I thought was "written in Java". The more straightforward headline would have been better, I think.
The straightforward headline would be "Security flaw in commons-collection deserialization". The anti-java snark really isn't welcome.
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.
Re: A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
#16Kenn 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 app…
[deleted]
Re: A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
#17Kenn 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 app…
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.
Re: A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
#18Earlier quoted context omitted.
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 app…
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.
Re: A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
#19Kenn 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 app…
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)
Re: A vulnerability in WebLogic, WebSphere, JBoss, Jenkins, OpenNMS and others
#20Earlier quoted context omitted.
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).