Re: Problems writing a nmap-service-probe for jdwp (Java debug wire protocol)

[Michael Schierl <schierlm () gmx de>]

> > [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/