Over the past few months, the distribution vector for "Ransomware" has shifted to a more targeted approach.
Several hospitals and healthcare organizations recently found themselves the victim of a widespread Ransomware infection.
Exploits against JBoss are believed to be responsible for several of these incidents, where a compromised JBoss server allowed access to the hospital's internal network.
For an excellent writeup of Ransomware infections using the JBoss exploits, see the Cisco Talos blog: "SamSam: The Doctor Will See You, After He Pays the Ransom"
Note that "JexBoss" is described as the exploit tool of choice. JexBoss exploits very old vulnerabilities in JBoss, and takes advantage of poor upgrading or patching policies.
Via Shodan or Google 'dorking', one can determine that there are a great deal of JBoss deployments.
It can be safe to assume that many of these deployments likely remain vulnerable.
While healthcare and hospitals are the target 'du jour', other high profile industry segments running old JBoss, may be targeted next.
In an effort to raise awareness to the JexBoss exploit and what it looks like from the victim's point of view, we stood up two vulnerable JBoss servers and exploited them using JexBoss.
We're providing some screen shots of JexBoss in action, along with the network packet captures from the vantage of the victim. We also will provide a list of the Snort and Emerging Threat IDS signatures that currently alert on this traffic.
Our test environment consisted of two Amazon EC2 instances running RedHat linux. I configured the first instance to run JBoss v6, and the other to run JBoss v4.
Please don't bother to test or "attack" the EC2 instances I used. They are firewalled to the world, except to my IP :)
The attacking environment was a simple Debian linux VM with JexBoss installed.
Attacking JBoss 4
Running JexBoss against a vulnerable host is quite trivial. You simply provide the URL of the JBoss instance, and hit Enter.
The following image shows how JexBoss found the JBoss web-console, jmx-console and JMXInvokerServlet as being vulnerable.
|JexBoss attack against a JBoss v4 host|
In this example, I ran the exploit against jmx-console. I then ran the linux 'ls' command to display the files on the compromised host.
Saying "Yes" to automated exploitation of jmx-console will instruct the victim server to pull a remote exploit toolkit named "jbossass.war" from 'joaomatosf.com'.
|Victim server fetching remote exploit toolkit|
Once the exploit code is deployed, a command shell is launched and a few host identification commands are automatically run.
Subsequent runs of JexBoss will not fetch the toolkit if it is already present on the victim host.
In this next example, I ran the exploit against the JBoss web-console.
Once the toolkit is resident on the JBoss instance via the JexBoss exploit, you can use the compromised host to fetch more files of your choice. Note how I used the 'curl' command to fetch a remote text file and display it on the console.
|Using JexBoss to fetch a remote file via the compromised host.|
In this example, I fetched the same file and saved it to the compromised host. Running the linux 'ls' command after the fetch reveals the file is now resident on the JBoss host.
|Using JexBoss to fetch and save a remote file to the compromised host.|
Here is a look at a log segment from the victim host after the exploits were run. A few exceptions are thrown, and Warnings and Info are logged.
|Log file segment showing Warnings and Info after JexBoss exploit|
Attacking JBoss v6
Attacking JBoss v6 is quite similar, except the web-console is not vulnerable, and exploiting the JMXInvokerServlet can be hit or miss.
However, the jmx-console is as easily exploited as it was in JBoss version 4.
|JexBoss exploit against the jmx-console on a JBoss v6 host|
|JexBoss exploit against the jmx-console on a JBoss v6 host - Remote file fetch|
By virtue of this very simple exploit tool, it's quite apparent that old versions of JBoss are extremely vulnerable to full attacker control.
With the continually evolving news of organizations falling victim to ransomware via JBoss exploits, it of critical urgency that any JBoss instance be checked and patched.
I actually wonder how many organizations are even aware that they are running JBoss, let alone a vulnerable instance of it.
A breakdown of the security vulnerabilities in JBoss, the versions affected, and the pertinent dates, can be found at CVEDetails - JBoss
We wanted this post to provide a glimpse of a JBoss exploit from the vantage of the victim. We hope that this blog post helps raise further awareness to this serious threat, and provides some additional information to help detect and defend against these attacks.
Files and Additional Information:
The following Snort and Emerging Threat IDS signatures will detect these JexBoss probes and exploits
[1:2014017:1] ET WEB_SERVER JBoss jmx-console Probe
[1:2801445:3] ETPRO EXPLOIT RedHat JBoss Enterprise Application Platform JMX Console Authentication Bypass
[1:24642:4] SERVER-WEBAPP RedHat JBoss Enterprise Application Platform JMX code execution attempt
[1:18794:9] SERVER-WEBAPP RedHat JBoss Enterprise Application Platform JMX authentication bypass attempt
[1:21516:9] SERVER-WEBAPP JBoss JMX console access attempt
[1:1054:14] SERVER-WEBAPP weblogic/tomcat .jsp view source attempt
JexBoss attack traffic - Vantage of a JBoss version 6 host:
JexBoss attack traffic - Vantage of a JBoss version 4 host (remote toolkit fetch):
JexBoss attack traffic - Vantage of a JBoss version 4 host (remote file fetch and display):
JexBoss attack traffic - Vantage of a JBoss version 4 host (remote file fetch and save to victim host):