Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

New JBOSS Worm Infecting Unpatched Servers

timothy posted more than 2 years ago | from the malware-spreadeth dept.

Security 47

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

cancel ×

47 comments

Sorry! There are no comments related to the filter you selected.

10 minutes (0)

Anonymous Coward | more than 2 years ago | (#37801166)

Its been 10 minutes, theres a damn worm involved, theres servers involved, and Slashdot commenters is staying eerily silent about the whole thing. What?

15 minutes (2)

Looce (1062620) | more than 2 years ago | (#37801216)

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

Re:15 minutes (1)

Loki_1929 (550940) | more than 2 years ago | (#37802592)

Or more likely, they're contacting their software vendors to yell and scream until the vendor finally gets off their ass and agrees to provide a supported product update to fix the problem.

first` (-1)

Anonymous Coward | more than 2 years ago | (#37801170)

FIRST!! wow first first ever

Re:first` (0)

Anonymous Coward | more than 2 years ago | (#37801332)

You lose.

JBOSS. (-1)

Anonymous Coward | more than 2 years ago | (#37801194)

Who gives a shit?

Re:JBOSS. (1)

dcherryholmes (1322535) | more than 2 years ago | (#37803462)

Big, unnamed, telecoms.

Patch available -- don't panic (1)

msobkow (48369) | more than 2 years ago | (#37801230)

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:Patch available -- don't panic (2, Interesting)

Anonymous Coward | more than 2 years ago | (#37801410)

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.

Re:Patch available -- don't panic (0)

Anonymous Coward | more than 2 years ago | (#37801456)

I knew my manager posted here! I don't know why but I just knew.

Re:Patch available -- don't panic (1)

perlith (1133671) | more than 2 years ago | (#37804034)

In which case, Red Hat has an excellent writeup of a manual / non-code workaround via update of the web.xml file if you are version-locked:
https://access.redhat.com/kb/docs/DOC-30741 [redhat.com]

Cheers.

Re:Patch available -- don't panic (1)

msobkow (48369) | more than 2 years ago | (#37801666)

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.

Re:Patch available -- don't panic (1)

JonySuede (1908576) | more than 2 years ago | (#37801894)

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

Re:Patch available -- don't panic (0)

Anonymous Coward | more than 2 years ago | (#37801976)

Support is for wimps!

Re:Patch available -- don't panic (1)

crutchy (1949900) | more than 2 years ago | (#37802820)

Luckily I'm no wimp... i'm a lamp :)

Re:Patch available -- don't panic (0)

Anonymous Coward | more than 2 years ago | (#37802044)

pussy.

Re:Patch available -- don't panic (1)

msobkow (48369) | more than 2 years ago | (#37802146)

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, sometimes it's not. If you just use software without knowing who is contributing, you're really being naive. You should understand your technology "supply chain."

Programmers gotta eat, too.

Re:Patch available -- don't panic (1)

Raenex (947668) | more than 2 years ago | (#37805222)

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.

Re:Patch available -- don't panic (2)

Loki_1929 (550940) | more than 2 years ago | (#37802648)

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.

Re:Patch available -- don't panic (1)

msobkow (48369) | more than 2 years ago | (#37803268)

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 designed software. Over 20 years in the industry, and I've yet to run into a serious compatability issue within a given point release. People need to start rethinking the production lifecycle in terms of keeping up to date and maintaining API and modularity boundaries, and let go of the old "production freeze" mentality.

Re:Patch available -- don't panic (2)

msobkow (48369) | more than 2 years ago | (#37803292)

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?

Re:Patch available -- don't panic (1)

Loki_1929 (550940) | more than 2 years ago | (#37805310)

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 customer does.
Admins don't decide which products to push; salespeople and management do.

And if you don't ever run into compatibility issues, you're either using an extremely limited set of applications with great vendors, or you're exceedingly lucky. I've seen all manner of issues crop up with Sparc and x86, Solaris, Windows, and Linux after running "minor" updates. Sometimes it's stuff the vendor broke. Sometimes it's something the underlying software changed that the vendor's code was dependent upon. Apache's latest releases for 2.0.x and 2.2.x even break RFC compliance (granted, with reasonably good reason). Microsoft tossed patches out for Win2k3 R2 that blew up IIS. Do I just throw the latest version of everything on all the prod systems I'm maintaining? Hell no (I actually like my job); I haven't a clue what that might break in all the various applications depending on those types of underlying software. It's the vendor's job to thoroughly test their product, find and fix problems, and let me know what configurations they test with and support.

Can I just start throwing updates around all over the place and hope for the best? Sure. Will it break things that customers are using? Yes, horribly. How do I know? Because as soon as it doesn't create a support issue from the vendor, these kinds of updates get installed in dev environments first and they break things in the dev environments all the time. When they don't break things in dev, then they're promoted through the chain and don't reach a production system until they've had the living shit tested out of them. Why? Because you don't want to be the one explaining to management why you just lost the company $6 million a year for a major production outage caused by throwing in unsupported, untested code changes. It isn't about there being a 'stake in the ground'; it's about keeping things functional so the customers don't go away and leave you without a budget from which to draw a paycheck.

What you actually do instead is a) keep up with security alerts that might impact systems you're running, b) figure out if your configuration is vulnerable to specific problems, c) mitigate on your own right away in any way possible that won't affect the application when you find something that could hit you, and d) contact the vendor to start the process of squeezing an update out of them. Does it suck? Absolutely. Should vendors always keep up and get security fixes out/provide rapid response for support inclusiveness with new versions of underlying software? Absolutely. Do I get to change the business practices of multi-billion dollar a year companies providing the software and support needed to serve customers? No.

Re:Patch available -- don't panic (1)

msobkow (48369) | more than 2 years ago | (#37805394)

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 who are still in the "buy a product" mindset just aren't getting it. You buy a license. You pay for maintenance contract. The vendors keep the maintained products up to date and secure. Any vendor not doing their job gets nailed for breach of contract.

Should you choose to skip the maintenance contract, you're on your own and deserve the nightmare of obsolescence that you're encouraging.

Re:Patch available -- don't panic (0)

Anonymous Coward | more than 2 years ago | (#37805692)

You buy a license. You pay for maintenance contract. The vendors keep the maintained products up to date and secure. Any vendor not doing their job gets nailed for breach of contract.

Oh pray tell, how exactly does one go about successfully suing companies the size of Oracle, Red Hat, Microsoft, etc. for breach of contract (without going bankrupt) when they lag on releasing updates or testing their products with updated versions of supporting software.

In a perfect world, you'd be right. But we don't live in a perfect world. In the real world, the guys responsible for infrastructure or system integration are not in any position whatsoever to fix the underlying problem. Assuming sysadmins actually got put in front of customers with free reign to speak their minds, what would you have them say when the customer requests a solution where all the big vendors for it are typical with regards to security and maintenance (i.e. terrible) and a custom solution will cost them x times as much as anything they've seen? What would you have sysadmins tell the vendors? Support Java/Apache/etc. version 1.2.3 in product x by Monday or we'll sue you?

You aren't being the least bit practical. You're talking about how it -should- be and I'm talking about how it actually is. In the real world, the best one can do without risking outages is mitigate issues as they come, lean on the vendor to fix/support the fix for the issue, and test the Hell out of any code change before implementing it in production. Any sysadmin living in the real world who isn't doing those basic things is risking a major intrusion or a major outage (or both).

Occupy! (1)

msobkow (48369) | more than 2 years ago | (#37806324)

Don't give up hope on holding big business accountable.

Re:Patch available -- don't panic (1)

mandelbr0t (1015855) | more than 2 years ago | (#37802396)

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 administration application, and can be expected to have near full control of the application server.

The JBoss Wiki has instructions on how to secure the jmx-console [jboss.org] from remote users.

Re:Patch available -- don't panic (2)

leenks (906881) | more than 2 years ago | (#37802418)

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.

Re:Patch available -- don't panic (2)

turbidostato (878842) | more than 2 years ago | (#37803556)

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

Not much of a vulnerability (2)

Philotomy (1635267) | more than 2 years ago | (#37801394)

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.

Re:Not much of a vulnerability (0)

Anonymous Coward | more than 2 years ago | (#37805426)

Errr no; the official documented way of securing the JMX console is broken and only secures GET and POST requests (so Put is not secured for example). Jboss did ship a notice but the current Jboss 5 download on their web site as of 10.22.2011 still has the vulnerability. I think it is hard to blame the sys admin for this one.

Re:Not much of a vulnerability (0)

Anonymous Coward | more than 2 years ago | (#37807200)

> Anyone who leaves the JMX console unsecured...

Considering there is *no* documentation available on how to secure it, you're wrong. If RedHat wasn't so arrogant and would actually help us, then we wouldn't have this problem. As it stand now, all we have from RedHat is an expensive support bill and no help with this problem.

This isn't new (1)

The Yuckinator (898499) | more than 2 years ago | (#37801428)

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.

FACE FACTS (-1)

Anonymous Coward | more than 2 years ago | (#37801550)

LINUX UTTERLY BLOWS!

you face facts, (1)

lister king of smeg (2481612) | more than 2 years ago | (#37801890)

you sir are a dumb ass. this is not linux this is java, now go troll elsewhere

Same old same old (0)

Anonymous Coward | more than 2 years ago | (#37801574)

1. I'm leaving IT.

2. I'm taking a pay cut to do it.

3. Real profit.

re-de (0)

Anonymous Coward | more than 2 years ago | (#37801626)

and?

JBoss (3, Funny)

cadeon (977561) | more than 2 years ago | (#37801698)

New UNNECESSARY CAPITALIZATION Worm Infecting Unpatched Headlines

But I thought Linux couldn't be hacked?? (-1)

Anonymous Coward | more than 2 years ago | (#37802064)

WTF??

Re:But I thought Linux couldn't be hacked?? (1)

UnknowingFool (672806) | more than 2 years ago | (#37802850)

JBoss isn't Linux. Troll somewhere else.

Can JBoss be installed without being root? (0)

Anonymous Coward | more than 2 years ago | (#37805968)

The one thing that crack me up is all these people packaging Un*x application using a *BROKEN* format (.deb or .rpm) mandating people to be root to install them. Don't get me wrong: I'm a huge Linux fan but .deb and .rpm are basically broken (I need to be root: I'm not installing your app).

Another thing that crackes me up is people installing whatever Java appserver as root "because it needs to listen to port 80 and you must be root to do". Yeah, sure. How hard is it to have your app listen on a port > 1024 and then doing a transparent firewall redirection?

Did you know that, on Linux, you can install Java + Tomcat without ever needing to be root? The only one time you'd need root would be to change the redirections to 80/443. And that's it. As a bonus you can deploy a second server, as another user for example, verify that everything is working and then change the port redirection: zero downtime webapp upgrade on a single machine.

But, no, people will keep installing Java as root, they'll keep installing Tomcat or full J2EE stacks as root, etc. Then they come playing the crybabies once their rooted JBoss automatically means rooted machine.

We're leaving in a sad, sad world security wise.

My grsec Debian/GNU Linux hardened Java + Tomcat server? Uptime in the four digits range. But what do I know about this uh!?

Re:Can JBoss be installed without being root? (1)

mandelbr0t (1015855) | more than 2 years ago | (#37806504)

This is my vote for the most ignorant comment of the week. Firewall redirections are about the worst possible way of forwarding to your web application, since your Java container knows nothing about the redirection. Java Server Faces, for example, and similar technologies such as JBoss Seam and Oracle ADF will often write their own URLs into the the application. Have fun making that behave with your firewall redirection. No, the correct way to get your web application to listen on port 80 is to use mod_jk and disable the Coyote HTTP. Hooray for your four digit uptime. I'm reminded of this image [pokato.net] when you talk about your awesome security and uptime. You fail to mention how many visitors that impossible-to-crack website gets. Like you said, what do you know about this? Clearly a lot less than you think you do.

Re:Can JBoss be installed without being root? (1)

Karzz1 (306015) | more than 2 years ago | (#37817350)

I have used mod_jk however I was under the impression that mod_proxy_ajp is replacing it. I have used mod_proxy_ajp for my last few installations and I love how simple it is to set up. Do you have information to the contrary? Is there specific applications where mod_jk make more sense than mod_proxy_ajp?

Re:Can JBoss be installed without being root? (1)

mandelbr0t (1015855) | more than 2 years ago | (#37819708)

These questions are answered in the Tomcat Connectors FAQ [apache.org] .

Re: your sig. You will find people withhold less information when you take the time to do research before asking FAQs. Paying them helps too ;-)

Where to find info on How to protect your Jboss (1)

blackorzar (954183) | more than 2 years ago | (#37806460)

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

Re:Where to find info on How to protect your Jboss (0)

Anonymous Coward | more than 2 years ago | (#37807090)

The make "some" edits to "some" file "somewhere" doesn't help the people that are a victim to this bad Java crap. Until someone posts good instructions on how to fix the problem, of course it will remain a huge problem. People like you that post links to meaningless roundabout crap instead of posting information are continuing to make the problem worse.

How about a text file that tells us how to fix our compromised servers?

Re:Where to find info on How to protect your Jboss (1)

Anonymous Coward | about 2 years ago | (#37808082)

If your system has been compromised, there is no 'fixing' it. Anyone who claims otherwise is a fool or a troll. Restore/rebuild with a known-good configuration, then secure that. The problem with trying to 'fix' JBOSS after an attacker has gained access is that you don't know what else they've gotten into on that system. Worst case scenario is that they're a lot better than you and have stuff hidden all over the place that you'll never find. You patch your JBOSS issue and move along believing all is well. Meanwhile, the attacker has persistent access with potentially elevated privileges.

If you're talking about physical machines, then hopefully you have recent, known-good disk images you can restore. If it's on VMs, then hopefully you've got snapshots ready to restore (assuming you don't have reason to believe the hypervisor wasn't affected). Hopefully you're monitoring your local network traffic and watching for signs of attacks against other local systems. If any of this isn't already in place, then I'd get moving on the rebuild and consider this a good lesson to learn.

Re:Where to find info on How to protect your Jboss (0)

Anonymous Coward | about 2 years ago | (#37811530)

No one posted anything about trying to clean-up after a compromise. You're just making-up crap because you can't defend Red Hat.

Are there any instructions on how to fix the vulnerability? I've looked for hours, and I don't think they exist. The link in the OP talks in circles and doesn't give the names of the files to change or what to change in them. JBoss guys have giving a big FU to their community.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>