Recording an incident of spring boot interface information leakage leading to AWS s3 bucket takeover.

Incident Background#

While digging into the assets of a certain SRC, it was discovered that a third-level subdomain had a historical resolution IP address pointing to an Amazon server. It was found that this IP address had a spring boot interface leakage vulnerability.

By analyzing the response, the plaintext of the AWS_SECRET_ACCESS_KEY encrypted with asterisks was obtained, and successful access to container resources was achieved.

However, despite knowing that it would be ignored, the vulnerability was still reported, resulting in a frustrating story.

Discovering the Interface#

Directly accessing the IP address resulted in a blank page, and entering random text after the IP address caused an error, which is a classic error page of spring boot.

So, the next step was to scan for misconfigured interfaces. Although there are many scanning tools available, the recently popular one is springboot_scan by the great winezer0.

Of course, you can also use traditional directory scanning tools like dirsearch, just like I did.

I was about to go to bed, so I copied the results to a text file after finishing the scan.

As you can see, there are interfaces like /env. Accessing the env interface gives the following result:

It can be seen that this is a standard env configuration information leakage, with all internal IP addresses and important information encrypted with asterisks.

Spring Boot Penetration Tip#

Here, I recommend a project on Github called SpringBootVulExploit.

Learning materials for SpringBoot-related vulnerabilities, a collection of exploitation methods and techniques, and a black-box security assessment check list.

It is very detailed and provides guidance on how to penetrate when you discover certain interfaces in spring boot.

You can see that the first two lines at the top are my attempt to receive encrypted content using a VPS (unsuccessful) based on this project.

Extracting Sensitive Information#

After searching through the response, it was found that there is AWS-related content, with AWS_ACCESS_KEY_ID in plaintext.

However, AWS_SECRET_ACCESS_KEY is encrypted with asterisks, and there is also the AWS region.

This AWS region is required for subsequent login. If it is not found in the response, you can query the location of the IP address first.

Then, based on the official region code documentation, determine the region and obtain the corresponding region name.

Returning to the main content, how can we obtain AWS_SECRET_ACCESS_KEY?

The method I prefer is to directly download the heapdump data package and parse it.

Heapdump refers to the JVM heap, and the downloaded file size is usually between 50MB and 500MB, sometimes even larger than 2GB.

The recommended method in the aforementioned Github project is to use the Eclipse Memory Analyzer tool to query, following the steps described in the article.

However, I have tried it a few times and it is not easy to use. So, I downloaded the heapdump file. A professional analysis tool for heapdump has been developed by a great developer in China called heapdump_tool.

It is also easy to use. Configure an environment variable for jhat (which comes with the JDK), followed by the file name (after decompression).

Choose mode 0 in the command line (quickly query data without loading all data), and then directly enter the name of the asterisk-encrypted value you want to query.

Here, I queried the value of AWS_SECRET_ACCESS_KEY, which appears to be a hexadecimal value.

After researching, I wrote two lines of code to solve it:

list = [0x45,0xxx,...,0xxx]
for i in list:
    print(chr(int("{}".format(i),0)),end="")

I obtained a 40-character AWS_SECRET_ACCESS_KEY.

Logging into AWS S3 Bucket#

Using the AWS CLI tool provided by AWS,

Configure the parameters through the command line:

Configure AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as required.
As mentioned earlier, configure the region.
Set the output format to JSON.

Successful login:

Conclusion#

Although it may not seem like much, I managed to take over an AWS S3 Bucket, even if the IP address resolved for this domain may not belong to it.

Despite that, I still reported the vulnerability, but it was ignored.

However, it was a good learning experience, so I am sharing it with everyone.