JBoss Exploits Merge PACSAn Alert To Merge PACS Sites

Image courtesy monitis.com

I'll dispense with the usual apologies for not having recent blog entries. You don't want to know about all the crap going on in my life, both on the personal and professional level. Suffice it to say that one can lead a horse to water, but can't make him play water polo.

Let's cut to the chase. Those of you with Merge PACS might have a problem. Our enterprise has a spoke-server placed at a remote location, which unbeknownst to us, had been setup as open to the world, having ports 80 and 8080 (ask your PACS or IT people) unblocked. Oops number one.

Oops number two involves the fact that Merge PACS server software uses something called JBOSS in its machinations. So just what IS JBOSS, anyway?

From the Wiki:

WildFly,[3] formerly known as JavaBeans Open Source Software Application Server (JBoss AS, or simply JBoss) is an application server authored by JBoss, now developed by Red Hat. WildFly is written in Java and is executable on top of the Java Platform, Enterprise Edition (Java EE), which is available cross-platform.

WildFly is free and open-source software, subject to the requirements of the GNU Lesser General Public License (LGPL), version 2.1.

The renaming to WildFly was done to reduce confusion. The renaming only affects the JBoss Application Server project. The JBoss Community or the Red Hat JBoss product line (with JBoss Enterprise Application Platform) all retain their names.[4]

In other words, it's free software for running web applications, of which AMICAS Merge PACS is one.

Sadly, Merge, like a vast number of other companies, is a step or two behind the latest release of JBoss/WildFly, meaning that hackers of the older versions are free to do their thing. From the November 18 issue of PC World:

Attackers are actively exploiting a known vulnerability to compromise JBoss Java EE application servers that expose the HTTP Invoker service to the Internet in an insecure manner.

At the beginning of October security researcher Andrea Micalizzi released an exploit for a vulnerability he identified in products from multiple vendors including Hewlett-Packard, McAfee, Symantec and IBM that use 4.x and 5.x versions of JBoss. That vulnerability, tracked as CVE-2013-4810, allows unauthenticated attackers to install an arbitrary application on JBoss deployments that expose the EJBInvokerServlet or JMXInvokerServlet.

Micalizzi's exploit installs a Web shell application called pwn.jsp that can be used to execute shell commands on the operating system via HTTP requests. The commands are executed with the privileges of the OS user running JBoss, which in the case of some JBoss deployments can be a high privileged, administrative user.

Researchers from security firm Imperva have recently detected an increase in attacks against JBoss servers that used Micalizzi's exploit to install the original pwn.jsp shell, but also a more complex Web shell called JspSpy.

We were alerted to the problem by the remote site, which experienced the equivalent of a Denial of Service (DOS) attack because the damn rogue application we caught started sending out streams of gibberish (fortunately NOT patient data) fast enough to bring down the system. We were blamed for having the infection, and it did indeed nest there on our server, but the infection actually came through our hosts' network. That gap has now been sealed.

Here's the more detailed description from my PACS guys:

On Wednesday our PACS vendor Merge acknowledged a JBOSS vulnerability within the PACS application. The exploit was a worm that scoured the Internet for all un-patched JBOSS versions 4.x and 5.x that were accessible via TCP port 8080. Because TCP port 8080 was open on the firewall for the spoke PACS server the worm was able to find and infect the PACS server. The exploit only affected the PACS server because it runs JBOSS. After we examined what the worm was trying to accomplish, it was determined that the payload consisted of PERL scripts designed to take the server and network down. On Tuesday afternoon, we created a script that constantly killed the process that was overloading the network and that protected the network until Merge could create a patch.

Merge's software development team and IT Security recreated the affected server in a test environment and were able to reproduce the exploit. They created a patch and thoroughly tested it. As of 4pm Thursday, Merge patched the security hole within JBOSS and the site closed TCP 8080 and TCP 80 on the firewall securing the server against further attacks from this exploit.

Merge has assured us that no patient data was compromised or sent out as a result of this exploit.

My compliments to Merge for acting VERY quickly to contain this problem. We were about to be forced off-line as a shotgun fix to the situation. Which would have compromised patient care, but that's another story.

So...to all Merge PACS customers...please contact Merge to see if you need this patch. Most likely, you do. But don't everyone call them all at once, please.