There is a new worm circulating right now that is compromising servers running older versions of the JBoss Application Server and then adding them to a botnet. The worm also attempts to install a remote access tool in order to give the attacker control over the newly infected server.
The worm has been circulating for a couple of days at least, and it’s not clear right now how many servers have been compromised or what the origins of it are. It apparently exploits an old vulnerability in the JBoss Application Server, which was patched in April 2010, in order to compromise new machines. Once that’s accomplished, the worm begins a post-infection routine that includes a number of different steps.
One user who found the worm’s payload on a honeypot machine he controls posted a message to Pastebin saying that the payload includes a variety of Perl scripts, one of which immediately connects a newly infected machine to an IRC server, effectively adding it to a botnet of other compromised JBoss servers. The payload also installs a RAT for future use by the attacker.
“I explored the contents of the malicious payload left and it contained Perl Scripts to automatically connect the compromised host to an IRC Server and be part of a BOTNET, install and run a remote access tool using dyndns (Flu.pl), and two Windows batch scripts, one is for exploring JBOSS Services (wstools.bat) and a script to discover all UDP–based members running on a certain mcast addressJGroups called “JGroups Cluster Discovery Script for Win32” (probe.bat),” the user wrote in his analysis of the JBoss worm.
Officials at Red Hat, which provides paid support for the open-source JBoss software, said that the vulnerability the worm exploits has been patched for more than a year and a half and users running outdated versions of the JBoss Application Server should patch their installations immediately.
“Red Hat has become aware of a worm currently affecting unpatched or unsecured servers running JBoss Application Server and products based on it. This worm propagates by connecting to unprotected JMX consoles, then uses the ability of the JMX console to execute arbitrary code in the context of the JBoss user,” wrote Mark Cox, Red Hat’s director of security response. “The worm affects users of JBoss Application Server who have not correctly secured their JMX consoles as well as users of older, unpatched versions of JBoss enterprise products. An update to JBoss enterprise products was produced in April 2010 to correct the flaw, CVE-2010-0738.”
There are instructions for securing the JMX console on the Red Hat site.
