Slashdot Mirror


New JBOSS Worm Infecting Unpatched Servers

Trailrunner7 writes "There is a new worm circulating right now that is compromising servers running older versions of the JBoss Application Server and then adding them to a botnet. The worm also attempts to install a remote access tool in order to give the attacker control over the newly infected server. The worm has been circulating for a couple of days at least, and it's not clear right now how many servers have been compromised or what the origins of it are. It apparently exploits an old vulnerability in the JBoss Application Server, which was patched in April 2010, in order to compromise new machines. Once that's accomplished, the worm begins a post-infection routine that includes a number of different steps."

8 of 47 comments (clear)

  1. 15 minutes by Looce · · Score: 2

    Clearly all the Slashdot commenters are busy patching their bosses' JBoss servers against this vulnerability.

  2. Not much of a vulnerability by Philotomy · · Score: 2

    So the "vulnerability" is an unsecured JMX console? That's like saying leaving your front door wide open is a "vulnerability." Or giving out the root password to users is a "vulnerability." Technically true, but also forehead-slapping obvious. Anyone who leaves the JMX console unsecured doesn't just have to worry about worms; the entire application server is wide open if you do that.

  3. Re:Patch available -- don't panic by Anonymous Coward · · Score: 2, Interesting

    How about blaming vendors whose shitty software isn't supported on newer/patched versions of JBoss, who effectively lock sysadmins into running a specific version of known vulnerable software?

    Or how about blaming the Business user for rewarding the vendor by going out and purchasing said shitty software, failing to involve IT at any point in the process, signing the contract, and then (and ONLY then) telling the sysadmin, "Hey, here's the new WhizzBang 2000 software that I just unilaterally purchased and need implemented yesterday. Oh, by the way, you need to implement, support, and own this. Budget? What budget? Servers? Storage? Training? Documentation? What are those? JUST MAKE IT WORK! OMG! How hard can it be? What else are you going to do? You don't have a life anyway."

    No, I'm not bitter or anything.

  4. JBoss by cadeon · · Score: 3, Funny

    New UNNECESSARY CAPITALIZATION Worm Infecting Unpatched Headlines

  5. Re:Patch available -- don't panic by leenks · · Score: 2

    It's a bit worse than that. The article, and exploit, refers to the enterprise platform, but community editions are also vulnerable - and many people run the non-Redhat paid versions for a variety of reasons (not just businesses trying to be cheap). The only supported community release is JBoss 7 and the console works differently there.

    In 4.0.x the console was unsecured - fine, this is no longer a supported Enterprise platform.

    In 4.2.x onwards, the console shipped secured to a degree. The vulnerability is in that the default config only secured GET and POST requests, and the worm exploits this. The fix is to remove the GET and POST constraints such that all methods are protected.

  6. Re:Patch available -- don't panic by Loki_1929 · · Score: 2

    Obviously you've never worked with enterprise applications. You run off and start applying patches/updates on your own without vendor blessings (likely invalidating support contracts that cost more than your annual salary), you can (probably should) get fired. It's all fun and games cowboying your way through updates and talking about how it should all just work (in theory) right up until you break some obscure, shitty vendor code and cause a major outage, blow through the SLA, and risk the loss of a multi-million dollar customer.

    Certainly there are some lazy sysadmins out there who just can't be bothered lifting a finger until something is broken and someone is complaining, but my experience is that nearly all the competent admins are hamstrung by vendors who are incompetent to a level that borders on negligence. No matter how much effort you put into design and maintenance of high-end, fault-tolerant systems, storage, network, and backup gear, bad code easily unwinds the whole thing. The users never see how solid all your stuff is and how broken all the stuff is that you're forced to implement; they only see whether their application is available and fast. Honestly, I've seen a small number of very small software vendors who are truly on the ball. Every medium to large application vendor I've dealt with has major, major problems.

    There's an entire industry built around cleaning up the garbage puked out by "enterprise" application vendors so that users of said applications have something usable. To me, that's indicative of a massive problem.

    --
    -- "Government is the great fiction through which everybody endeavors to live at the expense of everybody else."
  7. Re:Patch available -- don't panic by msobkow · · Score: 2

    In a world of web services and modular software where everything is constantly changing, how can you continue to be so naive as to think you can put a stake in the ground and say "thou shalt be production"? What's the point of dynamically loaded modules on a JEE server (for example), if you can't install the updates for the individual modules?

    --
    I do not fail; I succeed at finding out what does not work.
  8. Re:Patch available -- don't panic by turbidostato · · Score: 2

    "Just point the fingers at the sysadmins who haven't been keeping up with patches on their production systems"

    Sysadmins? They really have usually the power to decide on an upgrade when...

    * It's a supported version and the vendor doesn't provide an upgrade?
    * The app server is used to host a supported program that will break support if you don't stay at the version they say?
    * It's an in-house app and the developers still are using -and depending on, the unpatched version and don't give a damn?
    * His manager is a control freak that won't give a damn about the security problem unless it is exploited but will cry as crazy if there's a service halt because of an unforeseen problem about the update?

    Usually the sysadmin is a "mere" executioner but it is not up to him to decide what -or when to do.