多年来，NTLM已被用于中继大量内容，以提升Windows网络中的权限。在本文中，我们建议将对RPC协议的支持从impacket添加到已经非常出色的ntlmrelayx中，并探索它提供的新的渗透测试方法。CVE-2020-1113由于RPC协议没有全局完整性验证要求，中间人攻击者可以通过RPC协议将受害者的NTLM身份验证中继到选择的目标。如果受害者对目标具有管理权限，则攻击者可以在远程目标上执行代码。此攻击在已完全修补的WindowsServer2016域控制器上进行了测试。CompassSecurity于2020年1月发现了此漏洞，并将其披露给Microsoft安全响应中心，并将其标识为CVE-2020-1113。Microsoft在2020年5月星期二的更新中发布了此修复程序，实施了一种解决方法，提高了任务计划程序服务的完整性要求。但是该方案无法解决RPC缺乏全局完整性要求的问题。NTLM中继101下图给出了NTLM中继攻击的简化视图：攻击者充当客户端的服务器，并充当服务器的客户端。他从客户端消息中提取出NTLM认证块，并将其放入服务器修改后的消息中，反之亦然。最后，他可以根据需要使用经过身份验证的会话。要使这种攻击起作用，攻击者必须处于中间位置。这可以通过使用传统的欺骗技术（ARP、DNS、LLMNR和Netbios等）或通过错误或误用的功能（打印机错误、JuicyPotato等）触发与攻击者机器的连接来实现。示例回顾NTLM中继已在多种攻击中使用和重复使用：1.打印机错误：从WindowsServer触发SMB连接的好方法（与无约束委派结合使用时尤其方便）；2.PrivExchange：或如何从拥有Exchange邮箱的任何用户升级到域管理员；3.断开MIC：或者如何完全绕过继电保护。这些攻击中继以下协议：SMB→SMB（打印机错误）；HTTP→LDAP(PrivExchange)；RPC计算机的一些背景知识）来执行流程。2、DCE/RPC是OpenGroup设计的RPC协议标准；3.MSRPC（akaMS-RPCE）是微软的DCE/RPC的修改版；谁会使用RPC？RPC用于远程系统管理，WMI基于DCOM，此DCOM使用RPC作为传输（有时通过SMB）：1.监控和远程管理工具支持WMI（快速搜索将提供例如Solarwinds，NetCrunch，PRTG，LanSweeper、Kaseya等）并且必须配置特权服务帐户。注意：此监控解决方案需要具有管理权限的凭据，一旦获得，此帐户将尝试连接到网络中的所有主机。2.系统管理员还可以使用WMI手动执行远程任务，可能使用特权帐户。默认情况下，RPC在Windows防火墙中使用，因为它用于远程管理。AuthenticationandIntegritySecurityServiceProvider，依赖于RPC的工具使用标准的Windows安全提供者进行身份验证，可能的取值如下：注意默认为WINNT，表示NTLM身份验证通过。AuthenticationLevelAuthenticationLevel设置RPC交换中是否存在身份验证和完整性检查：再次注意默认值为CONNECT，这意味着没有完整性检查。幸运的是，大多数基于RPC的协议都有最低安全要求（详细记录在每个Microsoft协议文档的第2.1节中）：MS-SAMR：服务器SHOULDMS-LSAD：请求者不得使用RPC提供安全支持提供者机制（用于身份验证、授权、保密或防篡改服务）。不幸的是，其他一些要求的限制较少：MS-DCOM：服务器应按照[MS-RPCE]的第2.2.1.1.7节中的规定向一个或多个安全提供程序注册，安全提供程序的选择取决于完成。MS-TSCH：RPC服务器必须需要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-WMI使用MS-DCOM，这是一个很好的攻击向量。但是，由于典型的WMI代码执行需要对多个RPC接口进行身份验证，因此它不是NTLM中继攻击的最佳选择（无重新身份验证方法）。MS-TSCH是一种用于管理计划任务的协议，在atexec.py中使用，这是否意味着我们可以中继NTLM身份验证并使用计划任务执行代码？当然可以。我们修改后的impacket包含以下三个新组件：1.RPCRelayServer响应传入的RPC连接；2、RPCRelayClient向目标发起RPC连接；3.RPCAttack（基于ATExec）在目标上执行代码；PoC或GTFO在我们的设置中，攻击者计算机的IP为172.16.100.21，目标计算机DC是带有最新补丁版本的WindowsServer2016，IP为172.16.100.1。受害者用户WINLAB\scooper-da在DC计算机的本地Administrators组中，并使用IP172.16.100.14从这台计算机打开SMB连接。攻击者启动ntlmrelayx.py攻击者将安装我们自定义版本的impacket并在IP为172.16.100.21的主机上启动该工具，他想在目标172.16.100.1上添加一个本地管理员（名为compass）：连接由受害者触发受害者打开从计算机172.16.100.14到攻击者计算机的SMB连接，它模仿管理员使用上述工具访问共享或执行管理任务：#netview\\172.16.100.21\noshare\该工具将启动连接并中继，并且由于中继用户是目标机器上的本地管理员，他有权添加我们的新管理员：因此，将创建一个新用户并将其添加到本地管理员组。中继攻击的破坏力测试了以下场景：服务器端的SMB签名（在我们的测试中设置为必需，如默认DC安装）阻止从RPC中继到SMB。在客户端，默认情况下不需要SMB签名，这可以成功中继到RPC。一些有趣的用例在对iOS数字取证和事件响应(DFIR)进行例行调查后，研究人员发现早在2018年1月就影响了iOS上默认邮件应用程序的可疑事件。研究人员分析了这些事件并发现了一个影响AppleiPhone和iPad。ZecOps在很长一段时间内在企业用户、VIP和MSSP上检测到此漏洞的多个触发器。漏洞利用范围从向受害者的邮箱发送自定义电子邮件，使其能够触发iOS12上的iOSMobileMail应用程序或iOS13上发送的邮件中的漏洞。很少有可疑事件包括黑客常用的字符串（例如414141…4141），经确认，我们验证了这些字符串是由电子邮件发件人提供的。值得注意的是，虽然有证据证实受害人的iOS设备接收并处理了受害人的邮件，但邮件服务器上本应接收并存储的对应邮件却丢失了。因此，我们推断这些电子邮件可能已被故意删除。我们知道从2018年1月开始的iOS11.2.2上有多个触发事件。目前，攻击者可能正在滥用这些漏洞。欲了解更多信息，请点击此处。在我们对触发这些漏洞的研究中，我们发现了一些疑似受害者之间的相似之处。1、所有测试的iOS版本都存在漏洞，包括iOS13.4.1；2、根据我们的调查结果，这些漏洞在iOS11.2.2或更高版本上被主动触发；3.iOS6及以后版本存在漏洞，iOS6发布于2012年，iOS6之前的版本也可能存在漏洞，但我们没有检查过更早的版本。因为在iOS6发布的时候，iPhone5已经上市了。漏洞详情研究人员发现，MIME库中MFMutableData的实现缺少对系统调用ftruncate()的漏洞检查，从而导致越界写入。我们还找到了一种无需等待系统调用ftruncate失败即可触发OOB-Write的方法。此外，我们还发现了一个可以远程触发的堆溢出。已知这两个漏洞都可以远程触发。OOB写漏洞和堆溢出漏洞都是由同一个漏洞引起的，即没有正确处理系统调用的返回值。远程漏洞可以在处理下载的电子邮件时触发，在这种情况下，电子邮件不会完全下载到设备。受影响的库：/System/Library/PrivateFrameworks/MIME.framework/MIME；易受攻击的函数：-[MFMutableDataappendBytes:length:]。利用该漏洞后的异常行为，除了移动邮件应用程序暂时变慢外，用户无法观察到任何其他异常行为。在iOS12上尝试利用漏洞（成功/失败）后，用户只会注意到邮件应用程序突然崩溃。在iOS13上，除了暂时的减速外，这并不明显。如果随后执行另一次攻击并删除电子邮件，则失败的攻击在iOS13上将不会被注意到。在失败的攻击中，攻击者发送的电子邮件将显示消息：“此消息没有内容。”崩溃取证分析，用户体验到的部分崩溃（多次崩溃的一部分）如下；crash的指令是stnpx8,x9,[x3]，意思是x8和x9的值已经写入x3，由于访问x3中存储的无效地址0x000000013aa1c000而崩溃。要找出导致进程崩溃的原因，我们需要查看MFMutableData的实现。下面的调用树是从崩溃日志中提取的，崩溃仅发生在某些选定的设备上。通过分析MIME库，-[MFMutableDataappendBytes:length:]的伪代码如下：崩溃前执行如下调用栈：如果数据大小达到阈值，使用文件存储实际数据，当数据改变，映射文件的内容和大小也相应改变，系统调用ftruncate()在-[MFMutableData_flushToDisk:capacity:]里面调用来调整映射文件的大小。ftruncate的帮助文档是这样解释的：如上所示，调用失败返回-1，全局变量errno指定漏洞。这意味着在某些情况下，此系统调用将无法截断文件并返回易受攻击的代码。但是，当ftruncate系统调用失败时，_flushToDisk无论如何都会继续，这意味着映射的文件大小不会扩大，执行最终会到达appendBytes()函数中的memmove()，导致mmap文件出现越界（OOB）写。滥用用户账号以最少的权限进行渗透测试，对于安全人员来说是一个巨大的挑战，所以管理员必须一切都使用高权限账号。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.检查你的ActiveDirectoryACLs：应该使用最小权限原则；4.网络分段有助于防止中继攻击。5.立即停止使用NTLM。以下思路可以改进ntlmrelayx对RPC的支持：1.支持session重用：RPC攻击目前只有一次机会，不能像SMB一样通过socks代理保存和重用session。2.开发更多的RPC攻击：使用未经分析的MS-DCOM、MS-WMI或其他协议，有可能使攻击在CVE-2020-1113之外发挥作用。3.支持更多的RPC接口：部分Client会在认证前进行未认证的RPC调用。PoC目前仅支持IID_IObjectExporter接口(99FCFEC4-5260-101B-BBCB-00AA0021347A)。可以为传入的RPC连接找到其他向量：RemoteJuicyPotato：在“打印机错误”线程中找到一个错误会很有趣，该错误会触发通过RPC对给定主机进行远程身份验证的调用。
