Re: NSock error when scanning nessusd

[Brandon Enright <bmenrigh () ucsd edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 13 Jun 2008 17:40:47 -0500 or thereabouts Tom Sellers
<nmap () fadedcode net> wrote:

...snip...

> After checking that the service response to the probe matched the
> match line I ran the scan again with -d and -v.  I can see where
> nessus gets a service match here:

...snip...

> but then it does this:
>
> NSOCK (6.2400s) msevent_new (IOD #2) (EID #41)
> NSOCK (6.2400s) SSL/TCP connection requested to xxx.xxx.xxx.113:1241
> (IOD #2) EID 41 NSOCK (6.2400s) msevent_delete (IOD #2) (EID #34)
> NSOCK (6.2400s) wait_for_events
> NSOCK (7.3500s) wait_for_events
> NSOCK (7.3500s) Callback: SSL-CONNECT ERROR [Unknown error (10107)]
> for EID 41 [xxx.xxx.xxx.113:1241] Got nsock CONNECT response with
> status ERROR - aborting this service NSOCK (7.3500s) msevent_delete
> (IOD #2) (EID #41)

...snip... 

Hi Tom,

I recently ran into this too because I modified the Nessus match lines
to cut down on false positives.

The trouble seems to be that Nessus uses TLSv1 exclusively and OpenSSL
doesn't seem to detected that properly.

Here is an example:

$ openssl s_client -connect 127.0.0.1:1241
CONNECTED(00000003)
7640:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:188:

But using -tls1 you get:

$ openssl s_client -tls1 -connect 127.0.0.1:1241
CONNECTED(00000003)
depth=1 /C=US/ST=CA/L=LaJolla/O=UCSD/OU=Certification Authority
for ...snip...
SSL handshake has read 2170 bytes and written 316 bytes
- ---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
...snip...

Specifically for testing my Nessus changes I setup a socat SSL relay to
the Nessus port to confirm the fingerprint match changes worked.

I too have noticed that when Nmap encounters a Nsock error it aborts
abruptly.  Although sometime undesirable, I haven't looked into the
"problem" enough to decide if there is a more graceful error handling
technique that can be used.

I've been doing a giant (hundreds of millions of hosts) SSL survey of
the Internet for a while now and run into this many times with
Nmap/OpenSSL.  My guess is that there is a way to tell OpenSSL to try
SSL 3/2 and on failure fall back on TLS 1 but I haven't looked into it
because the problem is rare enough that it doesn't matter for my survey
project.

I know several Nmap developers are working on different aspects of
OpenSSL and further integration with Nmap/NSE; one of them may be able
to look into this.

Your recent testing and feedback for service fingerprinting has been
most valuable so please keep up the good work!

Brandon

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkhS/DQACgkQqaGPzAsl94LO/wCfR5ahZ7zc5nBf3IeJUISD/dCa
QxAAn3N2Oqgm+G1sX3Ja4DC+Jz1E0Nfp
=U3rF
-----END PGP SIGNATURE-----

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