不要指望Kerberos抵御哈希值传递攻击

在上篇“如何防御哈希值传递攻击” 发表后，很多朋友询问Kerberos身份验证是否能够有效抵御哈希值传递攻击。本文我们将讨论Kerberos抵御哈希值传递攻击的问题，Kerberos是用于各种计算机系统的一种开放式身份验证协议，Kerberos在多方参与的服务间传递加密密钥保护的身份验证“票”，密码哈希既不被发送也不被存储，所以无法被获取或者重复利用。

Kerberos是部署在Windows2000中的默认身份验证协议，现在很多操作系统使用Kerberos连接到Windows 2000和更高版本的Kerberos保护的资源和服务。在现在的Windows网络中，Kerberos身份验证广泛使用，它可能能够减少哈希值传递风险，但是并不像很多人想象的那么强大。

首先，哈希值传递攻击只针对互动的登录，在windows系统中，哈希密码既没有被发送也没有被存储在远程服务器或者windows内通过网络连接(除RDP连接外)的主机程序中，无论是使用NTLM/NTLMv2还是Kerberos。攻击者只能捕捉存储在SAM中本地计算机或者Active Directory数据库中的密码哈希，或者用户以交互式方式登录时的密码哈希。攻击者能够获取对服务器电脑的高权限访问并捕捉网络中每个连接用户的密码的说法是不现实的，在大多数情况下，Kerberos并不提供比NTLM/NTLMv2更多的保护。

其次，当用户以交互方式登录到使用Kerberos的计算机，他/她的NT密码哈希被存储在计算机的内存中并且可能被窃取。这是因为所有的windows计算机必须支持至少一种其他身份验证协议，例如LanManager、NTLM或者NTLMv2。在windows server 2008之前，NT哈希是用于被称为“Kerberos前身”的协议中，在W2K8和更高的操作系统中使用的是AES。

值得注意的是，从Windows 7和Windows Server2008 R2开始，除Kerberos外的身份验证协议可以通过Restrict NTLM功能来关闭，不过，这很难部署到最常用的操作系统中。

在大多数网络中，运行的都是较旧的身份验证协议。例如，很多应用程序和服务并不理解Kerberos或者接受它们的验证票。有些应用程序(例如微软的sharepoint)能够理解Kerberos但是默认启用的是NTLM以达到兼容目的。很多代理服务器和负载平衡器不允许Kerberos运行，却随时允许NTLM通过。默认情况下，IP地址提及的网络服务器(而不是DNS或者NetBIOS名)不会使用Kerberos，较旧的或者未配置的Samba安装不会使用underconfigured。

网络没有运行大量的NTLM身份验证是极其罕见的情况。在大多数情况下，NT哈希被存储在初始计算机中，即时只有使用Kerberos时。

同样需要记住的是，获取哈希值首先需要高级别访问。如果攻击者可以访问并查看NT哈希，他/她就能够获取Kerberos TGT(票证授权票)并通过验证。

Kerberos还是具备一定保护能力的，目前似乎还没有工具可以攻击Kerberos，攻击者也很难制作这样的工具，但是攻击者可以轻松地利用内存扫描仪或者拆卸(例如IdaPro)来进行攻击。(注意：NT哈希存储在Kerberos TGT中，并可以从中获取该NT哈希，除了在最新的windows操作系统上外。)

身份验证者捕捉或者重复使用是所有对称型身份验证系统面临的问题，包括大部分Kerberos部署系统。在Unix、Linux和BSD 中，Kerberos能够以非对称形式被使用，但大部分情况却不能这样使用。你同样可以使用其他非对称身份验证程序，如Sesame、智能卡、加密密钥卡和生物识别设备等，但每种方法都有自己的缺点和局限性。例如，很多智能卡使用的是密码哈希，很多生物识别技术要求使用密码来运行。计算机安全比表面看起来更复杂。

有些人还吹捧crypto key fobs的反重放机制，Kerberos确实有反重放功能，但哈希值传递攻击并不属于重放攻击，哈希值传递攻击利用的是最终身份验证要素：密码哈希，并将哈希用于新会话。

Kerberos可能在某些特定情况下能够缓解哈希值传递攻击，但在大多数环境中它并不能明显减少哈希值传递的风险。我们可以列举出很多理由(性能、其他安全保护、相互验证等)来说明应该使用Kerberos验证而不是较旧的验证协议，大家应该注意这一点。