使用 PtH 攻击 NTLM 认证的 Web 应用

阅读量306712

|评论3

|

发布时间 : 2018-07-28 14:00:48

x
译文声明

本文是翻译文章,文章来源:labs.mwrinfosecurity.com

原文地址: https://labs.mwrinfosecurity.com/blog/pth-attacks-against-ntlm-authenticated-web-applications/

译文仅供参考,具体内容表达以及含义原文为准。

本文详细介绍了在Windows/Active Directory环境中使用PtH攻击NTLM认证的web应用的详细步骤。该技术细节来源于Alva ‘Skip’ Duckwall Chris Campbell2012blackhat中名为“Still Passing the Hash 15 Years Later…”的演讲主题。

 

简介

Windows Active Directory环境的主要优点是它使用Kerberos 或者 NTLM认证来实现企业级单点登录(SSO)。这些方法通常用于各种企业资源的访问控制,从文件共享到Web应用程序,例如SharePointOWA或用于特定业务的内部Web应用程序。在Web应用程序的方面,IWAIntegrated Windows Authentication)允许用户通过Kerberos 或者 NTLM认证对Web应用程序进行自动身份验证,比如用于Web应用程序的Windows SSO。众所周知,NTLM身份验证协议的设计可能存在PtH攻击,用户使用哈希密码而不需原始密码就能进行身份验证。自1997年开始,这种攻击的公共工具已经存在,当时Paul Ashton发布了一个改进的SMB客户端,该客户端使用LanMan哈希来访问网络共享。

 

背景

多年来,PtH针对Windows环境的攻击已经得到了充分的证明。下面是选取的一些有价值的参考文献:

1.     Microsoft的官方文档详细说明了在尝试NTLM身份验证之前,“客户端计算出一个哈希密码,丢弃掉实际密码”的过程。在Windows环境中可能更有助于理解NTLM身份验证为什么存在PtH攻击: https://docs.microsoft.com/en-us/windows/desktop/secauthn/microsoft-ntlm

2.     Hernan Ochoa’s的幻灯片讨论了PtH最初的工具包:https://www.coresecurity.com/system/files/publications/2016/05/Ochoa_2008-Pass-The-Hash.pdf 。文章讲述了一种从2000年开发的针对Windows机器的PtH攻击方法。

3.     所有关于PtH的文章中,最感兴趣的是pth-suite Linux工具(这工具最初的发布是为Backtrack Linux编写的。所有的工具在Kali Linux中都有了新的位置,有一个需注意的例外,对写这篇博客非常有用,后面会详细说明): https://passing-the-hash.blogspot.com/

4.     “Pass-the-Hash Is Dead: Long Live LocalAccountTokenFilterPolicy”讨论的是本地用户账户的PtH,以及自Windows Vista的对PtH增加的额外限制:https://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/

5.     使用Metasploit中的PsExec模块利用PtH https://www.offensive-security.com/metasploit-unleashed/psexec-pass-hash/

6.     MimikatzPtH模块的GitHub文档:https://github.com/gentilkiwi/mimikatz/wiki/module-~-sekurlsa#pth

我一直对这种攻击技术感兴趣主要是因为可以使用PtH攻击NTLM认证的Web应用。由于Windows Active Directory环境无处不在,大量的企业内部Web应用都用此验证方案进行登陆,允许从公司工作站无缝SSOSingle Sign-On)到公司资源。因此,如果能够在Windows环境中对这些网站完成PtH攻击,就可以在后续对其进行更加深入有效的利用。当一个域名全部使用这种方案时,攻击的影响就非常明显了,比如一个给定域名在完整域名hashdump之后,会包含所有员工用户账户相关的NT哈希。在这种情况下,PtH不需要破解任何哈希密码就可以模拟任意公司员工登陆。这意味着即使对于那些具有安全意识的用户,他们可能使用了20多个字符长度的密码,也无法避免攻击者在企业的Web应用程序上模拟登陆。

 

使用PtH攻击NTLM认证的Web应用

那么实际中如何对NTLM认证的网站进行攻击?很长一段时间以来,我用谷歌搜索这个主题的结果,并没有找到对这种攻击方法详细的介绍(大约在2015-2018年)。在研究Kali LinuxPtH工具集(pth-suite)时,有个很奇怪的问题。大部分原来的pth-suite工具在2015年整合到了Kali Linux中,我之前提到的有一个不同,就是pth-firefox,顾名思义就是用于修改FirefoxNTLM认证代码以便能够允许Pth的工具。由于这些Linux工具对我没什么用,我就把注意力转移到了研究在Windows主机上使用Mimikatz进行同样的攻击的技术上。

在我自己发现一个可用的技术之后,我最近又偶然发现了由Alva ‘Skip’ Duckwall Chris CampbellBlackhat 2012发表的“Still Passing the Hash 15 Years Later…”幻灯片的第30页。它详细介绍了一种方法,在使用Hernan OchoaWindows凭据编辑器(WCE)直接注入详细NT哈希到内存后,使IE(或者其他使用Windows内置“Internet Options”的浏览器)能够通过IWA进行认证。他们在演讲中的第18分29秒给出了这种技术的演示。我花了很多时间才找到这些信息,并为实际利用的相关步骤写了文档,这篇博客的后续内容将介绍在Windows10主机中如何使用Mimikatz进行攻击。

 

攻击

配置环境

为了演示使用NTLM身份验证的Web应用程序,我是用了Exchange 2013服务器,配置为专门使用IWA进行OWA。在Exchange服务器上运行PowerShell配置命令如下:

Set-OwaVirtualDirectory -Identity “owa (Default Web Site)” -FormsAuthentication $false -WindowsAuthentication $true

Set-EcpVirtualDirectory -Identity “ecp (Default Web Site)” -FormsAuthentication $false -WindowsAuthentication $true

其它预先准备的条件:

l  Exchange服务器已加入test.com域。在此域上,使用复杂的密码和相应的邮箱创建名为TESTpath的用户。计算此用户密码的NT哈希值,以便稍后攻击使用。NT哈希生成如下:

python -c 'import hashlib,binascii; print binascii.hexlify(hashlib.new("md4", "Strong,hardtocrackpassword1".encode("utf-16le")).digest())'

57f5f9f45e6783753407ae3a8b13b032

l  在此之后,在未入域的Windows 10主机上下载最新版本的Mimikatz,该主机与Exchange服务器连接的网络相同。我们为了能够使用Exchange服务器的域名而不是IP地址,将此独立计算机上的DNS服务器设置为test.com的域名控制器。

攻击

假设我们的OWA Web应用程序可以在https://exchange.test.com/owa上访问,通常浏览到OWA会有以下提示:

NTLM Prompt when no Credentials are Injected into Memory

因为计算机在内存中没有任何域凭据,从网站收到的WWW-Authenticate头指定它可以接受NTLM身份验证。

以管理员身份运行Mimikatz,我们可以在TESTpth用户的上下文中启动命令提示符,方法是使用Mimikatz中的Pass-the-Hash模块-sekurlsa::pth-并提供用户的NT哈希作为参数:

privilege::debug

sekurlsa::pth /user:pth /ntlm:57f5f9f45e6783753407ae3a8b13b032 /domain:TEST /run:cmd.exe

这样不会改变计算机的本地权限,但是如果我们尝试从新生成的命令提示符访问任何网络资源,它将在我们注入的证书的上下文中完成。

 为了确保我们的浏览器在这些注入的凭据下运行,我们在命令提示符中通过运行“C:Program Filesinternet exploreriexplore.exe”这个命令生成IE进程

 检查“Internet选项”对话框中“本地Intranet”区域的“安全设置”,我们可以看到默认情况下,只对Intranet区域中的网站自动进行身份验证(使用SSO)。如下图所示:

Intranet Zone Options

因此,为了在Windows上使用PtH攻击Internet Explorer,必须将目标站点添加到“本地Intranet区域”。可以使用一个单独的通配符域来代替单独添加网站到这个域,在这种情况下,“*.test.com”将匹配“Test.com”的所有子域。配置如下面的截图:Sites in Intranet Zone

配置完成后,当浏览到https://exchange.test.com/owaTESTpth用户将通过NTLM认证自动进行身份验证,然后OWA加载成功。

Authenticated to OWA

 

潜在的影响

在域名泄露之后,对任何支持IWA的公司,PtH攻击Web应用程序将变得非常高效,可以模拟任何员工获取权限。虽然这可能主要包括的是微软Web服务,比如SharePointOWA(如果IWA是专门启用的),但是各种定制的内部财务程序,包括那些用来外部支付的应用程序,也是一样的。现在行业开始转向云服务环境,通常涉及ADFS联合身份验证,一般默认情况下,ADFS在提供Internet explorer用户代理时支持IWA。在这种情况下,意味着可以通过PtH访问公司的云端资源。

 

建议

虽然这篇文章的主要目的不是讨论保护Windows Active Directory环境的问题,但我们不能只在一个点上说问题,应该给感兴趣的人提供一些解决这些攻击的更深层次的思考。更多的细节没有在这篇文章讨论,可以在以前的文章中找到:Planting the Red Forest: Improving AD on the Road to ESAE.

Windows环境中的Pth问题无法自己本身解决。Active Directory用于SSO的两种协议都能发生Pth类型的攻击。最好的建议就是首先要防止密码哈希和Kerberos密钥的泄露。最重要的是域名控制器,域管理员控制,或其他在Active Directory作用包含保存凭据信息的部分不被泄露,这些都将直接导致所有存储的密码哈希和Kerberos密钥的泄露。在Windows10Server 2016中,可使用Credential Guard来保护内存中保存的凭据信息不受到窃取攻击。

在单独查看Web应用程序的IWA时,确保在登陆过程中使用多重身份验证(MFA)会有很好效果。有一个特例,在ADFSOffice 365一起使用时,通过IWA进行初始身份验证,为了完整整个验证还需要请求第二个因素,之后才能授权访问公司资源。但不幸这种方法不能通用的解决Pth问题,因为不是所有协议都支持它,比如SMB不支持MFA,但还提供允许远程代码执行的功能,这就使攻击者可以不受阻碍地使用PtH在企业环境中横冲直撞。

 

最后说明:Kerberos认证的 “PtH”

PtH背后的概念是,一旦凭证存储被泄露,就可以使用被盗存储的凭证材料(绝不应该是明文密码),模拟用户进行身份验证,而无需获取该用户的相应明文密码。

在参考Microsoft关于实现Kerberos协议的文档时,描述了如何使用“Kerberos与身份验证”来获取Kerberos票证授权(TGT)。这个过程要求用户给域控制器发送一个“验证信息”,使用从用户登录的密码派生的主密钥加密。然后,该文档解释了当DC收到TGT请求时,“它在其数据库中查找用户,获取关联用户的主密钥,解密预身份验证数据,并评估内部的时间戳。”这意味着秘钥本身用于用户的身份验证而不是作为用户的明文密码。用户的密码派生秘钥存储在AD数据库中,意味着如果此数据库遭到破坏(比如:当攻击者获得与管理员权限时候),则可以恢复存储的秘钥以及用户存储的NT哈希。由于只需要存储的秘钥来创建有效的验证信息,而Kerberos身份验证的作用就是“传递秘钥”。Alva DuckwallBenjamin Delpy将此攻击称为超越哈希,而surklsa::pth Mimikatz模块只支持使用Kerberos密钥来编写Kerberos预认证请求。

当然这意味着Web应用程序或任何其他公司支持直接使用AD进行Kerberos身份验证,则可以使用OTH对其进行攻击。

本文翻译自labs.mwrinfosecurity.com 原文链接。如若转载请注明出处。
分享到:微信
+11赞
收藏
anhkgg
分享到:微信

发表评论

内容需知
  • 投稿须知
  • 转载须知
  • 官网QQ群8:819797106
  • 官网QQ群3:830462644(已满)
  • 官网QQ群2:814450983(已满)
  • 官网QQ群1:702511263(已满)
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 360网络攻防实验室 安全客 All Rights Reserved 京ICP备08010314号-66