Nmap Development mailing list archives
Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol)
From: Michael Schierl <schierlm () gmx de>
Date: Sat, 13 Mar 2010 13:57:07 +0100
[Please Cc: me as I am not subscribed to the list. Thanks.]
Am 13.03.2010 02:43, schrieb Brandon Enright:
Michael Schierl <schierlm () gmx de> wrote:I tried to write a probe for JDWP, which you can find open in some corporate networks to enable people debugging services running on some servers (an open port in the internet might be desastrous to the security of the system, though, as the debugger can upload any Java code and run it).Yeah this would sure be nice to detect. I don't seem to have any hosts with port 8000 tcpwrapped or I'd test.
It need not be 8000. JDWP does not really have a default port, but 5000, 6000, 7000, 8000, 5050, ... seem to be quite common as they are easy to type. There is even an option in the JDWP agent so that it picks a random port and writes it into a local configuration file (so that you have to look up the port in that file before you can start debugging), so using any magic port numbers will not work here :(
However, JDWP is quite picky about who it speaks to. The conversation has to start with the magic string "JDWP-Handshake", or the socket is closed immediately. In addition, if that string is not received within the first two seconds, the port is also closed.Currently, the null probe will timeout and report the port as tcpwrapped, and my script is not even run. When reducing the timeout of the null probe to 1 second for example, my probe will work (and detect the jdwp version just fine), but of course this is not good for detecting other protocols. I don't really know how I can tell nmap to try this probe on ports that were previously closed (tcpwrpped) when trying the null probe.Well I haven't looked at the code and I suspect the NULL probe wins out over all other probes.
At least when it detects something. I guess so too.
Your jdwp probe did not use the "ports ..." directive. Try adding "ports 8000" to your probe and then move your probe *above* the NULL probe.
Which will not help if the port is different :(
Also, you make use o '.' to match anything so I suspect you want to use the 's' flag at the end of the match to allow . to match newlines.
Those \0\0.. are in fact (big endian) length information for the next field, so if the field is 10 bytes long, this will indeed mean that I should add the s option. Good catch :)
Finally, you capture the the entire rest of the response with (.*). This has a reasonably high chance of run-away matching and then causing Nmap to print an error that too much content was matched. Since it becomes the v// string, you should think about trying to restrict to something like [a-zA-Z0-9 _-].
I guess there is no way to parse the (\0\0..), find its binary value and match just that amount of bytes? As the next packet (which should not happen as I did not subscribe to any events yet) will start with a length field and therefore at least one \0, matching it against [^\0] should help as well. Some implementations do have a \n in their version string, though...
This is good info. I'm thinking though that rather than a probe and match, this would be better handled with a NSE version script. You could handle the tcpwrapped problem easily. You could even send a command to gather system info like "uname -a" if possible.
The JDWP version command will include the Java and the JDWP version. Getting more information would indeed be possible (there are Java methods to get os.name, os.arch and so on), but even when coding this in Java, against the official JDWP client library, it takes about 300 lines of code (been there, done that). You will have to enumerate the threads, take one at random which is currently not doing IO, send a suspend command, wait for it to suspend, send commands to run some bytecode on that thread, gather the results, and make sure to resume the thread afterwards or the application may have problems if it was an important thread and stays suspended forever. Besides, this is nmap and not Nessus or Metasploit, so first thing is to detect that it is jdwp (which should work well even by using the matches in this probe) and then you can still run other tools to get more information or try to "exploit" it.
Would you be willing to convert this probe/match to a version script? You can look at the Skype version script for a messy example of how to write a version script.
I might have a look when I find time to do so. I suppose a script can also parse the big endian numbers and get the version info exactly? If anyone else who has more experience with nmap scripting volunteers, I won't be unhappy either :-) Regards, Michael _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) Michael Schierl (Mar 12)
- Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) jrf (Mar 12)
- Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) Brandon Enright (Mar 12)
- Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) Michael Schierl (Mar 13)
- Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) Michael Schierl (Mar 16)
- Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) Brandon Enright (Mar 16)
- Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) Michael Schierl (Mar 16)
- Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) David Fifield (Mar 16)
- Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) Michael Schierl (Mar 17)
- Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol) David Fifield (Mar 17)