JBoss Exploitation

JBoss Application Server [Reference 1] is an open-source Java EE-based application server. An important distinction for this class of software is that it not only implements a server that runs on Java, but it actually implements the Java EE part of Java. Because it is Java-based, the JBoss application server operates cross-platform, usable on any operating system that supports Java. JBoss as was developed by JBoss, now a division of Red Hat.

JBoss Web Server provides organizations with a single deployment platform for Java Server Pages (JSP) and Java Servlet technologies, PHP, and CGI. It uses a genuine high performance hybrid technology that incorporates the best of the most recent OS technologies for processing high volume data, while keeping all the reference Java specifications.

JBoss Vulnerability

JBoss is widely used today and is deployed by many organizations on their respective web servers. Being a useful application, it must have been under target of hackers and malicious users. Though many vulnerabilities and bugs have been found on JBoss and many CVE's have been issued. But today we will look at one of the most critical bug in the JBoss application that can be used widely by cyber criminals. Let's have a look at the default JBoss server

The default state, if not configured properly, can allow attackers to create havoc. As the JMX console [Reference 2] can be accessed remotely usually on port 8080, hackers and malicious users can deploy their on WAR (web archive) file or shells on the server using the DeploymentScanner function in the JBoss console. In the next section, we will have a look on the exploitation in action.

Exploitation of JBoss in Action!

Most of us will start looking for tools like Metasploit, Nmap, Nessus etc! You won't need them here. Yes, you heard it right ! For hacking JBoss server, you don't need much application. All you need is a JSP shell and a browser. We formed a Google dork to search jmx consoles: inurl:jmx-console/HtmlAdaptor and here is the result,

Most of the JBoss server have default authentication to the jmx-console. The default configuration of JBoss does not restrict access to the console and web management interfaces, which allow remote attackers to bypass authentication and gain administrative access via direct requests. We just choose one of the random URL and bingo! We got the access to the jmx-console. Next, we need a JSP Shell. Jsp shells can be easily obtained by searching over the internet. So now, we have a JSP shell to move on.

In order to deploy our shell, we will use the DeploymentScanner in the jmx console by adding a new URL with our shell. Using the addURL() command, it is possible to add a new URL with an application or shell. Jboss will get the application from this URL. The next step is to wait for the DeploymentScanner to deploy the file and then we will access our shell. We uploaded our shell to a site, let's say: abc.com/attack/cmd.jsp. Next we need to deploy it. So we will access the DeploymentScanner in the console.

Next, we will add our URL with the shell in the jmx-console.

Once the URL is added, we will invoke the function. As seen in the figure above, we have a button to invoke the function. Once finished, the application gives a message of successful operation.

We waited for a minute while the shell was being deployed on the server. After that, we accessed our deployed shell. W00t W00t ! We have our shell running on the server perfectly!

What surprised us was that we had a root privilege in the server using our shell

Conclusion

The JBoss default authentication vulnerability is like Christmas gift for attackers! Usually administrators take it lightly. But the aftermath can be fatal. An attacker can successfully gain control over the server using this bug and

Root the server or tunnel it Get access to sensitive information Use the server to deploy malware Use the server in cyber crime campaigns Use the server to host malicious contents Compromise other machines connected to the server

And the possibility may go on! hat administrators need to do?

Should try to avoid and should close remote access If remote access is enabled, a strong password should be applied

A small caution can save your organization's critical data and keep them safe.

Download

White Paper - JBoss Exploitation

Reference

JBoss Application Server SecureTheJmxConsole nb : securityxploded