SpringBoot ‘DevTools’ Insecure Deserialization — Analysis & Exploit
By Ahmed Sherif
SpringBoot ‘DevTools’ is one of the common tools which is used to make an easier job for the developers. The tools can be included by just adding it in the dependencies section and then developers can make use of its features.
In our team, we strive to do vulnerability research and automation in order to make sure that our development teams are using the open-source frameworks and libraries in a more secure way.
Since we noticed the rise of the usage of this tool, we decided to give a closer look into it. By going through the official documentation of spring, we realize that ‘DevTools’ has the following features:
1 — Property defaults
2 — Automatic restart
3 — LiveReload
4 — Global settings
5 — Remote applications
The 5th feature looks interesting since it allows the remote connection. We decided to take a further look into that feature.
As per the official documentation:
“The Spring Boot developer tools are not just limited to local development. You can also use several features when running applications remotely. Remote support is opt-in, to enable it you need to make sure that devtools is included in the repackaged archive”
Its mentioned that this feature is not enabled by default, However, in order to enable it, developers have to set a secret password for a remote debugging.
In the above screenshot, it shows that the secret is very weak. Moreover, looking at the official tutorials from pivotal:
It also shows in the tutorial the usage of the weak secret. Given the fact that Pivotal already warned about enabling this feature on production, would this pose any risk if enabled in other environments?
The answer is yes, developers tend to make use of ‘DevTools’ for debugging reasons, either on their local laptops or on a testing environment. We have seen in many Red Teaming Operations¹ an initial foothold where Red Teamers are eager to get a foothold through any of the low-hanging fruits (i.e. Tomcat, Jenkins, etc. with weak passwords), DevTools can also pose the similar risk since developers are making use of this feature in the internal network of the organization, an attacker would be able to compromise the running instance and gain initial foothold in the network.
Further analysis of ‘DevTools’
‘Devtools’ consist of the server and client which can upload the “classloaderfiles” to the server.
Looking at the source code of ‘DevTools’ on GitHub:
Basically it shows that the client of ‘DevTools’ is uploading the classLoaderFiles as a serialized object, which can clearly indicate that on the server level, the deserialization happens.
Testing the deployed version
We have deployed a simple application with ‘DevTools’ enabled and noticed the following issue:
1 — Developers can use ‘DevTools’ over HTTP, which means that anyone capable of intercepting the traffic, would be able to get the ‘secret’ token (which is easily guessed in most cases).
2 — There are no restrictions on the secret and even the official documentation including the tutorial give the perception to the developers that this ‘Secret’ token is not so important or should be unique. Looking closely at this issue we can figure out from Github that many developers have fallen in this mistake.
3 — The ‘Secret’ token can be enumerated.
If the attacker knows the endpoint of the enabled ‘DevTools’, they can brute-force the ‘token’ since the endpoint gives different responses based on the given token.
4 — Unsafe deserialization²
The Remote debugger is allowing any kind of deserialization and there is no mitigation being used in this case.
Wrap-up the attack
The attack scenario would be as follows:
- Red Teamers/ Ethical Hackers would look for the endpoints related to ‘Devtools’ (i.e. /.~~spring-boot!~/restart).
- They will start brute-forcing the ‘AUTH-TOKEN’.
- Forming up a serialized gadget from ‘ysoserial’ or any other tools, depending on which library being used in the running project.
Communication with Pivotal
We have communicated this issue with Pivotal, the company decided to open an issue and to only change the recommendations but not to take any further steps with the other issues.
[1] Red-Teaming Operation: Red teaming is the practice of rigorously challenging plans, policies, systems and assumptions by adopting an adversarial approach. A red team may be a contracted external party or an internal group that uses strategies to encourage an outsider perspective.
[2] Insecure deserialization: Insecure Deserialization is one of the vulnerabilities on OWASP‘s Top 10 list and allows attackers to transfer a payload using serialized objects. This happens when integrity checks are not in place and deserialized data is not sanitized or validated.
Credits
Thanks to my colleague Muhammed Usman for helping to make this demo out.
