Oracle TNS Service Detection: match line behavior oddness

[Tom Sellers <nmap () fadedcode net>]

This morning I started working on the Oracle TNS Listener match lines
in nmap-service-probes with the goal of trying to improve the remote
version detection.  In my test scenarios nmap would detect the TNS
listener but it would not return the platform or version number, which
I know can be triggered by the right packet.


What I found is that everything that is needed is already in the probes
file, but that, at least in my tests, the data I expected is not returned.


After testing some more I found that I do not understand why nmap is
behaving a certain way.  Hopefully someone can shed some light on this
for me....


Here is the relevant section of the nmap-service-probes file from SVN,
it starts on line 6633 (I have added line numbers for reference):

6633:Probe TCP oracle-tns q|\0Z\0\0\x01\0\0\0\x016\x01,\0\0\x08\0\x7F\xFF\x7F\x08\0\0\0\x01\0 
\0:\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\04\xE6\0\0\0\x01\0\0\0\0\0\0\0\0(CONNECT_DATA=(COMMAND=version))|
6634:rarity 7
6635:ports 1035,1521,1522,1525,1574,1748,1754
6636:match oracle-tns m|^\0.\0\0\x02\0\0\0.*TNSLSNR for ([-.+/ \w]{2,20}): Version ([-\d.]+) - Production|s p/Oracle 
TNS Listener/ v/$2 (for $1)/
6637:match dbsnmp m|^\0.\0\0\x02\0\0\0.*\(IAGENT = \(AGENT_VERSION = ([\d.]+)\)\(RPC_VERSION = ([\d.]+)\)\)|s p/Oracle 
Intelligent Agent/ v/$1/ i/RPC v$2/
6638:match oracle-tns m|^\0.\0\0\x02\0\0\0|s p/Oracle TNS Listener/
6639:match dbsnmp m|^\0,\0\0\x04\0\0\0\"\0\0 \(CONNECT_DATA=\(COMMAND=version\)\)| p/Oracle DBSNMP/



Now, in my scans it is line 6638 (Oracle TNS Listener) that returns
results.  So I started looking at the more informative line 6636
to see what I could do to the regex to get this to match.  After
commenting them all out, looking at the response, tweaking the
regex and generally getting confused by the results I discovered
something.

Line 6636 **DOES** match if line 6638 is commented out or changed to
a softmatch.  I reran the tests by downloading a fresh probes file
from SVN and running scans against multiple targets with line 6638
working and disabled.

In each case the match for line 6636 was over ridden by line 6638 which
is 2 match lines further along.  I thought that the first match would
return results (win) and that match line testing would only continue if
the first match was against a softmatch line.

I also removed all of the scripts from the scripts folder to ensure that
they were not confusing the issue.  Incidentally, nmap does not like
this much even after running --script-updatedb.

I looked through the service detection documentation and didn't see
anything that I though explained this.

What am I missing here?  Any thoughts?

Thanks much,

Tom


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