Title: heapdump leaks Shiro key and thus RCE

1. Introduction

I built a vulnerable environment where Spring heapdump leaks shiro key and thus RCE. Github address: https://github.com/P4r4d1se/heapdump_shiro_vuln

Vulnerability Exploit Conditions:

There is a heapdump file leak in Spring Shiro environment and an exploitable chain.

2. Vulnerability Principle

Many bigwigs have shared the principles and debugging analysis of Shiro-related vulnerabilities. I won't go into details here. I will mainly explain this vulnerability environment:

(1) Spring actually has its own default security framework, called Spring Security, but some developments may be used to using Shiro, and replaced Spring Securiy with Shiro. This situation is not uncommon, for example, Ruoyi is Spring shiro.

(2) When there is a key, even the latest version of Shiro still has vulnerabilities, and in many cases, the shiro key will be leaked due to development, deployment and other issues.

(3) In the version with Shiro greater than 1.2.4, the key is changed to random generation without the manual intervention of the developer. This random generation is that the key will not change before restarting each time the web environment is started. It can be found in the JVM virtual machine memory.

(4) Spring's heapdump file is exported from the JVM virtual machine memory.

To sum up, this combination vulnerability has been created.

3. Vulnerability Demonstration

After loading the vulnerable environment, you can see that Shiro version is 1.8.0:

Access the /actuator/heapdump on port 8080 to get the heapdump file:

There are two ways I often use to get the shiro key:

(1) JDumpSpider: https://github.com/whwlsfb/JDumpSpider

This widget can automatically crawl variable information in heapdump, which is more convenient. The disadvantage is that it may miss information that is not in the crawl list.

Run :java directly -jar JDumpSpider.jar heapdump to automatically obtain variable information. Here you get ShiroKey (2) jvisualvm.exe: Java's own tool, the default path is: JDK directory/bin/jvisualvm.exe

This tool needs to manually find the information you want, enter org.apache.shiro.web.mgt.CookieRememberMeManager in the filter, and the 16 bytes circled are the key

Use a Python script to convert it into a base64-encoded Shiro key: use a Python script to convert it into a base64-encoded Shiro key:

import base64

import struct

print(base64.b64encode(struct.pack('bbbbbbbbbbbbbbbbbbbb', 109,-96,12,-115,33,59,24,112,44,124,56,110,-15,59,1,-41))) Use the obtained key for successful utilization:

Restart the server and get the shiro key again. You can see that the key has changed. The third point of the vulnerability principle is verified. Each time you start, a random key is generated:

Switching to a new key can still be utilized:

Reprinted from the original link: https://xz.aliyun.com/t/11908