NTLM 身份验证：它是什么以及为什么存在风险

NTLM 是一项古老的技术，早在 Windows NT 3.1 中就已引入，那么为什么今天值得讨论它呢？简而言之，NTLM 身份验证是一个巨大的安全漏洞，世界各地的组织仍在利用该漏洞，并且您可以在很短的时间内将其最小化甚至消除。

在这篇博客中，我将解释什么是 NTLM 身份验证以及使用它带来的安全问题。然后我将详细介绍如何最大限度地减少甚至消除它在 IT 生态系统中的使用。

什么是 NTLM？

NTLM 是一种身份验证协议 - 一种定义的方法，用于帮助确定尝试访问 IT 系统的用户是否确实是他们声称的身份。它发布于 1993 年，已经是很久以前的事了，尤其是当你考虑到 IT 岁月过得比狗岁月还快。 1998年，微软在Windows NT 4.0 Service Pack 4中发布了改进版本NTLMv2。

我强调这些技术的时代并不是为了给它们蒙上阴影，而是为了提供背景。 NTLM 是较旧的协议 LM 的后继者，LM 曾用于 20 世纪 80 年代末 Microsoft 的 LAN Manager 产品。创建 LM 时，计算机网络要简单得多，主要用于文件和打印共享，也许还有一些客户端-服务器应用程序。没有互联网可言，因此每个组织的网络都是独立的，不与任何其他公司的网络连接。

因此，IT 专业人员需要担心的网络犯罪的主要形式是有人试图通过窃听网络登录流量来窃取用户密码。不需要天才就能发现有一种简单的方法可以消除这种风险：不要通过网络发送用户密码。

但用户如何证明他们就是他们所声称的人呢？如果用户可以通过网络发送其他信息来证明他们知道 IT 系统记录的密码怎么办？

有一个密码哈希。

NTLM 身份验证的工作原理

密码哈希是一件非常酷的事情。它是由哈希算法创建的——一种将密码转换为不同字符串的特殊函数。该函数是可重复的：相同的密码将始终生成相同的哈希值。而且它是单向的：将密码转换为哈希值很容易，但无法将哈希值转换回密码。

要了解密码哈希如何解决当前问题，让我们逐步完成当我尝试登录公司网络时发生的 NTLM 身份验证过程：

1. 我在本地计算机上输入用户名和密码。
2. 我的计算机运行我通过标准哈希算法输入的密码，该算法由客户端计算机（例如我的计算机）和提供身份验证和授权服务的域控制器 (DC) 使用。这给了它我的密码哈希值，它将在步骤 5 中使用。
3. 我的机器向最近的 DC 发送登录请求，其中包括我的用户名。
4. DC 发回一个随机数，称为登录质询。
5. 我的计算机使用密码的哈希值对登录质询进行加密，然后发回结果（响应）。 （现在您知道为什么 NTLM 被称为挑战-响应身份验证协议了。）
6. 为了查看我是否提供了正确的密码，DC 使用其记录的与登录请求中的用户名相关联的密码哈希值对登录质询进行加密 — 该密码是使用与我的客户端计算机相同的哈希算法创建的使用。
7. DC 将其获得的结果与我的计算机发送的响应进行比较。由于 DC 和我的客户端计算机都使用相同的哈希算法和相同的加密过程，如果结果匹配，则证明我输入了正确的密码。在这种情况下，我已通过身份验证。

请注意，在此 NTLM 身份验证过程中，我的密码或其哈希值都没有通过网络发送。为了进一步提高安全性，所有这些通信都使用共享密钥进行加密，这是我计算机的域密码。

那么，NTLM 身份验证有什么问题呢？

虽然确实没有通过网络发送密码供窥探者获取，但按照当今的标准，NTLMv1 是一种非常弱的身份验证协议。虽然 v2 比 v1 安全得多，但它仍然不如 Kerberos 等最新协议安全。

您还记得商家拿走您的实体信用卡，将其放在特殊设备上，在上面放一张特殊的销售单，然后滑动手柄以在您的卡上留下印记吗？你会得到一份，他们会把另一份塞进他们的收银台。这意味着您访问过的每个商家都会存储您的信用卡号，从而为窃贼提供了大量的机会来窃取它。

NTLM 身份验证就是这样。从上面的过程中可以看出，密码哈希是身份验证的关键要素——如果攻击者能够获取我的用户名和密码哈希，他们就可以从上述过程的第 3 步开始；这种黑客技术称为传递哈希，可以追溯到 1997 年。由于用户名以纯文本形式发送，因此很容易被攻击者获取。不幸的是，密码哈希值也不难获取——它们分散在多个地方。在客户端计算机上，密码哈希值存储在 SYSTEM 和 SAM 文件中，任何具有管理员级别权限的人都可以读取这些文件，并且也容易受到多种黑客攻击。默认情况下，哈希值也会缓存在内存中，攻击者可以使用 Mimikatz 等现成的工具提取哈希值。

在服务器端，密码哈希值存储在每个域控制器上的 NTDS.dit 文件中。在那里，哈希值很容易受到 DCSync 攻击，这种攻击会诱骗 DC 将其哈希值存储与伪装成另一个 DC 的恶意软件同步。获取哈希值的其他方法包括 Responder（一种模拟服务器的工具）以及利用链路本地多播名称解析 (LLMNR) 协议的攻击。

另外，哈希值不仅仅在我上面示例中使用的登录过程中传递。毕竟，我登录公司网络的原因是因为我需要使用那里的一些资源，例如某个数据、特定应用程序或大厅里的打印机。但并非每个用户都有权访问每个资源，因此每当收到请求时，资源都会想知道“谁在请求？ ” 因此，我的客户需要一次又一次地通过网络传递我的凭据。在用户会话期间，密码哈希值也会保留在远程桌面协议 (RDP) 服务器软件的内存中，这意味着如果用户断开连接而不是注销，其密码哈希值仍保留在内存中。

这就是全部？

不是由一个长镜头。 NTLM 身份验证也非常容易受到暴力攻击，因为该协议使用的哈希算法是众所周知的，并且密码没有加盐。 加盐在对密码进行哈希处理之前向密码添加随机字符串，因此即使您和我碰巧选择相同的密码，我们也会有不同的密码哈希值。由于 NTLM 不允许加盐，因此每个选择相同密码的用户都将拥有相同的密码哈希值 - 无论他们访问哪个网络。因此，攻击者可以获取常用密码列表，通过已知的哈希算法运行它们，并获得可能与网络中至少某些用户相关的密码哈希彩虹表 。他们所需要做的就是尝试它们，直到找到正确的为止。 （您没有使用任何默认密码，对吗？特别是对于强大的管理员帐户？您可以确定攻击者将它们包含在他们的表中。）

另外，NTLM 身份验证协议不支持多重身份验证 (MFA)，因此设法获取密码哈希的黑客永远不必担心会受到第二条信息的质疑，例如通过电子邮件或短信发送给用户的代码，以便进行身份验证。

NTLM 身份验证还会受到NTLM 中继攻击。基本上，由于用户的客户端无法验证发送登录质询的服务器的身份，因此攻击者可以位于客户端和服务器之间并中继经过验证的身份验证请求以访问网络服务。尽管这是渗透测试中广泛使用的一种古老技术，但过去几年发现了一些漏洞，使黑客能够绕过一些安全措施，使得这种形式的攻击再次流行。

NTLM 是一个弱协议还有一些更多的技术原因。版本 1 使用 16 字节随机数进行登录质询，这不太安全。在 v2 中，这是一个可变长度的挑战，这要好得多，并且加密步骤添加了时间戳。然而，两个版本的 NTLM 身份验证协议都依赖于过时的 MD4 加密哈希函数；不支持 AES 或 SHA-256 等现代加密方法。 MD4 的缺陷早在 1991 年就已发布，甚至在 NTLMv1 推出之前；今天，它被认为受到了严重损害。此外，在创建哈希之前，密码字符串中的所有小写字母都会转换为大写，从而限制了可能的结果集。结果，到 2012 年，每个可能的 8 字符密码都可以在 6 小时内破解； 2019 年，该时间缩短至 2.5 小时以下。

哇，那么为什么还有人使用 NTLM 身份验证呢？

从技术上讲，他们不必这样做。早在 Windows 2000 中，Microsoft 就用 Kerberos 取代了 NTLM 作为默认身份验证协议。Kerberos 是一种更强大的协议，它依赖于票证授予服务或密钥分发中心，并使用加密而不是散列。 （我在这里详细解释了 Kerberos 身份验证。）

然而，Windows 中仍然支持 NTLM 身份验证，原因很充分：保持与旧系统的兼容性并在独立系统上启用登录身份验证。而且仍然有大量旧应用程序使用 v2，甚至是较弱的 v1。

如果组织依赖这些应用程序来实现重要的业务流程，他们自然不愿意冒险通过禁用他们所依赖的身份验证协议来破坏它们。毕竟，对于管理团队来说，业务风险似乎比我上面详细介绍的安全风险更加紧迫和清晰。 IT 团队可能也不愿意。毕竟，涉及的许多应用程序都是在 20 世纪 90 年代和 2000 年代初开发和实施的，因此今天负责企业网络的 IT 专业人员可能与部署它们无关。因此，他们可能对关闭 NTLM 所涉及的风险没有信心。

有没有办法安全地减少、禁用或消除 NTLM 身份验证？

是的！最好的策略是采取分阶段的方法。首先简单地进行审核：哪些应用程序正在使用该协议的两个版本中的每一个？您可以使用组策略设置网络安全：限制 NTLM：审核此域中的 NTLM 身份验证来启用此审核。第三方 Active Directory 安全解决方案（例如 Change Auditor）将提供更详细的信息，例如正在使用的协议版本。

有了这些信息，检查您是否可以将应用程序配置为使用更强大的协议（NTLMv2，或者最好是 Kerberos），或者是否有更新版本的应用程序或具有类似功能的不同应用程序可供您使用。

理想情况下，您希望消除使用两个版本的 NTLM，转而使用 Kerberos。要禁用 NTLM，请使用组策略设置网络安全：限制 NTLM。如有必要，您可以创建例外列表以允许特定服务器使用 NTLM 身份验证。您至少需要禁用 NTLMv1，因为它是您环境中的一个明显的安全漏洞。为此，请使用组策略设置网络安全：LAN Manager 身份验证级别。

NTLM 身份验证协议（尤其是 v1）对任何启用该协议的 IT 环境构成严重的安全威胁。我不建议盲目禁用它，因为这很容易破坏重要的业务流程。但值得努力确定它的确切使用位置，并系统地重新配置或替换应用程序，以便您可以最大限度地减少甚至消除 IT 生态系统中 NTLM 身份验证的使用。