Version 6
Created by anil.saldhana on Apr 14, 2011 9:35 AM. Last modified by jaikiran on Apr 15, 2011 1:55 AM.

    Recently, we came across incidents of malware/bots with JBoss AS community version reported in the forums at http://community.jboss.org/thread/164950?tstart=0

     

    Security experts at Red Hat, primarily Steve Milner from Red Hat Information Security and Marc Schonefeld from Red Hat Security Response did some background analysis of this.  I am copy/pasting their conversation/findings here. Kudos to Steve and Marc.

     

     

    Incident
--------
Marc Schoenefeld and I (Steve) were chatting on IRC when he passed 
along that he knew of a JBoss malware infestation via a JBoss forum 
post, which describes the infection of a host running the 
unsupported community version of JBoss Application Server. I jumped 
at the chance to take a look 
at what this specific JBoss badware looks like and how it may have 
infected the instance. Marc 
shared quite a bit of research on what he found as well as some 
information the instance administrator 
had given including that the JBoss admin was worried about ‘a virus’. 
The JBoss administrator found he 
had two unidentified JSP’s, one of which was referencing the IP [#1].


Details
-------
Marc looked into the the IP [#1] and found it to point to a well 
known and stable service. 
This could be for a number of reasons but I believe it was to simply 
check if it had a working 
network connection to the outside world. The service is stable enough 
to use as a test while being normal enough that it would be unlikely
 anyone would think anything of the request. 
Marc also noted that the code referenced another IP of [#2]. This 
second IP was originating in Austria to a hosted solutions software company.

The two JSP’s were line by line identical with the exception of one line. 
In the JSP which referenced [#1] the system runtime is being utilized so 
it can execute a system command. In this instance it was executing perl 
(something that is installed on almost every Linux/Unix 
system today). In the JSP which referenced [#2] the system runtime is 
used to 
download a file off of [#2]. In both JSP’s there is boilerplate code for 
streams 
and checking the popular service for outside internet connection.

Marc got a hold of the perl-based payload from [#2] and found it to 
be something 
I have seen before: ShellBOT (http://www.ossec.net/wiki/ShellBOT). In 

this case it is the second listed variant of ShellBOT. Marc also was quick 
to point out that this version was modified to connect 
to the IRC server at IP [#3] which ended up being a hosted infrastructure/shared 
hosting site. 

Here is a basic flow on how this botnet may gain a new slave:

   1. The botnet herders find a host to attack. In this specific case 
it looks to be either an ancient unpatched version of JBoss or a JBoss 
instance with the JMX console open (very likely). 
They exploit the weakness and execute their code. This could be manual 
or automated.
   2. The code runs on the compromised host and downloads its long 
running software. In this case, ShellBOT.
   3. The long running software connects to its control point.
   4. The bot herders connect to the control point to exercise their control.


Wrap Up
-------
All in all it’s not a very sophisticated attack, but interesting nonetheless 
especially since there are instructions on how to properly protect a JBoss 
instance 
(http://community.jboss.org/wiki/securejboss). I've also seen the same bot 

software being utilized against PHP based applications so unsecured JBoss 
instances are yet another vector for this malware.

This really goes to show the importance of taking the time to secure JBoss nodes. 
Even the instructions state:

    When you first download JBoss, it comes as an easy-to-install zip file.  
Upon installation, you can easily deploy EJBs, web applications and a whole 
array of services.  However, you may be suprised how easy it is to compromise 
the services.

In the end it's much more cost effective to take the time and secure to
 the best 
of your ability upfront rather than spending time cleaning up a compromised 
instance
 after the fact -- even if the compromised host is in "the cloud". In fact, 
clean up 
may be so complicated that you may never know 
if you are truly rid of the malware! Even taking simple steps such as 
shutting down 
development JBoss instances when not actively being used could help depending 
upon your 
network and what is allowed in/out. 
If you run a JBoss instance and have not verified your deployments security 
now is the time.

     

    Bottom Line

    Please do not leave your community version of JBoss AS unsecured. 

    As an analogy, if you download Apache HTTP Server serving pages on port 80. do you run it without going through security steps? 

    The same philosophy needs to be applied by developers who host web applications on JBoss AS community Version. 

    Please refer to http://community.jboss.org/wiki/securejboss  for tips/steps to secure your JBoss instance.

    FAQ

    1. I have a serious business and I need security for JBoss AS.
      • You should definitely consider the JBoss Enterprise Application Platform (EAP) that is secure by default and provides a stable/robust application platform.
    2. Give me the steps to secure the community version of JBoss AS
    3. Where do I report security vulnerabilities?
    4. How do I get notified whenever there is a vulnerability published for community projects?

     

    References

    1. Blog Post:  Security:  Community JBoss AS versus JBoss EAP
    2. Secure JBoss AS:  http://community.jboss.org/wiki/securejboss