Re: LDAP scripts

[Patrik Karlsson <patrik () cqure net>]

On 16 feb 2010, at 03.08, David Fifield wrote:
> 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?

Try this:
ldapsearch -h <ip> -x -D"cn=root,dc=my-domain,dc=com" -w secret -s base "supportedSASLMechanisms"

> 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*

> 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

> 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

In this case you need to go with alternative 1 *EXCEPT* if your running against Active Directory which is a complete 
different story.
As in AD you can simply omit the whole distinguished name and supply simple user names such as "bob" and "fred" and the 
directory will look them up for you.
I also found that AD will tell you if a user does not exist so that you don't have to spend more time trying to crack 
the password.
I've added all this and some more stuff to the latest version of the brute script.

> # 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/

Attachment: ldap-brute.nse
Description:

Attachment: ldap-rootdse.nse
Description:

Attachment: ldap-search.nse
Description:

//Patrik

--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





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