几年以来,我们作为渗透测试者大量使用NTLM来实现Windows网络中的特权升级。
在本文中,我们建议将对RPC协议的支持添加到已经很强大的 impacket 库的 ntlmrelayx中,并探索它提供的新的攻击方法。
利用CVE-2020-1113
由于没有针对RPC协议的全局完整性验证要求,中间人攻击者可以将受害人的NTLM身份验证中继到通过RPC协议选择的目标。如果受害者在目标上具有管理特权,则攻击者可以在远程目标上执行代码。这种攻击在一个完全打了补丁的Windows Server 2016域控制器上进行了测试,该漏洞于2020年1月被Compass Security发现,并向Microsoft安全响应中心披露了该漏洞,并将其分配为CVE-2020-1113作为标识符。
https://portal.msrc.microsoft.com/zh-CN/security-guidance/advisory/CVE-2020-1113
Microsoft在2020年5月星期二的更新中发布了此修复程序,所实现的解决方案为任务调度器服务添加了完整性要求,它不能解决RPC缺少全局完整性要求的漏洞。
NTLM中继101
下图给出了NTLM中继攻击的简化视图:
攻击者充当客户端的服务器,并充当服务器的客户端。他从客户端消息中提取NTLM身份验证Blob,并将其放入服务器的修改后的消息中,反之亦然。最后,他可以根据需要使用经过身份验证的会话。
为了使这种攻击奏效,必须处于中间人的位置。攻击者可以使用传统的欺骗技术(ARP,DNS,LLMNR和Netbios等)来实现,也可以通过漏洞或滥用功能(打印机漏洞,Juicy Potato等)触发与攻击者计算机的连接来实现。
NTLM中继已在多种攻击中使用和重用过:
打印机漏洞:一种从Windows Server触发SMB连接的好方法(与无约束的委托结合起来特别方便);
PrivExchange:如何从任何用户的交换邮箱升级到域管理员;
断开MIC:如何绕过完全保护继电器;
这些攻击中继了以下协议:
SMB→SMB(打印机漏洞)
HTTP→LDAP(PrivExchange)
SMB→LDAPS(删除MIC)
RPC的一些背景
定义
1. 远程过程调用(RPC)是指一个程序在不同的地址空间(例如在不同的计算机上)执行一个过程;
2. DCE / RPC是由Open Group设计的RPC协议标准;
3. MSRPC(又名MS-RPCE)是微软DCE/RPC的修改版本。
但是RPC仍在继续被人使用
那就是越来越有趣的地方,RPC用于远程系统管理。WMI基于DCOM,该DCOM使用RPC作为传输方式(有时通过SMB):
1. 监控和远程管理工具支持WMI(快速搜索将提供例如Solarwinds,NetCrunch,PRTG,LanSweeper,Kaseya等),并且必须配置特权服务帐户。
此监控解决方案需要具有管理权限的凭据,编辑者甚至指出:“可以使用域管理员。”这似乎很危险,因为此帐户将尝试连接到网络中的所有主机。
2. 系统管理员还可以使用WMI手动执行远程任务,可能使用特权帐户。
默认情况下,RPC用于Windows防火墙,因为它用于远程管理。
认证和完整性
安全服务提供商
依赖RPC的工具使用标准Windows安全提供程序进行身份验证,可能有以下值:
请注意,默认值为WINNT,这意味着NTLM身份验证听起来不错。
认证等级
身份验证级别设置RPC交换中是否存在身份验证和完整性检查:
再次注意,默认值为CONNECT,这意味着不进行完整性检查。
幸运的是,大多数基于RPC的协议都具有最低的安全要求:
MS-SAMR:服务器SHOULD。
MS-LSAD:请求者不得使用RPC提供的安全支持提供程序机制,用于身份验证、授权、机密性或抗篡改服务。
不幸的是,其他一些具有较少的限制性要求:
MS-DCOM:服务器SHOULD 注册[MS-RPCE] 2.2.1.1.7节中指定的一个或多个安全提供程序,安全服务提供商的选择取决于实现。
MS-TSCH:RPC服务器MUST 要求RPC_C_AUTHN_GSS_NEGOTIATE或RPC_C_AUTHN_WINNT授权。 RPC客户端必须使用[MS-RPCE] 2.2.1.1.8节中指定的RPC_C_AUTHN_LEVEL_PKT_PRIVACY(值= 6)身份验证级别。
发起攻击
MS-DCOM被MS-WMI使用,是一个很好的攻击载体。但是,由于典型的WMI代码执行需要对多个RPC接口进行身份验证,因此,它不是NTLM中继攻击(没有重新身份验证方法)的最佳选择。
MS-TSCH是用于管理计划任务的协议,它在atexecute .py中使用。这是否意味着我们可以中继NTLM身份验证并使用计划的任务执行代码?
impacket修改版本包括以下三个新组件:
· RPCRelayServer响应传入的RPC连接;
· RPCRelayClient启动到目标的RPC连接;
· RPCAttack(基于ATExec)在目标上执行代码。
PoC或GTFO
在我们的设置中,攻击者计算机的IP为172.16.100.21,目标计算机DC是具有最新补丁程序版本的Windows Server 2016,并且IP为172.16.100.1。受害用户WINLAB \ scooper-da在DC计算机的本地Administrators组中,并从IP为172.16.100.14的计算机打开SMB连接。
信息披露开发人员编写了许多应用程序,他们无法抗拒将敏感信息存储在文件系统和/或注册表中的甜美警报。其中包括社会保险号,信用卡号,数据库连接字符串,凭据等。开发人员可以对数据进行加密,以增强安全感,但是可能存在不安全或自定义的加密实现。如果必须存储加密数据,则必须始终将密钥存储在单独的位置,例如安全地存储在数据库中。
集中测试测试文件系统和注册表中的信息泄露非常简单,你只需要查看应用程序使用的文件和注册表项,并确保其中没有任何敏感信息。但是应用程序经常对文件和注册表项进行疯狂的调用。这就是为什么将重点放在最可能写入或读取敏感数据的应用程序区域上的原因。
安装程序如果可以测试安装,请始终以此为契机查找对文件系统或注册表的写入。现在是写入数据的最佳时机,稍后应用程序将读取该数据。该应用程序将连接到数据库吗?也许安装过程将数据库连接字符串写入注册表项。也许默认的管理员凭据存储在文件系统中。
应用程序在实际应用程序中,识别可能创建或修改敏感信息的功能区域。这通常包括初始数据库连接和登录表单。许多应用程序都为“记住我”功能保存了一些信息,因此请确定如何存储和检索这些信息。在应用程序的经过身份验证的部分中,查找专门处理敏感数据的区域。
工具和示例Sysinternals套件包含许多用于测试Windows应用程序的有用工具,我将重点介绍的两个工具是AccessEnum和Process Monitor,它们是由Microsoft Azure的CTO编写的。我将重点介绍的易受攻击的应用程序是BetaFast。配置Process Monitor将尝试向你显示比你想象的更多的信息,因此第一步是设置过滤器。 Process Monitor可以过滤的一项是你正在测试的应用程序的PID,因此请务必在任务管理器中进行检查。敏感数据,例如身份证号码或医疗信息,是否以明文传输?有一次,我以用户名“blogger”向应用程序进行了身份验证。在Wireshark中搜索包列表时,“blogger”的名称出现在登录过程中。这甚至是远程可读的,这意味着数据库连接是未加密的,任何访问此网络的人都可以轻松地读取此信息。幸运的是,密码似乎是加密的,所以黑客将无法访问我的帐户。从客户端发送的任何形式的密码,无论是明文、散列还是加密的,都应该是密码本身。当然,密码是加密的。但是,知道这个值并将其发送给服务器,就可以向应用程序验证该用户的身份。仅模糊参数值和不安全加密整个传输不会提供额外的防御。通过wireshark观察到的另一个值是登录过程的输出参数GUID。在应用程序的经过身份验证的部分中,接受GUID作为参数。
攻击者启动ntlmrelayx.py
攻击者将安装我们的自定义版本的impacket,并在其IP为172.16.100.21的主机上启动该工具。他想在目标172.16.100.1上添加本地管理员(名为compass):
受害者触发连接
受害人从计算机172.16.100.14打开与攻击者计算机的SMB连接,这模仿了管理员使用前面提到的工具之一访问共享或执行管理任务:
该工具将拾取连接并进行中继,由于中继用户是目标计算机上的本地管理员,因此他有权添加我们的新管理员:
结果,将创建一个新用户并将其添加到本地Administrators组。
中继性能
我们测试了以下方案:
服务器端的SMB签名(在我们的测试中设置为必需,如默认的DC安装一样)可防止从RPC中继到SMB。在客户端,默认情况下不需要SMB签名,这可以成功中继到RPC。
一些有趣的用例
滥用用户帐户
最小特权是安全专业人员的一个梦想,但并不容易实现,管理员将高特权帐户用于各种用途。
RPC→RPC:从监控工具获得连接,并在其他主机上获得管理员访问权限。
滥用计算机帐户
有时(通常是在旧的Exchange服务器上),一个计算机帐户是另一台计算机的管理员。
此BloodHound捕获展示了一个非常常见的场景,其中一台设备对其他设备进行管理。
RPC→RPC:你在受害计算机上具有低特权会话,可以使用RottenPotato触发与攻击者计算机的RPC连接并将其中继到目标。
SMB→RPC:受害者计算机已激活后台处理程序服务,你可以使用打印机漏洞触发与攻击者计算机的SMB连接,并将其中继到目标。
编码
我们将于6月中旬将对impacket的修改推送到以下GitHub存储库:
https://github.com/CompassSecurity/impacket
缓解措施
此攻击依赖于几个漏洞,CVE-2020-1113只是其中之一。以下是一些解决潜在漏洞的措施:
1. 修补你的Windows!
2. 通过GPO对整个网络中的客户端和服务器强制执行数据包签名;
3. 检查你的Active Directory ACL:应该使用最小特权原则;
4. 网络分割可以帮助防止中继攻击;
5. 立即停止使用NTLM。
以下思路可以提高ntlmrelayx对RPC的支持:
1. 支持会话重用:RPC攻击目前只是一种攻击,无法像SMB一样通过socks代理保存和重用会话。
2. 开发更多的RPC攻击:使用未经分析的MS-DCOM,MS-WMI或其他协议,有可能使攻击范围脱离对CVE-2020-1113的依赖。
3. 支持更多的RPC接口:某些客户端将在身份验证之前执行未经身份验证的RPC调用,目前PoC只支持IID_IObjectExporter接口(99FCFEC4-5260-101B-BBCB-00AA0021347A)。
可以找到其他向量来获得传入的RPC连接:
远程Juicy Potato(Windows特权模拟工具,已经在攻防安全社区中非常流行):找到类似于“打印机漏洞”的漏洞,这将触发通过RPC远程验证给定主机的调用,这将是很有趣的。
本文翻译自:https://blog.compass-security.com/2020/05/relaying-ntlm-authentication-over-rpc/如若转载,请注明原文地址: