Windows RPC 高危漏洞复现与分析

据媒体分析微软上周修复了一个名为Windows RPC CVE-2022-26809漏洞，并将其评为「严重」的级别，无需身份认证和用户交互，对仅通过向受影响的目标服务器发送特制的RPC请求，即可触发并达到远程代码执行的目的。

2022年4月份修复的高危漏洞CVE-2022-26809距今已经过去一月有余，期间除了L1nk师傅发了一篇关于GetCoalescedBuffer()漏洞函数触发条件的分析，再无其他消息。我这边虽然分析出了ProcessReceivedPDU()漏洞函数的触发逻辑，但苦于无法在默认系统上触发，也没什么进展。

直到5月18日，corelight上发了一篇关于CVE-2022-26809的漏洞利用检测文章，同时给出了相关的github仓库，仓库中附带了捕捉的漏洞触发数据包。

文章中提到CVE-2022-26809位于OSF_CASSOCIATION::ProcessBindAckOrNak()函数中，这是一个客户端解析bind_ack响应的函数。我和L1nk师傅一开始都忽视了这个函数，因为我们觉得客户端的漏洞和”有希望成为蠕虫漏洞“的描述不符，不太可能是CVE-2022-26809。但实际上当我们调用目标主机的EfsRpcDecryptFileSrv()efs rpc函数时，该函数会根据我们传入的unc路径，向我们的恶意smb服务器的srvsvc端点发起bind请求。这样服务端也就变成了客户端，就会调用ProcessBindAckOrNak()处理我们的恶意smb服务器返回的bind_ack数据包。现在看还是对smb之类的知识了解的太少。

数据包有两个特点，frag_len为0x1a，ScnDry_Addr_len为0，且数据包在这个字段截断，后面就没了。

BufferLength即是数据包的长度为0x1a，第一次BufferLength-0x1A，结果为0，然后由于sec_addr_length为0，所以会进入else分支，0-0x1c整数下溢。

后面取sec_addr_length地址+2+2，由于数据包到sec_addr_length结束，所以这个地址实际已经越界。

另外有一点我们需要注意：我们前面触发漏洞的payload使用的是大端字节序，但实际上使用小端字节序也能正常触发漏洞，所以和Data Representation字段是否为0应该没有关系。