Spring Actuator - Stealing Secrets Using Spring Actuators - Part 1:

Spring is a set of frameworks for developing Applications in Java. It is widely used,  so it is not unusual to encounter it during a security audit or penetration test. One of its features that I recently encountered during a Whitebox audit is actuators. In this series of articles, I will use them as a case study for security testing - first describing the risk involved in exposing actuators to the Internet by demonstrating how they can be used to steal secrets from your applications, using a basic Spring application as a case study. In the next parts of the series, I will discuss how to detect misconfiguration using static code analysis and dynamic testing, and finally, how you can secure those actuators that you absolutely cannot leave turned off.

What are Actuators?

Actuators expose information about the running Spring application via (amongst others) a REST API and can be used to retrieve data from the system, or even make configuration changes if configured (in)correctly. They can be quite helpful in debugging or monitoring a Spring application , but if you expose them too widely, things can get dangerous very quickly.

By default, only the health check endpoint is enabled over REST, listening at /actuator/health. However, it is possible to enable additional endpoints, for example, to expose metrics to Prometheus for monitoring. This can be done through settings in the relevant .properties file (or its YAML equivalent):

# Enable Prometheus endpoint in addition to health check
management.endpoints.web.exposure.include=health,prometheus

It is also possible to enable all endpoints for access over REST, by using the following setting in the relevant .properties file:

# Do not do this! This is insecure!
management.endpoints.web.exposure.include=*

This is the config that I found during a recent engagement - and since the application was explicitly configured to expose all actuators without any authentication, I was curious to see what other actuators exist, and how they could be leveraged to attack the application. The result was this article series (and a call to the customer, telling them to make some changes to their configuration right now).

Exploiting Public Actuators

Conveniently, Spring provides a list of all actuators that are present by default and can be enabled. They include actuators for reading (and writing!) the log configuration, the application environment (including environment variables), and even the logs of the application. Even more conveniently, by default, it will show you the list of enabled actuators if you simply access /actuator, removing the guesswork out of determining which actuators you have to work with.

I've created a basic, vulnerable Spring application that exposes all endpoints if you want to follow along at home. Running it locally on your machine and accessing the Spring actuators endpoint, you will get the following output:

$ curl localhost:8081/actuator | jq .
{
  "_links": {