Re: [PATCH] Always list SSL in case any SSL connection succeeded

[Kristof Boeynaems <kristof.boeynaems () gmail com>]

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