Spring Boot Actuator is widely used for Java application observability, found in over 60% of cloud environments, but its exposure can lead to serious security risks when misconfigured. These misconfigurations can lead to exposure of sensitive data and credentials (e.g., API keys, tokens, and passwords) and even enable remote code execution (RCE) in certain versions of Spring Boot.
We set out to analyze how organizations are deploying Spring Boot Actuator in the cloud, and actively detect misconfigurations within our customers’ environments. Our analysis has revealed that these weaknesses are more common than one might expect, occurring in 1 out of 4 of environments with publicly exposed Actuators.
This blog aims to raise awareness of these risks and offer actionable insights to help organizations protect themselves. We’ll cover:
• Possible Spring Boot Actuator misconfigurations
• How they might manifest in an organization’s cloud environment
• The potential impact, including data exfiltration and RCE exploitation
While closely related, Spring Boot and Spring Boot Actuator serve distinct roles in application development. Spring Boot is a popular framework designed to simplify the development of Java applications by providing a streamlined approach to building production-ready applications, while Spring Boot Actuator is a specialized module within Spring Boot that enhances the functionality of Spring Boot applications by providing critical insights into the applications' health and operational status. This allows developers to monitor application metrics, manage configurations and gain real-time visibility into performance and resource usage.
However, in the words of the late Uncle Ben, “with great power comes great responsibility”, and misconfigurations in Spring Boot Actuator’s endpoints can lead to severe security vulnerabilities that attackers can easily exploit. Common mistakes include exposing components that leak sensitive credentials such as environment variables, passwords and API keys, and some mistakes can even lead to remote code execution.
As opposed to vulnerabilities with CVEs which are tied to specific versions of the affected software, misconfigurations are more difficult to manage, for several reasons: a patching isn’t a relevant solution, since they often have the potential to affect any and all versions of the affected software; they are usually caused by human error stemming from lack of familiarity with best practices; and in some cases software can even be configured insecurely by default. These misconfigurations could be exploited by an attacker that can utilize it for initial access into your environment or even for moving laterally.
In this blogpost we will discuss and explore some common misconfigurations derived by human errors or insecure default configurations. Why and how attackers target these security flaws and come up with some speculations about these misconfigurations being exploited for initial access.
According to Shodan, around 92,000 endpoints worldwide are currently running Spring Boot Actuator. Threat actors appear to be well aware of this fact, as in the past 30 days alone, GreyNoise observed around 1K malicious IP addresses scanning for Spring Boot Actuator endpoints and 1K unique addresses specifically targeting its health check directory with about 95% of those marked as malicious.
According to Wiz data, 60% precent of cloud environments have at least one instance of Spring Boot Actuator, while 11% of such environments have instances that are publicly exposed to the Internet, and 24% of environments with exposed Actuators have misconfigured instances detected by Wiz Dynamic Scanner.
These numbers highlight not only the widespread use of Spring Boot Actuator in cloud environments, but also its strong appeal to attackers. While the monitoring functionality of Spring Boot Actuator is incredibly valuable for organizations using Spring Boot, it also introduces a unique set of security concerns if not carefully managed, as detailed in the following section.
The Spring Boot Actuator heapdump endpoint is designed to capture the current state of the Java heap, making it a valuable tool for diagnosing memory issues. However, if credentials such as passwords, tokens, cloud keys, or other secrets are loaded into the memory of a Java application’s JVM during its runtime, these might be included in the heap dump. Therefore, if accidentally configured to be publicly exposed, this endpoint could reveal this sensitive information to unauthorized users.
Up until version 1.5 (released in 2017), the /heapdump endpoint was configured as publicly exposed and accessible without authentication by default. Since then, in later versions Spring Boot Actuator has changed its default configuration to expose only the /health and /info endpoints without authentication (these are less interesting for attackers). Despite this improvement, developers often disable these security measures for diagnostic purposes when deploying applications to test environments, and this seemingly small configuration change may remain unnoticed and thereby persist when an application is pushed to production, inadvertently allowing attackers to obtain unauthorized access to critical data.
According to Wiz data, 2.3% of exposed Spring Boot Actuator instances in cloud environments have their heap dump endpoint exposed without authentication.
Retrieving the Spring Boot Actuator heap dump is very easy – all you need to do is send an HTTP GET request to /actuator/heapdump or /heapdump, for example:
Once obtaining a heap dump, attackers can then use simple tools like strings and grep to extract sensitive data from it. Here are a few examples:
AWS Access and Secret Keys: Search for AWS key patterns within the heap dump:
strings heapdump | grep -B 2 -A 2 "AKIA"
JWT Tokens: Locate JSON Web Tokens (JWT) captured during HTTP requests:
strings heapdump | grep -B 2 -A 2 "eyJ"
Cookies and session tokens: HTTP request capture including cookies/tokens of legitimate users:
strings heapdump | grep -E "^Host:\s+\S+$" -C 10
These credentials could provide elevated access to the server hosting the application, the application itself, other servers in the environment, or even to the cloud control plane. By failing to properly secure this endpoint, organizations risk exposing this vital data falling into the hands of malicious actors, allowing them to gain initial access to critical systems.
Spring Boot applications using Spring Cloud Gateway versions 3.1.0, 3.0.0 to 3.0.6, and older unsupported versions are vulnerable to remote code execution (CVE-2022-22947).
According to Wiz data, 28% of cloud environments using Spring Cloud Gateway have at least one instance running these vulnerable versions. Exploitation requires the Gateway endpoint to be configured for unauthenticated public exposure. Although Spring Boot Actuator Gateway endpoints are not exposed by default, they can be insecurely misconfigured to be publicly accessible without authentication.
Regardless of this vulnerability, there are significant risks associated with exposing the /gateway/routes endpoint, as it inherently allows for Server-Side Request Forgery (SSRF) by design. This endpoint can be abused to access internal services, cloud metadata services (if IMDSv1 is enabled on the host) and other sensitive resources.
To check if the Spring Boot Actuator Gateway endpoint is exposed without authentication, simply attempt to access /gateway/routes or /actuator/gateway/routes.
If the application responds with a 200 status code and contains fields like predicate or route_id in JSON format, it indicates that the endpoint is enabled and exposed to the internet.
After confirming that the gateway endpoint is publicly exposed without authentication, an attacker can craft a malicious route that forwards requests to the AWS Instance Metadata Service (IMDS) accessible at http://169.254.169.254. This is done by sending an HTTP POST request to the new route, containing a JSON object with the route matching conditions and the specification of where to forward the requests:
Next, a refresh is necessary to update the gateway’s routing configuration:
The new route was created successfully:
At this point, if IMDSv1 is enabled on the host, the attacker can enumerate the available routes and retrieve the AWS security credentials of the instance (if IMDSv1 is disabled, the attacker would receive a 401 Unauthorized error, as IMDSv2 requires a secret token for authorization):
In this proof of concept, we used an EC2 instance configured with IMDSv1, which allowed us to successfully retrieve security credentials via the metadata service. By default, AWS enforces IMDSv2 on newly launched instances, but organizations should make sure all EC2 instances are configured with IMDSv2, which prevents unauthorized access to metadata.
Combining the exposure of the /gateway/routes endpoint with a vulnerable version of Spring Cloud Gateway allows attackers to exploit the CVE-2022-22947 vulnerability and remotely execute code on the server.
This critical vulnerability arises from inadequate input validation. An attacker can send an HTTP POST request to /gateway/routes/new_route_name to create a new route. The arguments sent in the body of this request are vulnerable to code injection. In the following demo the injected code triggers a curl command to Burp Collaborator temporary domain:
Once an attacker sends the request with the intended payload they should also send a refresh request to add the new route:
The refresh request is what triggers the code execution. The screenshot below shows the server's request to our Burp Collaborator:
ENV endpoint exposure is a well-known misconfiguration that can affect a wide variety of platforms. In Spring Boot Actuator, the /actuator/env endpoint is specifically designed to expose details about the application’s runtime environment. When accessing the env endpoint, it returns a structured JSON response displaying configuration properties and environment variables used by the application. This can include values from multiple sources, such as system environment variables (e.g., JAVA_HOME, PATH), application properties, and external configuration sources. Consequently, it can expose sensitive information, including database credentials, API keys or tokens, and cloud keys.
According to Wiz data, 4% of exposed Spring Boot Actuator applications in cloud environments have their env endpoint publicly accessible without authentication. Like the heapdump endpoint, up until version 1.5, this endpoint was publicly exposed without authentication by default.
Using the same methodology described above for analyzing the heap dump, you can detect sensitive data within exposed env files, like in the following example:
In addition to the critical risks associated with the /heapdump, /env and /gateway/routes endpoints, it is important to recognize that other actuator endpoints such as /metrics, /threaddump and /scheduledtasks can also expose sensitive data that could be valuable for attackers. To safeguard your application, it is recommended to limit access to the actuator’s endpoints and ensure that endpoint are not unnecessarily publicly exposed without authentication.
The following example shows the http.client.requests metric exposing sensitive details including an internal IP address, a potentially sensitive "session" endpoint, and request patterns. Such information could be leveraged by attackers to map the application and strategize future attacks.
Credential disclosure—such as cloud keys, tokens, and passwords—poses a significant threat to organizations. When exposed, this information aids attackers in gaining initial access as well as facilitating lateral movement and privilege escalation in the course of complex, multi-stage attacks; while immediate remote code execution (RCE) might not always be feasible, these details support reconnaissance efforts, expanding attackers’ capabilities and potential access to sensitive resources. For example, while a given set of cloud keys might not grant full control over an entire cloud environment, they might provide attackers with enough privilege to enumerate resources and escalate their level of access. As attackers accumulate entry points and footholds within a compromised environment, they can keep returning to this treasure trove of sensitive data to deepen their infiltration and expand their reach.
Additionally, unauthorized access to sensitive endpoints opens doors to severe exploits, such as the abovementioned Spring Boot Actuator Gateway RCE (CVE-2022-22947), which attackers cannot exploit unless the gateway endpoint was misconfigured to be publicly exposed without authentication. To prevent such risks, organizations should protect credentials and sensitive data by enforcing strict authentication and least-privilege access controls by default, minimizing the chances of malicious unauthorized access leveraging unintentionally disclosed information.
Surprisingly, as far as we know there is currently no widely documented real-world threat activity known to exploit specific Spring Boot Actuator misconfigurations such as exposed heapdump files or the ENV endpoint. However, that does not mean that these weaknesses should be overlooked. While much of the focus in security conversations tends to be on vulnerabilities tied to CVEs, misconfigurations like those described in this blogpost can be just as useful for threat actors, and therefore must be accounted for in both prevention and detection efforts.
Furthermore, it is possible that historical breaches have occurred due to these misconfigurations but were attributed to other attack vectors or went undetected. This issue isn’t unique to Spring Boot; shifting focus to often-overlooked misconfigurations, which are not as actively monitored or easily patched as CVEs, can help organizations identify blind spots and prevent potential attacks. By expanding the scope of software security scanning beyond just CVEs, we can gain a more comprehensive view of attack surface areas and better safeguard sensitive systems.
Organizations can defend themselves against the risks posed by Spring Boot Actuator misconfigurations by implementing the following steps:
Ensure that sensitive Spring Boot Actuator endpoints, such as heapdump , gateway and env are protected by proper authentication and authorization mechanisms.
To enforce authentication, use Spring Security
To restrict access to sensitive endpoints, edit the application.properties file to disable and exclude sensitive endpoints:
Or edit your application.yml file, and exclude endpoints from exposure:
Or use Java Configuration and create a configuration class to programmatically exclude sensitive endpoints:
If Spring Boot Actuator is publicly exposed to the internet, then minimize the exposure and allow only authorized IP addresses to access it.
Keep Spring Boot Actuator and its associated libraries up to date, ensure the latest security features are enabled, and enforce secure default configurations.
The Wiz Dynamic Scanner detects publicly exposed Spring Boot Actuator instances within customers’ cloud environments. Moreover, it detects instances of Spring Boot Actuator that are misconfigured and expose sensitive endpoints such as /actuator/heapdump, as demonstrated in the screenshot below:
Wiz customers can find any findings in their environment related to the above mentioned misconfigurations by viewing the Attack Surface Findings page.
Moreover, Wiz also helps prioritize issues by identifying additional associated risks, such as whether a misconfigured resource has high privileges in your environment or exposes cloud keys that grant high privileges.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。