Hacker News Reader

Comment by el_duderino | Hacker News Reader

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

View on HN

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)

Reply on news.ycombinator.com