JDWP Misconfiguration in Container Images and K8s

Java Debug Wire Protocol (JDWP) is a great way to remotely debug applications during development. However, if enabled when shipped to production, hackers can exploit this mistake by running arbitrary code that allows initial access or privilege escalation in your production environment.

Using Aqua's Dynamic Threat Analysis (DTA) scanner, Team Nautilus detected dozens of misconfigured container images in Docker Hub, which belong to large organizations and may expose them to severe risk when running in production.

What is JDWP?

JDWP allows developers to remotely debug Java applications. This feature is disabled by default, but when activated, it allows developers to remotely debug the code. If it was enabled during the development phase and mistakenly released into production while still enabled, an attacker can exploit this misconfiguration as an initial access or to perform privilege escalation.

From within the network or using the exposed debugging port, a remote attacker can instruct the JVM to load arbitrary Java classes into memory and leverage these to achieve remote code execution.

JDWP in Containers and Kubernetes

In containers, you first need to set up the debugger and set a port to listen to dt_socket, then expose a port when running a container. When running in Kubernetes, the pod needs to run under 0.0.0.0, otherwise it will be listed to localhost, and an external attacker won't be able to gain access.

Over a period of one year, Team Nautilus detected 114 distinct Docker Hub accounts that had at least one container image with JDWP misconfiguration. In total, we've seen 193 distinct container images.

Mitigation

• Do not use JDWP in production environment. Start the JVM without any agents enabled.
• Restrict remote debugging to trusted hosts by modifying network and security policy configurations.
• Scan your images for JDWP misconfigurations with a dynamic threat analysis tool like Aqua's DTA.