Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[NSE] sslcert.lua - problems with LDAP Services #531

Closed
TomSellers opened this issue Aug 25, 2016 · 0 comments
Closed

[NSE] sslcert.lua - problems with LDAP Services #531

TomSellers opened this issue Aug 25, 2016 · 0 comments

Comments

@TomSellers
Copy link

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 suppor,t 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 label to something in the STARTTLS table and version detection will know the tunnel type at this point I have a commit that fixes 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.

 oid = ldap.encode("1.3.6.1.4.1.1466.20037")
 ldapRequest = ldap.encodeLDAPOp(ExtendedRequest, true, oid)
 ldapRequestId = ldap.encode(1)

Code link

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 will be committing code momentarily that addresses both of the issues above. It has 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant