在此前跟进CVE-2020-0796的过程中，我们发现公开代码的利用稳定性比较差，经常出现蓝屏的情况，通过研究，本文分享了CVE-2020-0796漏洞实现在realworld使用过程中遇到的一些问题以及相应的解决方法。
Takeaways
- 我们分析了exp导致系统蓝屏的原因，并尝试对其进行了改进；
- 相对于重构前exp，重构后的exp执行效率与稳定性都有显著提高；
- 关于漏洞原理阐述，Ricerca Security在2020年4月份发布的一篇blog中已非常清晰，有兴趣的读者可以移步阅读，本文不再赘述。
初步选择和测试公开exp可用性
测试环境：VMWare，Win10专业版1903，2G内存，2处理核心
为了测试和说明方便，我们可以将exp的执行分为3个阶段：
- 漏洞利用到内核shellcode代码开始执行
- 内核shellcode代码执行
- 用户层shellcode执行
根据实际情况，我们测试了chompie1337和ZecOps的漏洞利用代码。根据各自项目的说明文档，两份代码初步情况如下：
- ZecOps
ZecOps的利用代码是在单个处理器的目标计算机系统上测试的；在后续的实际测试中，发现其代码对多处理器系统的支持不足，虽然在测试环境中进行了多次测试中，系统不会产生BSOD，但漏洞无法成功利用（即exp执行第一阶段失败）。
- chompie1337
chompie1337的代码在漏洞利用阶段则表现得十分稳定，但在内核shellcode执行时会造成系统崩溃。
因此，我们决定将chompie1337的利用代码作为主要测试对象。
内核shellcode问题定位
我们在win10 1903中测试了chompie1337的exp代码，绝大部分的崩溃原因是在漏洞利用成功后、内核shellcode代码执行（即exp执行的第二阶段）时，申请用户空间内存的API zwAllocateVirtualMemory调用失败。在我们的多次测试中，崩溃现场主要包括以下两种：
对比exp正常执行时的流程和崩溃现场，我们发现无论是哪种崩溃现场，根本原因都是在内核态申请用户态内存时，调用MiFastLockLeafPageTable时（crash_A是在MiMakeHyperRangeAccessible中调用MiFastLockLeafPageTable，crash_B在MiGetNextPageTable中调用MiFastLockLeafPageTable）函数内部出现错误，导致系统崩溃。
在遇到crash_B时，我们起初认为这是在内核态申请用户态读写权限内存时，系统复制CFG Bitmap出现的异常。CFG（Control Flow Guard，控制流防护）会检查内存申请等关键API调用者是否有效，以避免出现安全问题。
随后，我们尝试了一些CFG绕过的方法，包括替换内存申请API间接调用地址，强制修改进程CFG启动标志等，这些方法无一例外都失败了。但在尝试过程中，ZecOps在他的漏洞分析利用文章中提到的一篇文章给了我们启发。zerosum0x0这篇文章分析了cve-2019-0708漏洞内核shellcode不能稳定利用的原因，其中提到了微软针对Intel CPU漏洞的缓解措施，KVA Shadow。
我们再次详细分析了导致MiFastLockLeafPageTable调用失败的原因，发现MiFastLockLeafPageTable函数中的分页表地址（即下图中的v12）可能会无效。
我们根据KVA Shadow缓解措施原理，猜测这是本次测试exp崩溃的根本原因。内核shellcode在调用API申请用户层内存时，由于KVA Shadow对于用户层和内核层的系统服务调用陷阱，如果IRQL等级不是PASSIVE_LEVEL，无法获取到正确的用户层映射地址。
解决问题
通过参考zerosum0x0文章中修正CVE-2019-0708 payload来绕过KVA Shadow的代码，但出于时间以及系统稳定性等多方面因素，我们暂时放弃了这种方法，转而尝试通过一种更简单和容易的方式来解决这个问题。
显而易见地，如果我们能够在内核shellcode中降低系统调用中的IRQL，将其调整为PASSIVE_LEVEL，就能够解决后续shellcode执行时由于用户态内存分配出现崩溃的问题。但在公开资料的查找过程中，我们并没有找到针对win10系统的IRQL修改方法。
于是，我们从崩溃本身出发，试图对这种情况进行改进。由于内核shellcode是从DISPATCH_LEVEL的IRQL开始执行的，调用内存分配等API时，可能因为分页内存的异常访问导致崩溃，于是我们尝试避免系统访问可能崩溃的分页内存。
在重新比对分析crash_B和成功执行的利用代码时，我们发现MiCommitVadCfgBits函数中会检查进程的CFG禁用标志是否开启（下图中的MiIsProcessCfgEnabled函数）。如果能够跳过CFG的处理机制，那么就可以避免系统在内存申请过程中处理CFG位图时对可能存在问题的分页内存的访问。
进一步对MiIsProcessCfgEnabled进行分析，该标志位在进程TEB中，可以通过GS寄存器访问和修改。
我们在内核shellcode调用zwAllocateVirtualMemory API之前修改CFG标志，就可以避免大部分崩溃情况（即B类型），顺利完成用户态内存的分配。需要一提的是，win10在内存申请时，大部分系统处理过程都是针对CFG的相关处理，导致B类型崩溃产生的次数在实际测试中占比达80%以上，所以我们没有考虑A类型崩溃的情况。
参考Google Researcher Bruce Dawson有关windows创建进程性能分析的文章<O(n^2) in CreateProcess>
实际修改shellcode遇到的问题
在修改CFG标志位解决大部分内核shellcode崩溃的问题后，我们在实际测试中又发现，该exp无法执行用户层shellcode（即exp执行第三阶段）。经过分析发现，这是由于用户层shellcode会被用户层CFG检查机制阻断（参考：https://ricercasecurity.blogspot.com/2020/04/ill-ask-your-body-smbghost-pre-auth-rce.html）。CFG阻断可以分为两种情况：一是对用户层APC起始地址代码的调用；二是用户层shellcode中对创建线程API的调用。下图的代码就是针对第二种情况的阻断机制：只有当线程地址通过CFG检查时，才会跳转到指定的shellcode执行。
这里我们采用了zerosum0x0文章中的方式：在内核shellcode中，patch CFG检查函数（ldrpvalidateusercalltarget和ldrpdispatchusercalltarget），跳过CFG检查过程来达到目的。需要注意的是，在内核态修改用户态代码前，要修改cr0寄存器来关闭代码读写保护。
另外，在patch CFG检查函数时，使用相对偏移查找相应的函数地址。由于CVE-2020-0796只影响win10 1903和1909版本，因此这种方法是可行的。但如果是其他更通用的漏洞，还需要考虑一种更加合理的方式来寻找函数地址。
最终测试
我们在win10 1903（专业版/企业版）和win10 1909（专业版/企业版）中测试了代码。经过测试，修改后的exp代码执行成功率从不到20%上升到了80%以上。但我们的修改仍然是不完美的：
- 本文并没有解决漏洞利用阶段可能出现的问题。尽管chompie1337的漏洞利用阶段代码已经非常完善，但仍不是100%成功。考虑到漏洞利用阶段出现崩溃的概率非常低（在我们的实际测试中，出现概率低于10%），如果系统处于流畅运行，这种概率会更小，我们的exp仍然使用了chompie1337在漏洞利用阶段的代码。
- 在本文中，我们尝试解决了由CFG处理机制导致的崩溃情形（即类型B的情况），没有从根本上解决内核shellcode执行阶段的崩溃。在这个阶段，shellcode仍然可能导致系统崩溃出现蓝屏，但这种概率比较低，在我们的测试中没有超过20%。
- 在使用本文的方式成功执行用户态shellcode之后，系统处于一种不稳定状态。如果系统中有其他重要进程频繁进行API调用，系统大概率会崩溃；如果仅通过反弹的后台shell执行命令，系统会处在一种相对稳定的状态。我们认为，对渗透测试来说，改进后的exp已经基本能够满足需求。
其他方案
除本文讨论的内容外，还可以通过内核shellcode直接写文件到启动项的方式来执行用户态代码。从理论上讲，这种方式能够避免内核shellcode在申请用户层内存时产生崩溃的问题，但对于渗透测试场景而言，该方法需要等待目标重启主机，实时性并不高，本文不在此进行具体讨论。
总结
针对网络公开的CVE-2020-0796 exp在实际使用过程中会产生崩溃的问题，本文分享了一些方法来解决这些问题，以便满足实际在渗透测试等应用场景中的需求。尽管本文的方法不尽完美，但我们希望我们的研究工作能够为诸位安全同僚提供一些思路。我们也会在后续的工作当中，持续对此进行研究，力图找到一种更简单、通用的方式解决问题。