以前 18 年的时候因为做的是安全漏扫开发的工作,所以那段时间经常接触 CVE 漏洞,但是有时候会被一些垃圾 CVE 气的缓不过气来,所以为了证明 CVE 可以真的很水,当时我自己也水了几个 CVE(打不过就加入?),如今时隔 3 年了,正好赶上博客大改版,那就顺便来水一篇文章,教大家如何水一个 CVE 吧。
全站浏览量和评论最高的文章前几天发现了一个致命的问题,就是评论突然无法正常加载了:
因为博客最近改版,Valine 也换的最新版本,可能是哪个评论和这个 Valine 冲突了,所以下面来尝试找出罪魁祸首并恢复原文评论。
备份评论
首先在 LeanCloud 中「按条件过滤」出所有 Termux 文章下面的评论:
然后将筛选后的结果导出为 JSON 格式的文:
这样就备份评论成功了。
尝试恢复
LeanCloud 自带的评论恢复功能基本上是不能使用的,首先「备份恢复」功能只有商用版本可用:
使用「数据导入」的功能,结果是覆盖式导入:
当时差点就把我的「Comment」类下的 2.3k 个评论给覆盖了(巨坑呀 一不小心可能就重头再来了):
没办法只能想其他办法了。
脚本恢复
LeanCloud 支持一个个手动添加行,类似于这样的效果:
现在思路就是抓取添加行的数据包,看看能不能使用脚本自动化读取之前的 JSON 文件添加进去,经过 Fuzz 测试发现可以自动化添加,最终的脚本如下,相关说明都放注释里面了:
import json
import requests
# 读取 json 文件并返回数组
def get_comments(path):
with open(path, 'r', encoding='UTF-8') as jsonfile:
json_list = json.load(jsonfile)
return json_list
def main():
# 这个是抓取提交评论的数据包的 URL
url = "https://cn-n1-console-api.leancloud.cn/1.1/classes/Comment?fetchWhenSave=true"
headers = {
"Host": "cn-n1-console-api.leancloud.cn",
"X-Lc-Ua": "LeanCloud-JS-SDK/0.0.26(Browser)",
...
这里老老实实填写抓包时候的 headers
...
"Accept-Encoding": "gzip, deflate"
}
# 读取 termux.json 位置的文件
comments = get_comments('termux.json')
# 对评论进行切片
comment = comments[:50]
# 考虑到评论互相引用的情况,所以得有 pid 和 rid
if 'pid' in comment:
pid = comment['pid']
rid = comment['rid']
else:
pid = ""
rid = ""
# 提交评论的基础格式
data = {
"ACL": {"*": {"read": True}},
"isNotified": False,
"pid": pid,
"rid": rid,
"comment": f"{comment['comment']}",
"objectId": f"{comment['objectId']}",
"insertedAt": {
"__type": "Date",
"iso": f"{comment['insertedAt']}"
},
"createdAt": {
"__type": "Date",
"iso": f"{comment['createdAt']}"
},
"link": f"{comment['link']}",
"mail": f"{comment['mail']}",
"nick": f"{comment['nick']}",
"ua": f"{comment['ua']}",
"url": f"{comment['url']}"
}
# 发起提交评论的请求
r = requests.post(url=url, headers=headers, data=json.dumps(data))
if __name__ == '__main__':
main()
找出问题
几百个评论如何找出哪些评论出问题了呢?实际上主要调整如下代码即可:
# 读取 termux.json 位置的文件
comments = get_comments('termux.json')
# 对评论进行切片
comment = comments[:50]
通过comments[:50]
先导入前 50 个评论,如果网页刷新正常的话,再导入comments[50:100]
50-100个评论,以此类推可以很方便的找出问题评论,最终找出的 BUG 评论如下:
找到了罪魁祸首,这个评论插进去,我的评论就挂了。简单 Fuzz 发现根本问题出在了 UA 里面,这个用户评论的 UA 很短,新版本的 Valine 会根据用户的 UA 会识别用户的操作系统和浏览器类型,因为这个 UA 很短,直接导致 Valine 的相关 JS直接异常,从而导致整个评论挂了。
验证危害
为了验证我这个情况不是个例,网上寻找其他使用了最新版 Vaine 的 Hexo 博客试试看,锁定了一个目标:
评论抓包改下 UA:
发包,成功将对方页面评论打瘫掉:
OK 这个虽然是一个很没有技术含量的 BUG,但是找到这个小 BUG 也消耗了不少时间,所以与其花了这么多时间不如用这个 BUG 去水一个 CVE,毕竟 Valine Github 上面也开源了,也有过千的 star,那么下面就开始去提交这个 CVE 吧。
编写细节
提交 CVE 前首先得说明一下漏洞细节,可以是个人文章也可以是直接 Github 对应的项目提交 issue,国光我这里就直接在 Valine 项目下提交了 issue:
a fatal bug that can kill the comment system(用户恶意修改 UA 评论 可影响正常评论加载) #366
小细节就是尽量使用英文去描述漏洞细节,如果你英语像我一样不太行的话可以使用谷歌翻译,总之可以让老外读懂漏洞的来龙去脉就行了。
提交 CVE
提交 CVE 的官网地址为:https://cveform.mitre.org
下面我帖一下本次申请的表单填写情况。
- 「 Select a request type」我这里选择的是:
Report Vulnerability/Request CVE ID
,即报告漏洞或申请 CVE ID - 「Enter your e-mail address」填写自己的邮箱信息用于接收 CVE 编号:
[email protected]
- 「Number of vulnerabilities reported or IDs requested (1-10)」报告的漏洞或请求的 ID 数,国光填的默认
1
勾选一下「漏洞不在 CNA 列表」和 「漏洞没有被申请过 CVE 编号」:
「Vulnerability type」这里根据自己的情况选择漏洞类型,因为我这个 BUG 不好定义,所以填写了
Other or Unkown
「Other vulnerability type」因为上面漏洞类型选择的 Other,所以需要对这个漏洞进行简短的说明,国光的说明内容如下:
a fatal bug that can kill the comment system,Similar to DDOS
「Vendor of the product(s)」 产品供应商,国光这里填写的是:
Valine
「Affected product(s)/code base」受影响的产品/代码库,根据情况填写
Valine
版本为1.4.14
「Has vendor confirmed or acknowledged the vulnerability?」供应商是否确认或承认漏洞,这里当然选择
Yes
「Attack type」攻击类型,这里 Web 攻击大多数
Remote
远程的「Impact」影响的话,国光这里勾选了
Denial of Service
「Affected component(s)」受影响的组件,这里可以填写问题代码、影响的功能等
「Attack vector(s)」攻击向量,主要就是漏洞利用的 Poc,国光原文内容如下:
"ua":"Mozilla/5.0", Details can be seen in https://github.com/xCss/Valine/issues/366
主要就是贴了核心 Poc 和 Github 详情
「Suggested description of the vulnerability for use in the CVE」在 CVE 中使用的建议和描述:
Valine 1.4.14 allows remote attackers to cause a denial of service (application outage) by supplying a ua (aka User-Agent) value that only specifies the product and version.
这块的最终的呈现效果如下:
「Discoverer(s)/Credits」漏洞发现者或者组织,国光这里填的是
www.sqlsec.com
「Reference(s)」漏洞参考链接,这里贴一下之前提交的 issue:
https://github.com/xCss/Valine/issues/366
最后填写验证码提交我们上面填写的表单即可:
过程概览
提交完之后,上述 CVE 申请的邮箱会很快收到应该邮箱:
大概意思就是你提交的漏洞我们收到了,这个漏审核成功有 CVE 编号了再通知你。
如果漏洞比较合规的话,可以很快收到 CVE 编号的回复邮件:
可以看到中午提交漏洞,晚上就收到 CVE 编号的邮件了,效率比我 18 年的时候快了很多(18 年的时候基本上得两三天时间)
在邮件的后面几可以找到自己的 CVE 编号了:
本次申请的 CVE 编号为:CVE-2021-34801
谷歌一下,发现今天很多网站已经收录了:
Bingo,完整的 CVE 申请流程就是这个样子了,过一段时间后国内的 CNVD 也会收录这个 CVE 漏洞,然后再分配一个 CNVD 编号的,溜了溜了,差不多到这就结束了,老头打了个响舌nice.mp4
CVE 的话更多的还是圈外人看起来比较高大上,实际上懂得都懂,CVE 编号多并不算什么,如果你很多比较水的 CVE 的话,只能说你这个人像国光我一样比较闲得蛋疼,所以追根到底还是看漏洞质量!建议大家水 CVE 点到为止即可。
下面分享应该 Hackerone 上一个价值 $11214 的漏洞:
https://hackerone.com/reports/1065500 (Multiple bugs leads to RCE on TikTok for Android)
漏洞详情已经披露了,可参考:TikTok for Android 1-Click RCE
这才是真的牛皮!!!
本文可能实际上也没有啥技术含量,但是写起来还是比较耗费时间的,在这个喧嚣浮躁的时代,个人博客越来越没有人看了,写博客感觉一直是用爱发电的状态。如果你恰巧财力雄厚,感觉本文对你有所帮助的话,可以考虑打赏一下本文,用以维持高昂的服务器运营费用(域名费用、服务器费用、CDN费用等)
没想到文章加入打赏列表没几天 就有热心网友打赏了 于是国光我用 Bootstrap 重写了一个页面 用以感谢 支持我的朋友,详情请看 打赏列表 | 国光