一、背景
1.1LDAP和认证过程
LDAP轻型目录访问协议是一个开放的，中立的，工业标准的应用协议，通过IP协议提供访问控制和维护分布式信息的目录信息。有优异的读性能，但写性能差。
LDAP作为开放的Internet标准，支持跨平台，在业界中得到广泛认可和使用，只需要通过简单的配置就可以实现与服务器的认证交互，可以很便捷的实现LDAP统一认证服务，如我们日常使用的sso。
LDAP bind绑定可以理解为一个登陆认证的过程，通常，在根据LDAP进行身份验证时，判断是否登陆成功会采取以下三种方法之一：
- 使用LDAP用户的用户名和密码绑定到LDAP服务器；最常见的简单代码实现方式，第三方应用也常用；
- 在LDAP中检索用户的条目，然后将用户输入的密码和检索到的LDAP记录中的密码属性相比较；LDAP服务器对于password属性可读的情况，较少见；
- “两次绑定”验证方法；支持匿名绑定的LDAP服务器下，进行初次匿名，第二次提交身份信息进行绑定，也比较常见。
1.2 NULL BIND
或者称为Anonymous bind，不同于匿名访问，匿名绑定很多情况下不被认为构成漏洞。匿名绑定指用户无需身份验证，即可直接提交空值，以“NULL BIND”的方式连接到该服务器完成绑定，但不能执行访问/查询。如果存在匿名访问漏洞，则还可以执行查询等操作。
如图为Windows Server 2016的AD，可以对rootDSE匿名绑定，但不能匿名查询支持的DN
图1.匿名绑定成功
图2.匿名访问/查询不成功
图3.通过验证可以查询/访问
在rfc【反和谐】4513的5.1.2和6.3.1小节，有关于该问题的描述
“https://datatracker.ietf.org/doc/rfc【反和谐】4513/?include_text=1”
重要部分翻译如下
5.1.2
LDAP客户机可以使用简单绑定方法，通过未经验证的身份验证机制来建立匿名授权状态，方法是发送带有名称值（LDAP字符串形式为非零长度的RFC【反和谐】44514的可分辨名称）的绑定请求，并指定包含零长度密码值的简单身份验证选项
...
打算执行身份验证的用户可能会无意中提供空密码，从而导致执行不佳的客户端请求未经身份验证的访问。客户端应该禁止向名称/密码验证用户界面输入空密码。此外，默认情况下服务器应失败未经身份验证的绑定请求。
...
6.3.1
...
使用简单Bind操作的结果来做出授权决策的客户端应主动检测未经身份验证的Bind请求（通过验证提供的密码是否为空）并做出适当的反应。
...
1.3 服务器的NULL BIND
微软AD（Windows ActiveDirectories）在默认情况下，不支持针对活动目录Active Directory的任何LDAP匿名操作，但支持对rootDSE的匿名搜索和绑定，且无法禁用。
Windows server 2003之前的版本需要手动调整，以禁用对活动目录Active Directory的LDAP匿名操作，包括绑定、搜索和查询。
微软官方说明：“https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/anonymous-ldap-operations-active-directory-disabled”
Active Directory：存储了有关对象的信息，能让管理员和用户能够轻松地查找和使用这些信息。
rootDSE：是目录信务器目录信息树的根，目的是提供关于directory Server的本身的数据。例如，如果一个客户端知道目录服务器正在监听的主机名和端口，则它应该通过询问rootDSE来了解directory server本身的信息和数据。
通常包含下面的一些信息
厂商/供应商=Vendor
服务器支持的命名上下文=naming contexts
服务器支持的请求控制=request control
支持的SASL机制
支持的功能
Schema位置等等信息
OpenLDAP在simple配置下，现行版本默认情况下支持匿名绑定，可以手动调整禁用。部分早期版本还支持匿名访问。“https://openldap.org/doc/admin24/security.html”
二、案例
2.1 漏洞描述
（1）某IT系统，由管理员自己分配有权限的账户，维持一个列表，依据LDAP进行密码校验；
（2）登陆时，验证用户名是否在服务器账户列表内，提交到LDAP验证，判断登陆是否成功；
（3）离职用户（即LDAP中不存在，但是在系统自身用户列表内）可以使用任意密码登陆
2.2 漏洞成因分析
分析代码发现，系统逻辑如下：
- 校验输入用户是否是已分配的合法用户；
- 对于合法用户，在LDAP服务器中查询用户DN信息；
- 提交DN与passwd密码，通过与LDAP绑定是否成功，判定登录状态。
漏洞成因如下，在第2步时，因为离职员工信息在LDAP中已经删除，返回DN为空。而上层域控为windows server DC，允许对rootDSE的NULL绑定，因此提交了空DN与任意密码。php代码认为ldap_bind执行结果为真，判定登陆成功。
等价于如图所示的情况，Base不选择的情况下默认为rootDSE。微软AD的rootDSE允许匿名绑定。
有问题的代码块如下，ldap_bind的结果判定为真
修改后，增加了判断ldap_user_dn是否为空的判定，若LDAP中不存在用户信息，则直接返回错误不进行提交。
三、复现方法
3.1 NESSUS扫描
Nessus可以不稳定的报出这个漏洞，描述如下，定义为中危的信息泄露
描述中明确，“此插件不能证明存在LDAP匿名访问漏洞，且LDAP v3要求支持匿名绑定”
“https://www.tenable.com/plugins/nessus/10723”
3.2手工测试
3.2.1 LdapAdmin
输入host，选择匿名连接
支持的情况
不支持的情况
3.2.2 SofterraLDAP Browser
使用Softerra LDAP Browser 工具验证过程如下
1.选择服务器，并选择Base DN为RootDSE;
2.选择“Anonymous user”匿名用户
3.选择完成，发现可以匿名绑定，并加载根目录信息
如果不支持NULL BIND，则无法加载根目录信息
3.2.3 Python脚本
Python代码，ldapconn.simple_bind_s传空参数，则会判定绑定成功
import ldap
ldapconn = ldap.initialize('ldap://X.X.X.X:389')
ldapconn.simple_bind_s('', '')
print("helllo")
官方python_LDAP库文档的说明如下，在who和cred参数，可以接收空值
“https://pypi.org/project/python-ldap/”
四、LDAP服务端调整（修复方法）
4.1 OPENLDAP
根据官方文档，需要在slapd.conf中指定“ disallow bind_anon ”来禁用匿名绑定机制。
“https://openldap.org/doc/admin24/security.html”
1.vi /etc/openldap/slapd.d/cn\=config.ldif
添加：
olcDisallows: bind_anon
olcRequires: authc
2. vi /etc/openldap/slapd.d/cn\=config/olcDatabase\=\{-1\}frontend.ldif
添加：
olcRequires: authc
3. 重启slapd服务
systemctl restart slapd
4. 验证，不允许匿名绑定
Windows-OpenLDAP直接修改此文件即可
4.2 Windows Server AD（仅针对Active Directory）
Windows Server 2003之后的版本，默认不允许对Active Directory的匿名绑定
但因功能设计，针对rootDSE匿名绑定无法禁用
可以通过以下方式调整对Active Directory匿名访问
1. 服务器运行AdsiEdit.msc，连接到配置
2. 选中LDAP条目，选择【CN=Configuration,CN={GUID}】双击【CN=Services】, 双击【CN=Windows NT】,在【CN=Directory Service)】右键选择属性
3. 将DsHeuristics 属性值设置为0（0000002表示允许）
4. 使用任意LDAP工具尝试连接并Fetch DNs，可以看到对Active Directory的匿名访问失败
五、安全编码实现
使用LDAP的服务器，后端验证逻辑避免此问题比较简单，对提交到LDAP的用户输入值，进行空值校验即可。注意在前后端均做控制，并检查提交参数的逻辑。
此外，使用LDAP认证登陆的应用系统，也需要注意避免LDAP注入类的问题。
如图示例，为vmware harbor开源平台的LDAP验证逻辑
六、ref
http://securitysynapse.blogspot.com/2013/09/dangers-of-ldap-null-base-and-bind.html
https://laoomiaoo.blogspot.com/2017/05/ldap-null-base-search-access.html