Re: LDAP scripts

[David Fifield <david () bamsoftware com>]

On Fri, Feb 19, 2010 at 08:08:00PM +0100, Patrik Karlsson wrote:
> On 16 feb 2010, at 03.08, David Fifield wrote:
> > |   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?
>
> Try this:
> ldapsearch -h <ip> -x -D"cn=root,dc=my-domain,dc=com" -w secret -s base "supportedSASLMechanisms"

That didn't work for me (ldap_bind: Invalid credentials (49)), but it
worked when I replaced "root" with "Manager". The duplicate lines are
there too.

> > 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?
>
> I've capped output to 20 objects, to avoid getting 100's of megs of results.
> Should've thought of this *sigh*

I'm a little torn about this, because someone may want the full results,
and not care if it's 100 MB. NSE is an inefficient way to do that,
because it keeps the whole response in memory, but maybe there's a use
for it.

What you've done with a script argument is fine, and it appears you can
disable the limit by setting it to -1. But I should ask, what's the use
case of this script? How do you see it being used by an LDAP admin,
pen-tester, network troubleshooter, or other person? I think the use
case should drive what the default behavior is.

> > 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:
>
> Ok, the argument name is now qfilter for "Quick filter".
> As it's does not allow the user to input a *real* LDAP filter, the name filter would be misleading.
> In the future these quick filters could be extended to include stuff like:
> - ad-accounts-lockedout
> - ad-accounts-no-kerberos-preauth
> - ad-accounts-need-change-pw

A "real" filter would require client-side parsing and filtering?

> > 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:
>
> The "problem" with LDAP (except AD) is that you need to use the
> distinguished name to authenticate to the server.
> So, in your case, rather than using root you should be using
> cn=root,dc=my-domain,dc=com
> I've made some changes to the script to handle this:
> 1. Either put the distinguished names into the userlist
> 2. Supply the ldap.base parameter to specify the base against which guessing is to be performed
>
> For the second alternative you would put: ldap.base='dc=my-domain,dc=com'
> The problem is obviously if you have users in different places such as:
> cn=bob,ou=Sales,dc=my-domain,dc=com
> cn=fred,ou=IT,dc=my-domain,dc=com
> cn=alice,ou=HR,dc=my-domain,dc=com

Thanks for the good explanation. This works for me now, after I add
Manager:secret to the username/passwords list:

# nmap --script ldap-brute.nse --script-args ldap.base=\"dc=my-domain,dc=com\" -p ldap 192.168.0.190 -d

389/tcp open  ldap    syn-ack
| ldap-brute:
|_  cn=Manager,dc=my-domain,dc=com:secret => Login correct

I want you to go ahead and merge ldap.lua, ldap-rootdse.nse, and
ldap-brute.nse, and let me think some more about ldap-search.nse.

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