Spring boot actuator is a tool that allows us to monitor our application built with spring.
We can quickly measure various metrics and monitor traffic on our server or check the status of our database. All this thanks to simple rest endpoints.
Today, in "from 0 to pentesting hero", a slightly different view of this mechanism. I'll demonstrate that it's not safe to have this data publicly available - even when it seems that it's harmless.
In standard configuration, health and info endpoints1 are accessible from the web interface.
If we want others to be available - we need to modify our configuration accordingly.
Of course, you can define individually which links are to be active - separating them with a comma.
A smart programmer could use an asterisk - to make all endpoints available.
Simplifying your life is not a bad thing on its own.
Let's see what this means for security.
Sometimes our application uses some secret data - for example, API keys.
For security reasons, we do not want to hardcode them in source code.
So we often use environment variables, and refer to them in the code.
By making env endpoint accessible - we can list variables available for our application.
In this way someone can know our secrets.
Another underestimated endpoint is heapdump - which returns our process's memory dump.
What can you find there? If you store some secret information in static variables - you can easily find them here.
We will modify our example so that the API key is hardcoded as a static variable.
It's worth using an external tool to view this file.
Eclipse Memory Analyzer2 is one such tool.
On the list of classes we choose the one that interests us and then check the Statics tab.
As you can see, the value defined in the class is clearly visible here.
Another endpoint worth paying attention to, is httptrace.
It displays a list of several recent requests to the server.
So we know when someone sent the query to a given URL.
What's wrong with that? In addition to addresses, there is also a complete list of headers sent by the client.
These headers contain user cookies.
The attack may look like this: the attacker enters the httprace endpoint, refreshes it from time to time - waiting for a user with high privileges to log in to the application.
Then using his cookie - he logs on to someone else's account and performs malicious action.
Is that a scary prospect?
We already know that some of the information you can find here can potentially be useful to an attacker.
So what if we still want to use this tool?
If you do not need it on the production server - it's worth taking care of setting the appropriate exclusions.
You can also do what the documentation suggests - treat these endpoints like all other addresses that should be available only to the administrator or another authorized user.
If you use Spring security - they are protected in the standard configuration.
Icon made by Freepik, prettycons from www.flaticon.com