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.

Image for post
Image for post
The weak secret is mentioned in the official documentation

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:

Image for post
Image for post
Source of Client

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:

Image for post
Image for post
Running an application with ‘DevTools’ endpoint enabled.

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).

Image for post
Image for post
‘DevTools’ is enabled over HTTP

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.

Image for post
Image for post
Developers following the official documentation

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.

Image for post
Image for post
Wrong Secret Given— 403 Forbidden response
Image for post
Image for post
Right, Secret — 500 Internal Server Error Response

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.


Thanks to my colleague Muhammed Usman for helping to make this demo out.

Written by

OSCP | Red Teamer | CTF player | https://sherif.ninja | @sherif_ninja

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store