JBoss:Bots,Malware,Security etc

    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.



    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].
    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 
    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 
    (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 
     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.


    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?



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