Securing JBoss AS From Remote Exploit

This morning i got a call from office telling that she can't accessing our ERP application. After some checking i found that there are something wrong with Jboss AS. There are some unrecognized .war files on deploy dir. The .war files only contain one .jsp file with similar code. The results from web search lead me to this website. The code was same, and obviously we were the victim.

It was exploiting standard and unsecured jmx console on jboss (i'm still using jboss v4.0.2), well.. that was entirely my fault wasn't to prioritize securing jmx and web console on production server. The code on .jsp was intended to open a console (cmd on windows or sh on linux) and fortunately the jboss service was executed by user 'jboss' not 'root' (you can imagine what happen if it was root).

This 'accident' forcing me to take time (mine and users) to apply jboss security. First step is i opening bookmark list on my browser (believe me or not i was bookmarking an some articles about securing jboss a couple months ago) and start to apply them. Here are the links : SecuringTheJMXConsole - Jboss Comunity and JBoss Application Server Security Vulnerability Notice.

Now some security was applied, and i need to test it right? download the exploit code and put it into linux box because it wrote using perl and i don't have perl on my windows. First i try the exploit to jboss on my development server which using standard/unsecured version and the exploit was working, this proofing that the exploit is wasn't defect. Then i try it to jboss on production server which the jmx and web concole already secured, and failed while complaining can't upload the file.


For now the jboss is secure from the exploit while i still need to explore other posibilities.

Update: April 1, 2011

Days after implementing secure jmx and web console, i'm not found any alien .war file any more. But netstat result mention some unknown irc connections.
Then i take these step:

1. Run a full scan and found 3 infected files:

ieh: Trojan.Perl.Shellbot-2
.X-un1x: Trojan.Perl.Shellbot-2
xh: Linux.Rst

and remove them.

2. I also checking /tmp and removing some suspicious files/folders which is owned by jboss and nothing to do with currently deployed legit applications (i.e: hibernate cache files).

3. Kill all process by PID shown from netstat (i use -p option to show pid).

4. Re-check all process which is owned by jboss except one which running Jboss Server.

5. Check again netstat to make sure there are no more unwanted connections.

WAR File Auto Deployer

Ok, here its scripts for auto deploying war file, so i don't have to wait all the employees logged out before i can bring down the server ;)

1) create a file with name '/erp/scripts/war-deployer.sh'

#!/bin/bash
#
# WAR File Deployer Script
# description: Its simply stop service, backup file, replace file, and start the service again.
#

WAR_FILE="erp.war"
DIST_DIR="/erp/readyToDeploy"
DEPLOY_DIR="/usr/jboss/server/default/deploy"

# stop jboss server
/sbin/service jbossd stop

# backup
BACKUP_FILE="/erp/backup/$WAR_FILE-"`date +%F_%H-%M`".bak"
echo "Creating backup file $BACKUP_FILE ..."
/bin/cp "$DEPLOY_DIR/$WAR_FILE" "$BACKUP_FILE"

# replace
echo "Replacing $DIST_DIR/$WAR_FILE with $DEPLOY_DIR/$WAR_FILE"
/bin/cp "$DIST_DIR/$WAR_FILE" "$DEPLOY_DIR/$WAR_FILE"

# start jboss server
/sbin/service jbossd start


2) Then assign it in crontab:
run command crontab -e to insert job to be executed tonight into crontab. Then add following line:

05 22 7 3 * /erp/scripts/war-deployer.sh

It will execute script /erp/scripts/war-deployer.sh on 07 March 2011 22:05

3) Done! and let see if it will do the job :p

By given method above, all i need to do is put new erp.war file on distribution directory and change Day-of-month and Month field on crontab every time i need to update the application.
Btw, it will work great too if i have fixed schedule to update the app. consider this cycle: develop/bug fix > test > distribute it by put war file on dist directory and forget the 'deploy' part... ;)


read more about cron on : http://en.wikipedia.org/wiki/Cron.

update[March 26, 2011]
- fixed script (variable $DIST_FILE -> $DIST_DIR).
- crontab entry (year removed, and change ? with *).