内核漏洞利用之CVE-2020-17382篇（下）

在本文中，我们将以CVE-2020-17382漏洞为例来介绍内核漏洞是如何被武器化的。

在上一篇文章中，我们首先解释了攻击者为什么会以驱动程序为攻击目标，然后，分析了驱动程序的组成部分，最后，讲解了驱动程序的逆向分析和调试方法。在本文中，我们将以CVE-2020-17382漏洞为例为读者介绍内核漏洞的利用过程。

攻击MSIO64.sys

现在，我们知道了如何在Ring0中获得指令指针的控制权，接下来，我们将为读者演示如何开发不同的POC。我们将要使用的shellcode是一个标准的Token Stealing，它的目的是通过窃取SYSTEM进程的token来提升当前（或另一个）进程的权限。正如我所说过的，本文不会对Windows 7进行太多的讨论，但尽管如此，它还是帮我认识到了内核模式中进程恢复是多么的至关重要。然后，在讨论进入Windows 10平台之前，奇热我还是要简单聊一聊这个话题。

Windows 7

在Windows 7平台上玩弄了一段时间这个漏洞的利用代码之后，我终于让shellcode正常运行了起来，但问题是：我始终无法找到一种稳定的方法来恢复原来的执行流并释放调用堆栈的其余部分，而每一次尝试都会导致残酷的Bug Check。

然后，我们继续提出了几个“what if”式的问题。如果我们能找到一种方法，它能在冻结内核线程的同时提升另一个进程的权限，那会怎么样呢？问题是，我们不能让这个进程在内核中直接崩溃，否则整个系统都会挂掉。我们必须找到一种方法，要么恢复执行，要么让这个线程无害化。

然后，我开始调整shellcode/exploit，让它把偷来的SYSTEM令牌复制到任意进程，比如另一个打开的cmd提示符，它可以作为命令行参数传递。这样一来，我们就可以不那么关心初始进程的命运了，因为当bug check发生时，我们已经提升了目标进程的权限。但是，我们如何防止BSOD呢？突然，我想起Matt Miller写了一篇关于Ring0 payload的文章，仔细拜读之后，很快就得到了回报。在众多的payload中，我获得了一个相当令人惊讶的发现：我发现的解决方案仅由两个字节组成，即\xEB\xFE ，或JMP 0x0。这一招很老套，并且使用范围不限于内核shellcode。在提升目标进程权限后，通过在shellcode的末尾附加这些指令，我们就能让原来的线程永远运行下去，这样就不会把系统弄崩溃了。当然，这绝对算不上一个优雅的解决方案，但它的确是行之有效的，至少在Windows 7上是如此（由于Windows 10提供了更强大的检测机制，最终会检测到这个浪费资源的内核线程，并引发bug check）。

为了将这个漏洞武器化，我们只需要在用户空间的缓冲区中为实现令牌窃取的shellcode分配空间即可，由于Windows 7基本没有提供内核防御措施，我们的exploit只需要用shellcode的指针覆盖返回地址即可。

下面给出了该exploit的运行效果：

Windows 10 1709

绕过SMEP和其他内核漏洞利用缓解措施

与Windows7相比，Windows 10采用了几种内核级别的漏洞利用缓解措施，例如：

· 内核模式代码签名（KMCS）