While testing for bugs on a Vulnerability Disclosure Program, I recently came across a subdomain of the program having an application running on Spring Boot. The application had exposed Spring Boot Actuator endpoints in production, which could lead to a number of issues. In this post, I will share how to exploit one such issue for security impact, when the application has exposed the /heapdump actuator endpoint.
Note: Do not test web apps without permission. I reported this bug along with all other exposed actuator endpoints to the program and they have now fixed it.
Spring Boot Actuator
Spring Boot Framework provides some built-in features to help you manage and monitor your application. These features can be accessed via the actuator endpoints, and are meant to help developers to monitor and debug. Some of the common endpoints are:
- /health
- /info
- /trace
- /metrics
- /heapdump
There are many such actuator endpoints and you can find the complete list of these endpoints with description here. It's definitely worth adding these endpoints to your wordlist. In fact, that's how I discovered the endpoint, while directory bruteforcing the target.
Heapdump
The /heapdump endpoint returns a heap dump from the application’s JVM. It provides a dump file with hprof extension, which is a binary file that can be opened and examined in a memory analyzer tool.
When you visit the /heapdump endpoint, it will automatically download the file on your machine.
Visual VM
Once you have downloaded the file, you need to find a way to open the hprof file and find something interesting, with clear security impact. One way to read the hprof file is by using Visual VM Memory Analyzer tool. Visual VM is a tool that helps you read hprof files, and extract meaningful data out of the dump. You can download VisualVM from here. There is no installation required, you just need to download the tool and run the executable.
After downloading the tool, you can now import the heapdump file in Visual VM. Open the tool -> Go to File -> Load -> Import your file.
On successfully importing the file, Visual VM will give you an initial summary of the dump data on the screen. This includes the server information like JVM information, heap size, classes information, environment information, etc. You can certainly explore by yourself if you know what you're doing and look for interesting objects and classes. There are more than one way of exploitation from here on.
However, since we are looking for a security impact here, a much easier and quicker way of achieving that is simply executing OQL queries on the heapdump data to fetch sensitive information.
OQL
OQL stands for Object Query Language. It is very similar to SQL and used by Memory Analyzer to find interesting data from heapdump using SQL-like queries. OQL represents classes as tables, objects as rows, and fields as columns.
You can open the OQL console in Visual VM to run queries by clicking on the Summary dropdown, and selecting OQL console option.
This should open the OQL window in Visual VM where you can now enter and run queries.
Building queries
As mentioned earlier, OQL queries are similar to SQL, and allow you to query data from the heapdump. From a security impact standpoint, some of the sensitive information we can try and search for in the dump is probably things like session tokens, JWTs, hardcoded credentials, API keys, AWS credentials, etc.
First, I just tried to search for the term "AWS", and that in itself got me a lot of data to look at. There were URLs I could connect to, references to credentials I could try, etc.
select s from java.lang.String s where s.toString().contains("AWS")
The number preceding the variable name is the line where the reference of the variable is. For example, the AWS_SECRET_ACCESS_KEY is preceded by java.lang.String#80962. If we wanted to check the value/usage, we can right click on the variable name, click on 'Open Class in New Tab' and then scroll to the line 80962.
If you are familiar with the format of certain tokens: JWT always begins with "ey...." or AWS_ACCESS_KEY_ID always begins with "AKIA.....", you can tweak your query to directly search for those as well:
select s from java.lang.String s where s.toString().contains("AKIA")
select s from java.lang.String s where s.toString().contains("ey")
You can also try to fetch database strings or other data related to the DB configuration using keywords related to the DB. For example:
This is how we can extract sensitive information from a heap dump when the Spring boot actuator's /heapdump endpoint is exposed in production.
For further reading on this, do check out this awesome research paper: https://www.exploit-db.com/docs/50459
For any questions, feel free to reach out on Twitter
