Hack systems running JBoss JMX Console with the help of Google & Bing

It is well known that Google/Bing dorks continue to be one of the simplest ways to detect vulnerabilities in servers and web services, which is why I decided to make this short post talking about what I consider one of the most effective dorks when it comes to quickly detecting servers potentially vulnerable to Remote Code Execution.

JBoss is a Java Enterprise Edition application server widely used globally. As is known, applications based on Java EE usually have a strong enterprise flavor. That is to say, It is very common to find business management applications written in Java, as is the case with Microsoft's .NET.

One of the peculiarities of JBoss is that it provides, by default, a web-based administration console that allows you to manage, configure and deploy services within the JBoss server. Where is the interesting thing? JBoss allows you to deploy services contained in "WAR" packages directly from the web console, so that if it can be accessed from the Internet without any type of restriction, anyone can deploy Java services on the JBoss server.

The JBoss console is generally located in the /jmx-console path. It's not common to rename this path, so it's easy to find open consoles with a Google search: inurl:"/jmx-console". The service is usually found in ports frequently associated with development (8080, 8081...), although a multitude of them can also be found in ports related to production environments (80 and 443) and even in less common ports.

A practical example

When accessing one of these consoles, we find an interface similar to the one in the following image:

The console displays an index with all available services. We will focus on the MainDeployer service, although the ServerInfo service may also be interesting.

He ServerInfo service displays information about the server architecture and operating system on which the JVM runs.

The JBoss MainDeployer service allows you to deploy WAR containers. The dangerous thing is that it accepts a URL as the source of the WAR container.

What happens if the container that we pass by parameters is located in a server that we control and whose purpose is to deploy a JSP that accepts POST or GET parameters, commands that will subsequently be executed in the system?

Bad news. It is possible to execute remote code on the server. In the case of the previous image (fictional case in a local environment for demonstration purposes), you gain control as the root user on the server. As a reader, If your profile is not technical, this basically means complete and absolute control over the vulnerable server.

By automating the search for JBoss consoles by doing some scrapping, More than two hundred vulnerable servers are found in a few seconds different. Interesting right?