Re: [NSE] False positive in jdwp-version.nse

[David Fifield <david () bamsoftware com>]

On Sun, Oct 02, 2011 at 03:22:28PM -0500, Tom Sellers wrote:
> On 10/2/2011 1:17 PM, Michael Schierl wrote:
> > Am 02.10.2011 18:50, schrieb Tom Sellers:
> >
> > > > I think the problem lies with the following section of code:
> > > >
> > > >       -- match jdwp m|JDWP-Handshake| p/$1/ v/$3/ i/$2\n$4/
> > > > 1:      local match = {string.match(result, 
> > > > "^JDWP%-Handshake%z%z..%z%z%z\1\128%z%z%z%z..([^%z\n]*)\n([^%z]*)%z%z..%z%z..%z%z..([0-9._]+)%z%z..([^%z]*)")}
> > > > 2:      if match == nil then
> > > >                 -- if we have one \128 (reply marker), it is at least not echo because the request did not 
> > > > contain \128
> > > >                 if (string.match(result,"^JDWP%-Handshake%z.*\128") ~= nil) then
> > > >                     port.version.name="jdwp"
> > > >                     port.version.product="unknown"
> > > >                     nmap.set_port_version(host, port, "hardmatched")
> > > >                 end
> > > >                 return
> > > >         end
> > > > 3:      port.version.name="jdwp"
> > > >         port.version.product = match[1]
> > > >         port.version.version = match[3]
> > > >         -- port.version.extrainfo = match[2] .. "\n" .. match[4]
> > > >         nmap.set_port_version(host, port, "hardmatched")
> > > >         return
> > > >
> > > >
> > > > The output of the first string.match (1:) appears to be a table of nils when parsing the following
> > > > result data:   HTTP/1.1 404 Not Found
> >
> > Which is the strange thing. I did a bit of testing and for me it is an
> > empty table (a table of length 0). I am pretty sure it used to be nil
> > when I submitted the script. But anyway, replacing (2:) by
> >
> > if match == nil or #match == 0 then
> >
> > should do the trick, as far as I have tested it.
> >
> > > > Unfortunately I do not have a jdwp sample to test with and I am not familiar with the protocol so
> > > > I cannot test this logic change reliably.
> >
> > If you have a (Sun) Java Runtime Environment installed, you can open a
> > JDWP port for any Java program you execute in it. In case you don't have
> > a Java program handy, you can also use one of the tools included in the
> > JRE, for example keytool (although really debugging it is quite pointless):
> >
> > $ keytool -gen-key \
> >    -J-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=12345
> >
> > Then when it goes to a prompt, just let it wait (and kill it with ^C
> > when done scanning) and scan port 12345.
> >
> > > Further testing shows that there is an error in my assumptions above.  It looks like this is not
> > > triggered against all unidentified services, but in the situation where the service detection NULL probe
> > > causes the remote host to reset the connection ( READ ERROR [Connection reset by peer (104)] ) which
> > > seems to end probe based detection.  The scripting portion of version detection then picks up and is
> > > able to trigger a response by the targeted host.
> >
> > The scenario I used for reproducing your issue is a service that has a
> > socket read timeout of 1 second and closes the connection on timeout.
> > Whenever it receives something else, it replies with an "x" character
> > (i. e. "nonsense"). That way, the null probe will run into "tcpwrapped"
> > case and result will be filled with "x" characters.
> >
> > Doing the change above fixed it for me. Does it fix it for you, too?
>
> Yes, that change corrected the issue I was seeing.

Thanks, Tom and Michael. Tom, go ahead and commit the fix if it worked
for you.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/