-1

I'm a security research studying CLDAP as a vector for UDP reflection attacks, a from of Denial of Service. I'm not a MS Server expert, so I want to sure up my understanding of the context of the CLDAP service.

The CLDAP service is a UDP version of the LDAP service exposed on MS Servers' that implement Active Directory. From the MS literature, there is only one command implemented over CLDAP (the UDP version of LDAP), and that is the LDAP Ping. This command then is leveraged as a reflective vector by malicious actors conducting denial of service attacks.

The intended purpose of the LDAP Ping is the discovery of information about collaborating Domain Controllers. The docs say the purpose is "to verify the aliveness of the domain controller and also check whether the domain controller matches a specific set of requirements." This scope of usage on this sounds to be intended only as a MS Server inter-server cooperative thing.

The "open CLDAP reflectors" that I track all have this service exposed directly to the open internet. I assume much of this is due to accident, gross naivete, or some other non-standard usage.

But maybe I'm wrong. Is there any standard, valid practice of MS Server deployment and configuration that would have these Domain Controllers trying to discover each other over the open internet? Or can I say that they are all, more or less, accidentally exposed?

0

2 Answers 2

0

Most likely, they are accidentally exposed. (Allowing public access to AD domain controllers is never good practice. Though it's slightly beyond my understanding as to why that applies even to things like the seemingly-secure Kerberos service… but then I come from an academic IT environment, not corporate.)

But note that CLDAP ping is not used between DCs. Rather, it is used by the "DC Locator" service from Windows client machines which are trying to select the most suitable DC for authentication.

(DCs don't need to "locate" another DC because they simply authenticate to themselves – and for replication between DCs they already know each other's capabilities from the AD directory so they go straight to TCP-based communications.)

So it is also possible that the DCs were exposed "intentionally", e.g. to allow roaming laptops to authenticate in case their cached credentials expire, and/or to get Kerberos tickets for accessing further AD-based services from those machines. (Even non-AD-member machines support using Kerberos for accessing AD services, but even in that situation Windows insists on making the DC Locator CLDAP-ping.)

(Preemptive note: Saying that something "is done intentionally" doesn't imply saying that it is done wisely.)

It is also possible that the owner runs an AD implementation they assume would be more robust against generic exploits than MS AD, e.g. they might be running Samba AD and assume that it's more safe to expose it, but they still don't realize it still lacks any sort of CLDAP rate-limiting.

And it's certainly also possible that the owner of said DCs just doesn't know what a firewall is, except for it being something they "need to" disable. Just consider how many printers, VNC servers, etc. are exposed to the Internet – it's valid to assume that the same applies even to AD DCs.

1
  • Thanks for clarification of the usage. And I certainly understand the intentional versus wisely bit. On the wise path, one would expect those clients to be connecting over a VPN, correct?
    – chad
    Aug 16, 2022 at 16:43
0

Domain controllers do not perform discovery of or perform an LDAP ping of other domain controllers.

Domain clients perform an LDAP "ping" for the IP addresses of domain controller records that are registered for the domain. If that is a public IP address, then yes the connectivity test may traverse the Internet if the client is remote.

More information:

https://social.technet.microsoft.com/wiki/contents/articles/24457.how-domain-controllers-are-located-in-windows.aspx

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .