Threat Advisory: A JBoss AS Exploit, Web Shell code Injection.

JBoss Application Server (or JBoss AS) is an open-source Java EE-based application server. JBoss AS was developed by JBoss, now a division of Red Hat. On late 2012, JBoss AS was named as WildFly.
Recently, Imperva’s ADC had detected a surge in the exploitation of web servers powered by the JBoss AS, probably as a result of the public disclosure of an exploit code that abuse this vulnerability.
The vulnerability allows an attacker to abuse the management interface of the JBoss AS in order to deploy additional functionality into the web server. Once the attackers deploy that additional functionality, they gain full control over the exploited JBoss infrastructure, and therefore the site powered by that Application Server.
While the vulnerability is not new by itself and is known for at least two years, it is amazing to realize that during these years the attack surface had not decayed, but in fact had grown in terms of the number of the vulnerable web application.
The Incident Timeline
On 2011, a JBoss AS vulnerability had been presented in security conventions. Researchers showed that JBoss AS is vulnerable to remote command execution via the ‘HTTP Invoker’ service that provides Remote Method Invocation (RMI) /HTTP access to Enterprise Java Beans (EJB).
On September 2013, NIST had assigned a code execution vulnerability in certain HP products that utilized JBoss AS with a Common Vulnerability Enumeration (CVE-2013-4810).
On the 4^th of October 2013, a security researcher, have made the exploit publicly available. Immediately thereafter, we had witnessed a surge in Jboss AS hacking, which manifested in malicious traffic originated from the infected servers and observed in Imperva’s honey pots array.
The Exploit’s Technical Analysis
Jboss AS is vulnerable to remote command execution via the ‘HTTP Invoker’ service that provides Remote Method Invocation (RMI) /HTTP access to Enterprise Java Beans (EJB).
Java Beans are reusable software components for Java represented as a serializable Java Object. MBean, which stands for Managed Bean, is a type of Java Bean.  javax.management.ObjectName represents the object name of an MBean.  Mbeans are usually used in Java Management Extensions (JMX) technology. Java Management Extensions (JMX) is a Java technology that supplies tools for managing and monitoring applications, system objects, devices and service oriented networks. Those resources are represented by MBeans.

JMX uses a 3-level architecture:

1. The Probe level contains MBeans
2. The Agent level, or MBeanServer, is the core of JMX. It acts as an intermediary between the MBean and the applications.
3. The Remote Management level enables remote applications to access the MBeanServer through connectors and adaptors. A connector provides full remote access to the MBeanServer API while an adaptor translates requests between a given protocol (e.g. HTTP, RMI) and a specific JMX functionality. The Invoker invokes the proper MBean service based on the actual JMX request.

Figure 1 JMX architecture

The detached Invoker allows MBean services to expose functional interfaces via arbitrary protocols for remote access by clients. The HTTP Invoker service, including EJBInvoker and JMXInvoker, includes a servlet that processes posts of marshaled (serialized) org.jboss.invocation.Invocation objects that represent invocations that should be dispatched onto the MBeanServer. Effectively this allows access to MBeans that support the detached invoker operation via HTTP POST requests.

The Vulnerability is composed of public HTTP access to EJBInvokerServlet or JMXInvokerServlet servlets, represented as URL /invoker/EJBInvokerServlet and /invoker/JMXInvokerServlet respectively, and invocation of the MainDeployer MBean. The MainDeplyoer MBean is responsible to deploy a WAR from a remote location.
The recently published exploit, abuses invoker/EJBInvokerServlet to deploy a web shell code that enables the hacker to execute arbitrary Operating System commands on the victim sever’s  system.


Figure 2 Exploit code
The exploit consists of a two steps process:
On the first step, the exploit abuses the EJBInvokerServlet to deploy the malicious Web application ARchive (WAR) from the remote URL http://retrogod.altervista.org/a.war that includes the ”a/pwn.jsp” shell code


Figure 3 A network capture of the malicious web shell injection as reproduced in Imperva’s lab
On the Second step, the exploit sends an operating system command to the injected web shell

Figure 4 A network capture of the commands sent to the malicious web shell injection as reproduced in Imperva’s lab
In The Wild Exploitation
Although this specific JBoss AS security issue has been known to the security community for a few years, it is amazing to realize that during these years the attack surface had not decayed, but in fact had grown in terms of the number of the vulnerable web application.
The number of server exposing their JBoss management interfaces had more than tripled itself (7,000 to 23,000) since the vulnerability was presented on 2011.


Figure 5 Exposed JBoss’ Management interfaces – October 2013 (Google Dork here)

Figure 6 Exposed JBoss’ Management interfaces – 2011
The list of the exposed sites contains some governmental and educational sites. We had identified some of them to be actually infected with a web shell code.
Many of the deployed web shells utilize the original pwn.jsp shell code that was presented with the original exploit, as can be seen in a blog entry posted by one of the attack’s victims.
Figure 5 Blog entry on a server infected with pwn.jsp

On other cases a more powerful web shell was deployed. In these cases, the attackers had used the JspSpy web shell which includes a richer User Interface, enabling the attackers to easily browse through the infected files and databases, connect with a remote command and control server and other modern malware capabilities.

Figure 6 JspSpy User Interface
Recommendations and Mitigation

• JBoss users should harden their web application according to JBoss manual
• Imperva’s customers have been updated with a signature to prevent unwanted access to the vulnerable JBoss AS servlet via our regular content updates.

Where can I learn more?

• Imperva’s CMS Hacking webinar
• A Similar incident that was covered by our last Threat Advisory, and was also covered by KrebsOnSecurity