Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Worms IT

New JBOSS Worm Infecting Unpatched Servers 47

Posted by timothy from the malware-spreadeth dept.
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."
This discussion has been archived. No new comments can be posted.

New JBOSS Worm Infecting Unpatched Servers More

New JBOSS Worm Infecting Unpatched Servers

Comments Filter:

  • Just point the fingers at the sysadmins who haven't been keeping up with patches on their production systems. Alas, all too common an issue.

    However, I would like to point the finger at Oracle for releasing updates to Glassfish without a lock-step update of the Eclipse GlassFish tools. I can not upgrade my dev servers without the updates to the dev tools. I don't like being forced to develop and test downlevel from production.

    • Re: (Score:2, Interesting)

      by Anonymous Coward
      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

    • Re: (Score:2)

      by msobkow ( 48369 )

      Yeah, yeah, it's not all the sysadmins fault. Compatability issues and all that. But at least in theory, you're supposed be able to deploy a web application in any container/server, so if you can't apply the updates in this case, there's something fundamentally wrong.

      • indeed, and running core business production server on the unsupported community edition is almost as bad !

        • Re: (Score:2)

          by msobkow ( 48369 )

          I know open source software doesn't require a license, but morally anyone who deploys open source software should be helping to support the community that does the development and maintenance. Some businesses invest a significant portion of their support fees into maintaining the software that's shared by the community. They deserve to be supported in their efforts -- and if no one supports those efforts, who is going to do the work?

          Sometimes it's easy to pinpoint a maintainer or provider to support, s

          • Re: (Score:2)

            by Raenex ( 947668 )

            Programmers gotta eat, too.

            So Cheetos and Mountain Dew? Granted, that won't pay for their health care costs once they get sick,, but there's always some kid out of college to replace them.

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

        • Re: (Score:2)

          by msobkow ( 48369 )

          Obviously you've never worked with enterprise applications.

          That's rich. 20+ years experience doesn't count?

          If you have a vendor coordinating your patches, you've outsourced the patching to them. In that case, they're the lazy sysadmins I'm talking about because they've taken on responsibility for doing the patching and testing. Clearly your vendor is not delivering on their end of the bargain if they're not actually keeping you up to date.

          The compatability argument is a red herring with properly des

          • Re: (Score:3)

            by msobkow ( 48369 )

            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?

          • If the vendor only supports Java/Weblogic/Apache 1.2.3 for their product, you don't get to install 1.2.4 until they support it. If you just decide to do it anyway, the best case scenario is they tell you they don't know the next time you come to them with a problem. The worse case scenario is they run your support agreement through a shredder and laugh at you.

            Admins don't decide which versions of underlying software are supported; the vendor does.
            Admins don't decide which vendor's software to use; the custo

            • Re: (Score:2)

              by msobkow ( 48369 )

              Key point: "For a given point release."

              If you're paying for support, the provider should be back-porting security fixes to earlier point releases as well. The "upgrade to fix" mentality from vendors is as bad as the "lock it down" production release.

              I understand the arguments for the "lock it down" model. I really do. I've heard them all my life. I just feel it's fundamentally the wrong approach.

              Third party vendors should be held responsible for keeping up to date as well. People and companies w

    • More to the point, this can be avoided by correctly securing your jmx-console application on JBoss. The jmx-console allows arbitrary code to be executed with the permissions of the application server. The worm itself targets older versions of JBoss (of which there are a number of production installations), but could theoretically target newer servers as well. It's just that the worm hasn't been updated for the newer jmx-console, which I believe still allows the arbitrary code execution. It is, after all, an

      • Re: (Score:3)

        by leenks ( 906881 )

        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 i

    • "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 i

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

  • intitle:”jboss management console” “application server” version inurl:”web-console”

    intitle:”JBoss Management Console – Server Information” “application server” inurl:”web-console” OR inurl:”jmx-console”

    As I said above, this isn't new.

  • JBoss (Score:4, Funny)

    by cadeon ( 977561 ) on Friday October 21, 2011 @11:02PM (#37801698)

    New UNNECESSARY CAPITALIZATION Worm Infecting Unpatched Headlines

  • It's important to check 3 sites: http://community.jboss.org/wiki/SecureTheJmxConsole [jboss.org] --> Wiki site on Jboss http://community.jboss.org/wiki/SecureTheJmxConsole/diff?secondVersionNumber=47 [jboss.org] --> This is important because the Wiki site has some missing info that you can see in this diff https://access.redhat.com/kb/docs/DOC-30741 [redhat.com] --> Another related security problem Check your Jboss config!!

Slashdot Top Deals

Utility is when you have one telephone, luxury is when you have two, opulence is when you have three -- and paradise is when you have none. -- Doug Larson

Close