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.
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.
- 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.
- Give me the steps to secure the community version of JBoss AS
- Where do I report security vulnerabilities?
- Look in this page for information: http://www.jboss.org/security.html
- How do I get notified whenever there is a vulnerability published for community projects?
- Bookmark or visit often: Security Vulnerablities to Community