Nmap Development mailing list archives
Re: [PATCH] Always list SSL in case any SSL connection succeeded
From: Kristof Boeynaems <kristof.boeynaems () gmail com>
Date: Mon, 2 Mar 2009 21:00:05 +0100
On Mon, Mar 2, 2009 at 5:27 PM, David Fifield <david () bamsoftware com> wrote:
On Tue, Feb 24, 2009 at 10:09:35PM +0100, Kristof Boeynaems wrote:David Fifield wrote:On Sun, Feb 22, 2009 at 12:04:53AM +0100, Kristof Boeynaems wrote:A quick patch for the 'bug' described in http://seclists.org/nmap-dev/2009/q1/0484.html.I think the bug could be fixed in a better way, though. The code already passes (*svc)->tunnel in the case of no match, so the fact that SSL was detected is already recorded. I think you should rather patch getNmapServiceName in output.cc. That's the function that builds up a name from the service info.Thanks for looking into this. In fact, trying to adapt getNmapServiceName() was the first thing I tried, but that does not work, as apparently that function never gets called in the case described above. It seems that Nmap gives up on the ssl tunnel completely, even before that function. I followed the code a bit further, and it turns out that the tunnel that getNmapServiceName() ultimately receives is set by getServiceProbeProbeResults() in portlist.cc. This function in turn gets it from 'serviceprobe_tunnel', which is initialized with the value of SERVICE_TUNNEL_NONE. It seems that the only way that 'serviceprobe_tunnel' (and hence ultimately the tunnel description in getNmapServiceName()) can be changed, is through a call to setServiceProbeResults(). This function is called from nse_nmaplib.cc, and from service_scan.cc. But, this function is *never* called in the test case of above. Thus the tunnel in these cases defaults to SERVICE_TUNNEL_NONE.You're right, my analysis was not quite correct, because the call to setServiceProbeResults is not made if there was no match and no fingerprint. But calling it with no fingerprint is safe, as getServiceFingerprint returns NULL in that case. I think we can get by without a third call to setServiceProbeResults. Can you try the attached patch and see if it does what you want? If so, then we can tweak the SSL output in getNmapServiceName.
I am unable to try out the patch at the moment, but from the code it seems okay; this is indeed a much better (shorter) way to obtain the same results :) I will not be able to do any tweaking in getNmapServiceName in the following two weeks, but I surely can have a look at that later on. Of course, feel free to go ahead without me ;)
Here are the results I get with this patch. # ncat -l localhost 80 # ncat -l localhost 4433 $ ./nmap -sV -p 80,4433 localhost PORT STATE SERVICE VERSION 80/tcp open http? 4433/tcp open unknown? # openssl s_server -cert test-cert.pem -key test-key.pem -accept 80 # openssl s_server -cert test-cert.pem -key test-key.pem -accept 4433 $ ./nmap -sV -p 80,4433 localhost 80/tcp open ssl/unknown 4433/tcp open ssl/unknown And here are examples where a fingerprint should be printed. # ncat -l localhost 80 --exec "/usr/bin/date" # ncat -l localhost 4433 --exec "/usr/bin/date" $ ./nmap -sV -p 80,4433 localhost 80/tcp open http? 4433/tcp open unknown? ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port80-TCP:V=4.85BETA3%I=7%D=3/2%Time=49AC06B2%P=i686-pc-linux-gnu%r(NU SF:LL,1D,"Mon\x20Mar\x20\x202\x2009:17:54\x20MST\x202009\n")%r(X11Probe,1D SF:,"Mon\x20Mar\x20\x202\x2009:17:54\x20MST\x202009\n")%r(FourOhFourReques SF:t,1D,"Mon\x20Mar\x20\x202\x2009:17:54\x20MST\x202009\n"); ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port4433-TCP:V=4.85BETA3%I=7%D=3/2%Time=49AC06B2%P=i686-pc-linux-gnu%r( SF:NULL,1D,"Mon\x20Mar\x20\x202\x2009:17:54\x20MST\x202009\n"); # openssl s_server -cert test-cert.pem -key test-key.pem < /dev/zero # openssl s_server -cert test-cert.pem -key test-key.pem -accept 80 < /dev/zero 80/tcp open ssl/unknown 4433/tcp open ssl/unknown ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port80-TCP:V=4.85BETA3%T=SSL%I=7%D=3/2%Time=49AC082D%P=i686-pc-linux-gnu%r(NULL,90000,"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ ... ==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)============== SF-Port4433-TCP:V=4.85BETA3%T=SSL%I=7%D=3/2%Time=49AC082C%P=i686-pc-linux-gnu%r(NULL,C000,"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 ... I think these are the same results expected with your patch, correct?
Yes, indeed. Thanks! Kristof _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Re: [PATCH] Always list SSL in case any SSL connection succeeded, (continued)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded Kristof Boeynaems (Feb 21)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded David Fifield (Feb 23)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded Kristof Boeynaems (Feb 24)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded Kristof Boeynaems (Feb 24)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded David Fifield (Mar 02)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded Fyodor (Mar 02)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded David Fifield (Mar 02)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded Fyodor (Mar 02)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded David Fifield (Mar 03)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded Kristof Boeynaems (Feb 24)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded David Fifield (Mar 02)
- Re: [PATCH] Always list SSL in case any SSL connection succeeded Kristof Boeynaems (Mar 02)