聊聊最近挖 Security Bounty 的感受

聊聊最近挖 Security Bounty 的感受

编程那点事 随便写写 4433 字 / 9 分钟

文章头图来自 @大空水獭 https://t.bilibili.com/637532953957629970

起因

有将近四个月没写点东西了。赶着周六的凌晨,带着些许睡意,想来分享下从去年年末到现在挖 Security Bounty 的感受与经验。文中会挑选几个我觉得有意思的漏洞,分析其背后的故事以及我的想法。

记得三年前,大二上学期刚开学协会招新的时候,跟新生聊到协会的 @Li4n0 学长大二就 Typora RCE 连拿两个 CVE,那新生便问我有没有 CVE 编号。我一时语塞,挠挠头尴尬地回答没有。可能就是这个原因吧,后来自己特别想要有个 CVE 编号。 之后虽然也在空闲的时候陆陆续续地去挖了一些 SRC,赚了点小钱,但最终的报告又不公开,自己拿了钱确实爽,但对外没啥能吹得。😅

时间来到了去年年末十二月份,我突然对国外某产品的一个功能的代码实现很感兴趣,便去翻他们网站上关于此功能的设计文档。看完后暗自佩服的同时也在想这么大个公司会不会有啥洞呢?趁热打铁挖了一波,还真有!后面陆陆续续地交了这个公司的几个洞,小赚了一笔大的。但,依旧没有 CVE。
(虽然到后面给补上了)

后面我便转换了下思路,专盯着那些 stars 数很高的开源项目。时间来到一月下旬,当时公司在搞一套内部的统一鉴权系统(SSO),用于各项独立服务的登录鉴权。国内有很多仿照海外 Auth0 做的产品,但价格都太贵了。最后选择使用开源项目 casdoor (https://github.com/casdoor/casdoor) 进行自建。casdoor 是基于著名 casbin 项目发展而来的,两者有着千丝万缕的关系。同时 casdoor 也是使用 Go 语言进行开发,我便试着白盒扫了下。好家伙,还真给我捡了漏了,扫到一处 SQL 注入。

CVE-2022-24124 casdoor SQL 注入

漏洞触发的原理很简单,有几个公开的 Web API 查询接口支持对表中任意字段的模糊查找,具体的代码实现是字段名直接从 field 的 Query 参数中传入,格式化字符串拼接进 "%s like ?" 语句,导致 LIKE 前面的内容可控,从而引发 SQL 注入。那这管你套啥 ORM,神仙也救不了你。 PoC 见 #439

官方修复的 PR 刚开始是用黑名单过滤字符,我 review 时直接给绕了哈哈。我给的修复建议是用反射解析结构体里的字段,作为 field 参数的白名单进行过滤。官方后面觉得这样太复杂了,直接正则检验只能传入大小写 + 数字,给牢牢地限制死了。

可惜的是我貌似是第一个给 casdoor 提交安全漏洞的人,官方以前并没有相关的漏洞处理流程。最后只能自己默默地去申请了 CVE 编号,CVE 下来的那天我还在回老家的车上,看到手机上收到的邮件兴奋地不得了。(但我其实更希望的是官方能主动帮我申请,也算是一种特别的感谢与肯定。)

CVE-2022-24123 marktext XSS -> RCE

在挖到 casdoor 的 SQL 注入之后的第二天,我微信上刷到了一篇文章,文章介绍的是在 Typora 收费后,作者说大家可以使用 marktext 这个开源免费的 Markdown 编辑器作为替代。想起之前 @Li4n0 挖到了 Typora 的 RCE,正巧这个 marktext 也是基于 Electron 实现的跨平台桌面应用,我也想来试试。 可惜我一看到 JavaScript 就头大,根本不想去认真审,随即胡乱地在翻着 marktext 的 issue。突然发现了这个长达一年之久的 issue #2504。他里面提到 marktext 的 Mermaid 图表功能存在 bug,输入类似 HTML 的标签 <something_in_chevrons> 自动给闭合变成了 <something_in_chevrons>some text</something_in_chevrons>。 我一看,好家伙,这不说明输入被当做 HTML 解析了嘛,这不妥妥的 XSS 嘛。我在 marktext 中把他 issue 里的标签内容改成 <img src=1 onerror="alert(1)">,直接就弹窗了。改成

<img src=1 onerror="require('child_process').exec('open /System/Applications/Calculator.app')">

直接弹计算器了。成了! 真的是白捡了一个 RCE,提给后官方很快就修了。但根据 marktext 之前几个 RCE 的 issue,最终都是漏洞提交者去申请了 CVE。所以我又只能自己去申请 CVE 编号,凄惨。

后面我简单的跟了一下这个洞,发现是直接将 innerHTML 设置成用户输入导致的。后来全局搜索代码,也发现了一处同样的问题,不过读取的是用户剪贴板中复制的内容。想了下好像没啥能利用的可能,毕竟用户哪会傻到去复制一段自己都看不懂的奇怪代码进来。可是…… 就在我这个 CVE 公开的几天后,一个韩国老哥交了这个剪贴板复制导致 RCE 的洞,居然还被承认了!血亏啊!

与 Cloudflare 的纠缠

过年期间住在奶奶家的时候,晚上睡前会随便网上冲浪到处看看。那个时候我把 GitHub Advisory Database 里所有 Go 相关的历史漏洞信息全部爬了下来,整理成了一个 Excel 慢慢看,企图从中总结出一些 Go 相关漏洞的特点。看到之前 Iris 框架之前上传文件目录穿越的洞。漏洞的成因是 Iris 想修目录穿越,但只是用了很简单的分步 strings.ReplaceAll 进行替换,这个的绕过不用说了吧…… 双写一下就完事了:....//

// Fix an issue that net/http has,
// an attacker can push a filename
// which could lead to override existing system files
// by ../../$header.
// Reported by Frank through security reports.
header.Filename = strings.ReplaceAll(header.Filename, "../", "")
header.Filename = strings.ReplaceAll(header.Filename, "..\\", "")

我看了真的觉得好笑,不会吧,不会吧!不会真有人这么防目录穿越吧?!全局搜了下,好家伙,还真有,还是大名鼎鼎的 Cloudflare。 他们在这个 commit 里修复了 CVE-2021-3907 这个下载文件时目录穿越可能导致 RCE 的高危漏洞。修复的方式也是很简单粗暴:

path = strings.ReplaceAll(path, "../", "")

我按照 GitHub Advisory 下的指南给他们发送了邮件,几天后他们就给修了,并且发布了新的 GitHub Advisory。我便发邮件多问了下能否在这个 GitHub Advisory 下给我的 GitHub 账号加个 Credit,这样我的 GitHub Profile 下面也有一个好看的小徽章了!

对方隔了半个多月回邮件了,没直说不行,而是让我去 HackerOne 上再提交一波,然后给我 Bounty。可是…… 比起钱,我还是更想要这个好看的徽章,大家都有就我没有,我好没面子。 😭😭😭

开始使用 huntr.dev

后来在 Twitter 上刷到了 huntr.dev 这个平台。他们的目标是提高 GitHub 上开源项目的安全性,只要提交 GitHub 上开源项目的漏洞,他们作为平台方就会帮你联系项目的开发者,并在漏洞确认后给予一定的 Bounty 奖励,甚至还能帮忙申请 CVE。给予的 Bounty 金额好像跟项目的 stars 数正相关。我查了下 Cardinal,发现交 Cardinal 的洞都能赚个 10 美刀。那我自己往 Cardinal 里写洞自己交,左脚踩右脚是不是能上天?

CVE-2022-0415 Gogs RCE

恰好那段时间无闻邀请我进了 Gogs 的组织中,闲聊的过程中他也提到了 huntr,说最近有很多人通过这个平台给 Gogs 提交漏洞让他确认。huntr 现在也成为了 Gogs 项目推荐的漏洞上报方式。 就当熟悉 huntr 的提交流程了,我粗略地看了下 gogs 的源码,直接对着危险函数硬搜。(说是粗略也不是,之前写 CRUD 的时候项目结构都是借鉴的 Gogs,看了无数遍了)

结果还真找到了一处 RCE。


时间要回到大一下学期的暑假。我是个很懒的人,平时很少复现漏洞,除非那个洞的利用过程很吸引我,不然我就是看一眼网上复现的文章就结束。到目前为止我认真复现过的漏洞数量屈指可数。大一暑假的时候我看到土爷发了一篇复现 Gitea RCE (CVE-2019-11229) 的文章,其中的利用过程很巧妙: 通过 go-ini 库存在的 CRLF 漏洞,逃逸引号出来改写本地 Git 仓库的 .git/config 文件,通过设置 core.sshCommand 参数,在 Git 仓库被 pull 和 fetch 时,对应的命令将会被执行,从而达到 RCE 的目的。这个 core.sshCommand 的 trick 我到现在还在用,真的屡试不爽。如果以后有人问我印象最深的漏洞是哪个,我绝对会回答是这个!它吸引我的点在于,它在一个合法的正常的我们日常都在用的程序 (git)中找到了一个因为恶意的配置,导致可以 RCE 的操作。

Gogs 的这处 RCE 最终的原理也是如此。我在文件上传处看到其从上到下是这样处理上传文件的路径的。

dirPath := path.Join(localPath, opts.TreePath)
...
// Prevent copying files into .git directory, see https://gogs.io/gogs/issues/5558.
if isRepositoryGitPath(upload.Name) {
	continue
}
...
targetPath := path.Join(dirPath, upload.Name)

其中 targetPath 是最后文件写入的路径。后半段文件名 upload.Name 做了检测,防止复制文件进入 .git 目录,而前半段 dirPath 中的 opts.TreePath 是来自用户传入的可控参数,这个参数却没有被检测。所以我们在上传文件时构造 tree_path=/.git/ 即可将文件上传至仓库的 .git 目录中,后续 Gogs 会本地 pull + push 我们的仓库,使用上面的 trick 覆盖 /.git/config 文件即可实现 RCE。当然,我们也可以直接 tree_path=../../../xxx 目录穿越写系统定时任务弹 Shell,利用的方法数不胜数。

目前 Gogs 的 main 分支已经修复该漏洞,且在最新发布的 0.12.6 中得到修复。具体报告 huntr 已公开:https://huntr.dev/bounties/b4928cfe-4110-462f-a180-6d5673797902/

但离谱的是,在 huntr 提交报告时网页上已明确说明此项目会给申请 CVE。但直到漏洞确认修补后,huntr 官方也没动作。无奈我只能找 huntr 管理员,有趣的是这个管理员在 GitHub huntr 仓库提了个 issue,抱怨每天都有一堆人找他手动申请 CVE,他想要一个自动化的方案,同时把所有找他申请 CVE 的人全截图挂在了 issue 下。对没错,我也被挂了。😡

但不管怎么说,我最终都如愿以偿地获得了第一个 GitHub Advisory Credit!感谢无闻老师!🥳

[CVE 待申请] Gitea 任意文件删除

提交完这个 RCE 后,我第一时间肯定是去看 Gitea 是否存在类似的问题,可惜 Gitea 后面改成了直接对 git 的 Index 等进行操作,相当于直接操作 git 数据库了,不再是像 Gogs 一样本地模拟用户添加文件再 add + commit + push 的操作。 但我又想起 Gitea 喜欢整花活,啥有用没用的功能都往里面塞,比如它就支持 Git LFS。嘻嘻,这 LFS 你总得老老实实地上传文件了吧?可惜 Gitea 做了严格的过滤。 我又继续搜起了危险函数来,发现上传后的 LFS 文件 Gitea 都会对文件名做哈希,然后取文件名哈希前 1、2 位,3、4 位,建立目录,作为文件最终的存放路径。这种操作在很多包管理系统中都很常见,iOS 的 CocoaPods 就是这样的。 例如我们在 Gitea 上的文件名是 48076e66a051950bd5cd7fc489924a5d67865dac,那么它将被存放在 48/07/48076e66a051950bd5cd7fc489924a5d67865dac 下面。具体的代码实现是这样的:

func AttachmentRelativePath(uuid string) string {
	return path.Join(uuid[0:1], uuid[1:2], uuid)
}

那要是我传入一个文件名为 ....foo 的 uuid,它是不是路径拼接后就把 ../../foo 的文件给删了?确实是这样的捏~ 但是 LFS 文件的添加和修改接口,在操作前都会查询一遍数据库确保这个 uuid 存在。但对于删除操作,是 ORM 删除一下数据库的记录,然后再删除文件。Go ORM 的删除操作都一样的特性,根本不管你 WHERE 条件是否能查到记录进行删除,删了个寂寞也给你返回成功。最好在执行删除操作后再检查一下 RowsAffected 确认影响的行数。 所以通过构造 ....%2fcustom%2fconf%2fapp.ini 这样的 uuid,我们就能轻松的删掉 Gitea 的配置文件。可惜只有在程序重启后才会触发重新安装的操作。删除了 SQLite 的数据库也只是给你 500 报错而已。目前倒是没想到很好的利用方式。

具体报告 huntr 已公开:https://huntr.dev/bounties/c5ed8660-a896-4101-b6a7-05772443485b/

令我不开心的是,Gitea 明明在报告中表明要在博客文章中对我进行感谢,且询问了我的用户名,但是在最终发布的文章中却漏了。我在报告中询问后他们提了个 PR 说会补上,但是这个 PR 现在就卡在那里没人 review 没人合;以及 huntr 说的帮申请 CVE 到现在也没消息。

最后说几句

所以这不欺负老实人嘛?直到现在,挖了这么多洞之后,我都没能有一次畅快的经历。 CVE 得我自己申请,官方的感谢要不是没有,就算有了最后也给漏了。然后 Cloudflare,加个 GitHub Advisory Credit 是会判刑还是怎么?同一个项目中,别人有我就没有。交了 Hackerone 还跟我掰扯半天问我为啥能 RCE,你之前那个洞不是自己定的高危 RCE 然后自己没修好嘛?好家伙双标是吧? 啊对对对,我承认我就是追名逐利,就看中这些虚无缥缈的感谢啊,徽章啊。这些就是我跟别人瞎吹逼的资本,所以我在意。

嘛,接下来有空的时候会去尝试做更有效率的开源软件漏洞挖掘,不想再像上面那些纯靠运气成分或人工肉眼看了。现在脑子里其实已经有一些酷炫的想法想要去做了,奈何自己太菜了还有不少前置知识得去学习的。不过至少,今年跨年定的年度目标:获得人生中第一个 CVE 编号,以及今年 Bug Bounty 总金额超过 [已删除] 元这两个目标已经提前圆满完成了。