避免AD攻击 防止密码破解和其它常用目录攻击

[导读]
微软的活动目录AD为大规模的企业系统提供了方便的管理架构，但是，你了解针对AD的攻击吗？你管理的AD安全吗？如何加强AD的安全管理呢？相信本文一定会成为很好的参考。

现在，许多企业在Windows架构中采用活动目录（AD）作为企业目录或者是网络操作系统目录（NOS），AD已经成为企业中一项重要的资产。显然，如此有价值的东西当然要受到重点保护。
对AD的攻击可以来自许多方面——我们来看看五个常用的攻击手段以及如何保护AD以应对攻击。本文提到的前三种攻击可以在AD中提升攻击者的权限，后两种攻击则严重影响了AD架构的可用性。除非特别说明，本文的内容适用于Window Server 2003和Windows 2000 Server中的AD。
在本文中我不能列出全部的AD攻击，我的主要目的是让AD管理员有危机感，能够用多种方法加固AD，保护AD。

攻击一：基于LM Hash破解密码

密码破解实际上是利用操作系统使用的同一个哈希算法对可能的用户密码进行哈希运算，然后把结果和目标操作系统中保存的密码哈希进行对比，从而获得破解的密码。密码破解一般非常耗时，破解者通常要试验大量（有时候是全部）可能的密码。不过，一些免费工具，如John the Ripper和LCP可以进行自动破解，最新版本的John the Ripper和LCP可以分别从http://www.openwall.com/john和http://www.lcpsoft.com/ english/index.htm下载，这些工具对于破解在AD环境中采用普通的NT LAN Manager（NTLM）认证协议的密码十分有效。NTLM是Windows NT 4.0的默认认证协议，但是出于向下兼容的考虑，仍然在Windows 2000和后续操作系统中使用。NTLM包括两种认证协议：LM和NTLM，分别使用不同的哈希算法，这些哈希值分别被称为LM和NT，或者是Unicode、哈希。

由于Windows创建LM哈希的方法存在漏洞，可以显著加速破解过程。一个漏洞是密码不能长于14个字符，并且LM还在哈希运算中将密码字符全部转换为大写，此外，LM哈希实际上并没有使用哈希函数，而是采用对称加密生成了哈希值。
在图1中显示了用户密码“hpinvent1”是如何生成LM哈希值的过程。首先，密码被转换成大写字母“HPINVENT1”；然后，这些大写字母被分割成两段字符串，每段7个字符，“HPINVEN”和“T1*****”，其中第二段要用空字符补齐；接着，这两段字符串作为密钥，通过Digital Encryption Standard（DES）对称加密去加密一个常数，而不是使用哈希函数；最后，把DES加密的结果连接起来就生成了LM哈希值。

攻击一预防措施

要降低LM密码哈希的危害，需要采取以下措施：在AD数据库中取消LM哈希，要求Windows用户采用更为强壮的NTLMv2认证协议，或者要求用户应用特殊的密码创建规则。

在Windows Server 2003、Windows XP和后续的平台中，可以设置组策略（GPO）或者本地策略禁止AD保存LM哈希：
网络安全：在下次改变密码时不保存LAN Manager哈希。

在Windows 2000，该设置并不能从AD或SAM（本地安全数据库）移除LM哈希，只能确保用户下次更改密码的时候不会保存LM哈希。因此，进行该设置以后，需要强制所有受影响的用户更改密码。在Windows Server 2003和Windows XP，上述设置则可以清除安全数据库中的LM哈希历史数据。

对于Windows Server 2003、Windows XP和Windows 2000 SP2或后续平台，还可以编辑注册表，直接禁止保存LM哈希，即把HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\nolmhash（REG_DWORD）的值改为1。
如果是在域环境中，则必须要设置全部的域控制器（DC）。如果用户仍然在使用Windows 98或者Windows 95这些没有安装目录服务客户端的系统，则不可以进行上述设置，因为这些客户端只能使用LM认证。关于nolmhash的使用介绍，请参见微软知识库文章“如何防止Windows在活动目录和本地SAM数据库中保存LAN Manager密码哈希”（http://support.microsoft.com/kb/299656）。

如果是在Windows Server 2003或Windows 2000群集环境中，必须确保群集服务的帐号密码长度至少为15个字符。如果小于此长度，使用群集管理工具会出现问题，微软知识库文章“设置NoLMHash策略后必须设置群集服务帐号密码长度不少于15个字符”（http://support.microsoft.com/kb/828861）对此问题有详细的说明。

为了确保用户都使用强壮的NTLMv2认证协议，必须为运行老版本的Windows平台准备好NTLMv2软件。对于Windows 98和Windows 95用户，可以下载http://down load.microsoft.com/download/0/0/a/00a7161e-8da8-4c44-b74e-469d769ce96e/dsclient9x.msi，安装目录服务客户端。Windows Server 2003、Windows XP、Windows 2000或者Windows NT SP4以上版本都已经内置了NTLMv2支持。

在Windows Server 2003或Windows 2000 AD环境中强制客户端使用NTLMv2，需要设置网络安全：LAN Manager认证级别组策略为“只发送NTLMv2应答，拒绝LM”，或者直接修改注册表键值HKEY_LOCAL_MACHINE\SYSTEM\Current ControlSet\Control\Lsa\lmcompatibilitylevel（REG_DWORD）为4，可以参见微软网站上的文章“LmCompatibilityLevel”（http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/regentry/76052.asp）。

这样，如果用户遵从下述密码规则，Windows将不再会创建LM哈希：
 使用的密码长度超过14个字符；
 在密码中使用特定的ALT字符，可以按住ALT键敲四个数字生成ALT字符，在图2中列出了这些防止LM哈希的ALT字符。

图2：防止LM哈希的ALT字符

攻击二：基于Kerberos预认证数据破解密码

长期以来，我们都认为在Windows Server 2003、Windows XP或Windows 2000中使用默认的Kerberos认证能够保护密码，能有效对付前面所述的那类暴力破解攻击手段，但是在2002年末（发布Windows 2000两年后）Internet上出现了名为KerbCrack的工具。KerbCrack包括两个工具，分别为kerbsniff和kerbcrack，能够暴力破解Kerberos数据包，其中Kerbsniff从网络中捕获Kerberos数据包，kerbcrack则利用kerbsniff的输出进行暴力破解。在http://www.ntsecurity.nu/toolbox/kerbcrack可以下载这两个工具。http://www.hut.fi/~autikkan/kerberos/docs/phase1/pdf/LATEST_password_attack.pdf这篇文章则描述了类似的攻击手段，不过是使用了另外的工具。

Kerberos 5.0引入了Kerberos预认证功能，由客户端使用预认证数据到Kerberos密钥分发中心（Kerberos Key Distribution Center，KDC，即每台Windows Server 2003和Windows 2000域控制器上运行的Kerberos服务）验证密码，然后客户端可以接收到一个Ticket Granting Ticket（TGT）。Kerberos破解攻击的目标就是在其预认证数据中嵌入的加密时间戳，而该时间戳使用用户主密钥加密（例如，基于用户密码的密钥）。

攻击二预防措施

有两种方法可以应对Kerberos预认证攻击：使用Windows智能卡登录，或者在Kerberos客户端和域控制器之间采用IPsec加密网络传输。Windows智能卡登录使用了被称为PKINIT的Kerberos扩展，不使用用户主密钥加密数据包，而使用用户的私有密钥加密。文章“Kerberos初始认证的公共密钥加密”（http://www.ietf.org/proceedings/03mar/ I-D/draft-ietf-cat-kerberos-pk-init-16.txt）详细介绍了PKINIT。目前，暴力破解还无法处理使用公共-私有密钥加密的数据包。

攻击三：利用SIDHistory提升权限

在Windows 2000的AD用户帐号对象中，微软增加了SIDHistory属性。对于域内的帐号移植和森林域内的帐号移动，SIDHistory简化了资源访问过程。例如，当用户帐号从Windows NT 4.0域迁移到Windows 2000域时，Windows 2000域创建新的用户帐号，会自动添加SIDHistory属性，包含了该用户帐号在Windows NT 4.0域中的SID。登录时，Windows 2000域会收集用户的认证数据（组成员等），域控制器从SIDHistory属性中将用户旧的SID添加到认证数据中，这样，在旧的域中的资源不需要被重新分配许可（例如不用更新ACL），用户使用新的帐号即可以继续正常访问。

而对于心怀恶意的AD管理员来说，就可以通过尝试修改用户帐号对象的SIDHistory属性来提升权限。例如，在一个域信任环境中，被信任域的管理员会尝试将信任域的管理员帐号的SID添加到自己域中一个用户帐号的SIDHistory属性里，如果成功的话，被信任域的该用户将获得信任域的管理员访问权限。

在发布的Windows 2000第一版中，信任域的域控制器并不检查来自被信任域的包含有认证数据的资源访问请求，信任域的域控制器会自动认为只包含被信任域的域控制器SID的请求是被授权的资源。

虽然修改AD用户帐号的SIDHistory属性并不容易（只能在AD离线模式时操作），但这是可行的，而且已经出现了这样的修改工具，SHEdit就是一个例证，可以在http://www.tbiro.com/projects/shedit/index.htm下载。

这种攻击在各种Windows域信任环境下都能发生：可以在单一森林的域中间，也可以在存在信任关系的连接外部的域之间或者森林之间。在单一森林中，能够物理接触到域控制器的管理员或用户都可能利用SIDHistory漏洞把自己提升到企业管理员组。

攻击三预防措施

为了避免SIDHistory属性造成危害，必须确保企业管理员组和域管理员组的成员是值得信任的，还需要确保域控制器具有高的物理访问安全级别，防止用户将域控制器离线进行漏洞攻击。

此外，还可以利用不同森林中域之间建立的信任关系的SID过滤功能，防止管理员修改SIDHistory属性。SID过滤可以让管理员隔离域，激活SID过滤时，信任域的域控制器会检查来自被信任域的包含认证数据的资源访问请求是否真实，信任域的域控制器将自动删除不是来自被信任域的SID。因为该操作同时删除了认证数据中由SIDHistory属性增加的SID，所以，SIDHistory和SID过滤是互斥的两个功能。

Windows 2000 SP2及后续版本都提供了SID过滤功能，用命令行命令netdom.exe可以打开或关闭SID过滤。如微软知识库文章“MS02-001：在Windows 2000中伪造SID导致提升权限”（http://support.microsoft.com/kb/289243）所述，在Windows 2000中，可以使用trust和/filtersids开关，而在Windows Server 2003中，则使用trust和/quarantine开关。对于Windows Server 2003外部和森林信任关系，SID过滤是默认被打开的。

在同一森林里具有信任关系的域之间，则不应该使用SID过滤，因为这会终止AD的复制和传递信任关系。如果需要隔离一个域，应该把它放到另一个森林中。

攻击四：基于过度创建AD对象的DoS攻击

具有管理员权限的用户过度创建新的对象会引发针对AD的拒绝服务（DoS）攻击。例如，授权用户不断创建AD对象，直到耗尽域控制器的磁盘空间，会导致AD服务器崩溃。另一个例子则是授权用户用一个命令将几千个成员添加到一个组中，同样会导致服务器崩溃。

攻击四预防措施

要预防这种攻击，必须对授予AD对象创建权限的人要特别小心。还可以采用在Windows Server 2003中的AD对象配额这个功能，而Windows 2000里的对象配额功能有限。

AD对象配额会限定AD命名关联（Naming Context，NC）或根据特定安全项建立的目录分区中可以拥有的对象数量。每个AD NC和目录分区都可以独立设置和管理AD对象配额。不过，在Schema NC中不能定义AD对象配额。对于每个AD NC和分区，可以定义默认的配额，如果没有特别定义，则配额没有限制。

对于安全项拥有的AD tombstone对象，也计入AD对象配额。tombstone对象是AD对象被删除时创建的临时对象，用于在AD的域控制器之间保持被删除对象数据的一致性。对于每个NC和分区，可以指定tombstone配额参数，确定tombstone对象在配额中的权重。例如，为NC或分区指定tombstone的配额参数是25，即分区中一个tombstone对象被计算为一个普通AD对象的0.25。默认的每个分区中tombstone配额参数是100，也就是说，一个tombstone对象和一个普通AD对象具有相同的权重。

对于每个安全项，都可以分配配额，包括用户、计算机、组和inetOrg-Person。一个安全项可以有多个配额，例如，用户可以被分配独立的配额，他所属的组又具有一个配额，在这种情况下，配额将采用最大的那个设置。域管理员组和企业管理员组成员没有AD对象配额限制。

AD对象配额保存在AD NC或分区的NTDS Quotas容器中，属于msDS-QuotaControl类的对象。在Accounting的域NC中设置用户Joe的AD对象配额为10，可以使用下列Dsadd命令：

Dsadd quota 
  -part DC=Accounting,DC=COM
  -acct Accounting\Joe
  -qlimit 10
-desc "Quota for Joe" 
设置Accounting域NC的tombstone配额参数为25，可以使用下列Dsmod命令：
Dsmod
  partition DC=Accounting,DC=COM
-qtmbstnwt 25 
将Accounting域NC的默认对象配额设置为0，可以使用下列Dsmod命令：
Dsmod
  partition DC=Accounting,DC=COM
-qdefault 0

只有运行Windows Server 2003的域控制器可以强制配额，只能在发起目录操作时强制配额，而不能用于复制操作中。要想在AD域目录分区有效使用AD对象配额，域中所有的域控制器必须运行Windows Server 2003。而在AD配置分区使用AD对象配额，则森林中的所有域控制器都必须运行Windows Server 2003（例如，所有域和森林必须运行Windows Server 2003功能level 2）。AD对象配额功能本身和任何指定的功能级别并没有关系——在任何Windows Server 2003域控制器上都可以使用。如果定义了配额的Windows Server 2003域中有Windows 2000域控制器，用户可以继续连接这些域控制器，同时受到配额的限制。

与Windows Server 2003 AD的配额系统相比，Windows 2000的配额功能十分有限。在Windows 2000中，管理员可以限制某个用户帐号创建计算机帐号的数量，必须使用AD域对象中的ms-DS-MachineAccountQuota属性，这个限制并不适用于域管理员组和帐号操作员组的成员。Windows Server 2003支持ms-DS-MachineAccountQuota属性（默认值为10）。如果想禁止添加计算机帐号，可以将该属性值设置为0。

对于认证用户组来说，在用户权限中删除“向域中添加工作站”也可以达到同样的目的。在Windows Server 2003和Windows 2000中，认证用户组默认具有该权限。

攻击五：基于MaxTokenSize属性的DoS攻击

微软扩展了基本的Kerberos协议，利用Kerberos认证ticket包含认证数据。Windows Kerberos ticket和Ticket Granting Ticket（TGT）都包含一个特殊的区域，称之为权限属性验证（Privilege Attribute Certificate，PAC），可以利用Kerberos协议传输认证数据，如在Kerberos认证ticket中的用户组成员和用户权限。

Kerberos ticket具有固定的大小，间接限制了PAC的大小。如果用户属于很多的组（比如100个或更多），他的ticket大小可能会超出限制，Windows认证和组策略处理就会失败。因此具有AD创建和修改组权限的用户可以利用这个漏洞针对管理员帐号发起拒绝服务攻击（DoS），这种攻击将导致管理员帐号无法登录网络。

攻击五预防措施

为了预防这种攻击，必须相当仔细地为组管理委派AD管理权限，还必须限制管理管理员帐号组成员的权限。因为在森林中，管理员可以管理本地和全局组，添加任何用户帐号并不需要特殊的权限，所以在AD中限制默认权限很困难。因此，必须将企业管理员组或域管理员组的帐号放置在一个特殊的组织单元（OU）中，不给被委派的管理员读取的权限。
此外，可以设置注册表

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\MaxTokenSize的值增加Kerberos ticket的最大尺寸，可以参考微软知识库文章“解决用户属于多个组出现问题的新方法”（http://support.microsoft.com/kb/327825）。

对于用户使用Kerberos登录域的所有Windows系统，都需要修改MaxTokenSize（REG_DWORD）的值。在Windows 2000中，MaxTokenSize的默认值是8000字节；在Windows 2000 SP2和后续版本以及Windows Server 2003中，MaxTokenSize的默认值为12000字节。

为了减少PAC的大小，微软在Window 2000 SP4中还采用了新的方法在PAC中存储认证数据。新的PAC认证数据存储方法如下：

 如果是本地组或来自其它域，组的全部SID（例如S-1-5-21-1275210071-789336058-1957994488-3140）将保存在PAC中。
 如果用户所属的全局组在用户所属的域的本地，则只存储组的相对识别号（Relative Identifier，RID）。
微软在Windows认证过程中采用特殊的处理过程，在客户端和服务器端将RID重新分解成SID格式。需要注意的是，即使采用新的PAC认证数据存储方法，仍然需要修改MaxTokenSize或减少用户所属组的数量。

为了避免Kerberos tiket的PAC域的空间浪费，从Windows NT 4.0域迁移到Windows Server 2003域或Windows 2000域时，应该删除AD帐号的SIDHistory属性，可以参见微软知识库文章“如何使用Visual Basic脚本清除SidHistory”（http://support.microsoft.com/kb/295758）。

微软发布了Tokensz工具，用于解决Kerberos令牌大小相关的问题，该工具可以从http://www.microsoft.com/downloads/details.aspx?familyid=4a303fa5-cf20-43fb-9483-0f0b0dae265c&displaylang=en下载。下列Tokensz命令列出了当前系统的MaxTokenSize值和当前的令牌大小：

tokensz /compute_tokensize 
/package:negotiate 
/use_delegation 
/target_server:< MachineName > 

关于如何使用Tokensz，可以参见微软的白皮书“解决Kerberos错误”（http://www.microsoft.com/downloads/details.aspx?familyid=7dfeb015-6043-47db-8238-dc7af89c93f1&displaylang=en）。

全方位较量

本文提到的这些攻击手段说明了采用多种措施保护AD架构的重要性。除了技术上的安全措施，还必须考虑物理上和组织上的安全措施。物理上的安全措施包括对Windows域控制器、网络设施和公司建筑物的物理安全访问；组织上的安全措施包括建立安全规则和操作步骤，定期对AD架构进行外部安全审计，不断培训管理员和用户的安全风险知识和操作实践。在公司内，保护AD的安全是一项重要的工作，应该列为高优先级，应该从技术上、物理上和组织上建立联合的团队共同完成