Home page logo
/

nmap-dev logo Nmap Development mailing list archives

Re: [PATCH] Always list SSL in case any SSL connection succeeded
From: David Fifield <david () bamsoftware com>
Date: Mon, 2 Mar 2009 09:27:33 -0700

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.

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?

David Fifield

Attachment: nmap_always_print_ssl_3.patch
Description:


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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]