Re: LDAP scripts

[David Fifield <david () bamsoftware com>]

On Tue, Jan 26, 2010 at 10:22:33PM +0100, Patrik Karlsson wrote:
> On 25 jan 2010, at 19.49, David Fifield wrote:
> > What is ldap-get-baseobject telling me? The example in your
> > documentation is a lot longer. I want you to add to the documentation a
> > short description of what the baseobject is and what information it
> > might contain.
>
> I renamed ldap-get-baseobject to ldap-rootdse. The baseobject or more
> correctly the LDAP root DSA-specific Entry (DSE) is the root object.
> It contains information regarding the LDAP service and configuration.
> Section 3.4 of RFC 2251 [1] describes what information MUST be
> provided here by the LDAP server. 
>
> I'm using this object to retrieve the namingContexts or the
> defaultNamingContexts and use it as base for the search (if not
> explicitly set to something else) in the ldap-search script. So
> basically I'm querying this object for the namingContext attribute,
> set it as base, do a new query for all objects. I've added some brief
> documentation and reference to the RFC in the ldap-rootdse script.
>
> While documenting and experimenting some more I noticed that I was
> querying the root DSE without setting any attributes. While Windows
> responds well to this and simply returns each and every attribute for
> the object OpenLDAP doesn't. So I've modified the code to first do an
> empty query, check if it received the namingContext, if not it, do a
> new query for a whole bunch of attributes.
>
> > The script arg names in ldap-search are too specific. (Think of how
> > "username", "password", "filter", and "base" could have meaning for
> > other scripts.) Change them to something like ldap.username and
> > ldap.password.
>
> Sorry about that, they're now ldap.username, ldap.password,
> ldap.filter and ldap.base.
>
> > We already have a function that tries to automatically handle SSL and
> > non-SSL connections, comm.tryssl.
> >
> > http://nmap.org/nsedoc/lib/comm.html#tryssl
> >
> > If you can find a way to use that, it's preferable to doing your own
> > connection handling in every script. comm.tryssl will user port number
> > heuristics and version detection results to try and guess the correct
> > connection method.
>
> I changed the code to use tryssl instead of my dodgy hack. I'm sending
> a null/anonymous bind to the server as initial data. After verifying
> the status I close the socket and create a new one using the options
> received from tryssl. While closing and re-opening the socket may be
> overkill it ensures that the null bind does not mess up anything in
> the subsequent communication.
>
> In addition to the above I changed the ldap-brute unpwdb code to match
> the changes I made to mysql-brute recently. I also removed a bunch of
> debug messages from the library and scripts.
>
> I'm attaching the most recent library and scripts

ldap-search and ldap-rootdse are working well for me now. I added some
default direcotry entries according to the Quick-Start Guide at
http://www.openldap.org/doc/admin24/quickstart.html, and now get

389/tcp open  ldap    syn-ack
| ldap-rootdse:
|   <ROOT>
|       namingContexts: dc=my-domain,dc=com
|       supportedControl: 1.3.6.1.4.1.4203.1.9.1.1
|       supportedControl: 2.16.840.1.113730.3.4.18
|       supportedControl: 2.16.840.1.113730.3.4.2
|       supportedControl: 1.3.6.1.4.1.4203.1.10.1
|       supportedControl: 1.2.840.113556.1.4.319
|       supportedControl: 1.2.826.0.1.334810.2.3
|       supportedControl: 1.2.826.0.1.3344810.2.3
|       supportedControl: 1.3.6.1.1.13.2
|       supportedControl: 1.3.6.1.1.13.1
|       supportedControl: 1.3.6.1.1.12
|       supportedExtension: 1.3.6.1.4.1.4203.1.11.1
|       supportedExtension: 1.3.6.1.4.1.4203.1.11.3
|       supportedLDAPVersion: 3
|       supportedSASLMechanisms: SRP
|       supportedSASLMechanisms: SRP
|       supportedSASLMechanisms: SRP
|       supportedSASLMechanisms: OTP
|       supportedSASLMechanisms: OTP
|       supportedSASLMechanisms: OTP
|       supportedSASLMechanisms: NTLM
|       supportedSASLMechanisms: NTLM
|       supportedSASLMechanisms: NTLM
|       supportedSASLMechanisms: GSSAPI
|       supportedSASLMechanisms: GSSAPI
|       supportedSASLMechanisms: GSSAPI
|       supportedSASLMechanisms: DIGEST-MD5
|       supportedSASLMechanisms: DIGEST-MD5
|       supportedSASLMechanisms: DIGEST-MD5
|       supportedSASLMechanisms: CRAM-MD5
|       supportedSASLMechanisms: CRAM-MD5
|       supportedSASLMechanisms: CRAM-MD5
|_      subschemaSubentry: cn=Subschema
| ldap-search:
|   dc=my-domain,dc=com
|     dn: dc=my-domain,dc=com
|         objectClass: dcObject
|         objectClass: organization
|         o: Example company
|         dc: my-domain
|     dn: cn=Manager,dc=my-domain,dc=com
|         objectClass: organizationalRole
|_        cn: Manager

ldap-rootdse has some duplicated supportedSASLMechanisms lines; do you
know what that's about? Is there an ldap command I can run locally to
verify the results?

About ldap-search, how big can its output be? Are directories typically
very large, or is it reasonable to print all the search matches by
default?

There's a bug in the documentation (or the code). The documentation
refers to the script argument ldap.filter but the code uses
ldap.objtype. With both ldap.objtype=computer and ldap.objtype=users I
get the shorter output:

PORT    STATE SERVICE REASON
389/tcp open  ldap    syn-ack
| ldap-search:
|_  dc=my-domain,dc=com

I don't know if I'm doing something wrong, but ldap-brute isn't working
for me. The default password for OpenLDAP is "secret", which isn't in
passwords.lst. But even if I add it in, the script tries all the
username/password combinations and doesn't produce any output. I have
this configured:

# Cleartext passwords, especially for the rootdn, should
# be avoid.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw          secret

Here's the output:

NSE: Trying root/ ...
NSE: Trying root/secret ...
NSE: Trying root/password1 ...
NSE: Trying root/abc123 ...
...
NSE: Trying admin/secret ...
...
NSE: Trying administrator/secret ...
...
NSE: Trying webadmin/secret ...
...

Is it a problem with the user name, do you think? I don't know what the
user name is supposed to be. When I run ldapadd (as root), it asks me
only for a password, and "secret" works.

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