Nmap Development mailing list archives

[NSE] sslcert.lua - problems with LDAP Services (FIXED)


From: Tom Sellers <nmap () fadedcode net>
Date: Fri, 26 Aug 2016 05:02:57 -0500

I'm tossing a copy of GitHub Issue #531 at the mailing list in the event that someone runs into these issues with a 
binary version of Nmap and then checks here.


There are two issues with sslcert.lua that prevent it from working with LDAP in certain cases.


STARTTLS vs version detection

When version detection is used against an ldaps port, for example 636/tcp, it would identify the port as ldap over an 
ssl tunnel. sslcert.lua, not knowing about the already discovered tunnel support,
would look up the service name (ldap) to see if it needed to use a STARTTLS helper function, would find it in the list, 
try to negotiate STARTTLS, and then fail. Without version detection enabled it
would label the port as ldapssl, fail to find it in the table, and then successfully negotiate a TLS tunnel.

Since this issue is due to the version detection changing the service name to something that can be found in the 
STARTTLS table and since version detection will know the tunnel type at this point I
have committed a fix for this problem by checking to see if the port.version.service_tunnel is ssl before calling the 
STARTTLS functions.



STARTTLS request

The LDAP STARTTLS related request is not encoded correctly. It was being encoded as a standard ASN.1 octet string ( tag 
0x04 ). This failed to work and was not parsed as valid in Wireshark. The
related code can be found here:  
https://github.com/nmap/nmap/blob/79a2774405ab919557f584f80f3adbb1044ce3b4/nselib/sslcert.lua#L256-L258

Per RFC4511 Section 4.12 the requestName, in this case the OID for STARTTLS, is an octet encoded string with a Context 
specific tag of 0 meaning that it should be encoded with tag 0x80.

0x80  = 10000001  =  10        0                 00000
hex     binary       Context   Primitive value   Value: 0

After this change has been made STARTTLS functions correctly against LDAP services that support it.

I've committed code to address both of the issues above.  The changes have been tested against Windows Active Directory 
(with and without support for STARTTLS) and OpenLDAP (with STARTTLS support)
servers.

The following commands were used and returned the expected results:

nmap -sSC -p389,636,3268,3269  -vvv -d2 --script=+ssl-cert <target>

nmap -sSCV -p389,636,3268,3269  -vvv -d2 --script=+ssl-cert <target>


nmap -sSC -p389,636,3268,3269  -vvv -d2 <target>

nmap -sSCV -p389,636,3268,3269  -vvv -d2 <target>


Tom Sellers


Reference:
  GitHub issue #531 - https://github.com/nmap/nmap/issues/531
  RFC 4511 Section 4.12 - https://tools.ietf.org/html/rfc4511#section-4.12

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/


Current thread: