作者： 国光大佬
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()
找出问题
几百个评论如何找出哪些评论出问题了呢？实际上主要调整如下代码即可：
PYTHON
# 读取 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 ：https://github.com/xCss/Valine/issues/366
小细节就是尽量使用英文去描述漏洞细节，如果你英语像我一样不太行的话可以使用谷歌翻译，总之可以让老外读懂漏洞的来龙去脉就行了。
提交 CVE
提交 CVE 的官网地址为：https://cveform.mitre.org
下面我帖一下本次申请的表单填写情况。
- 「 Select a request type」我这里选择的是：
Report Vulnerability/Request CVE ID，即报告漏洞或申请 CVE ID - 「Enter your e-mail address」
填写自己的邮箱信息用于接收 CVE 编号：
admin@sqlsec.com - 「Number of vulnerabilities reported or IDs requested (1-10)」报告的漏洞或请求的 ID 数，国光填的默认
1
勾选一下「漏洞不在 CNA 列表」和 「漏洞没有被申请过 CVE 编号」：
- 「Vulnerability type」这里根据自己的情况选择漏洞类型，因为我这个 BUG 不好定义，所以填写了
Other or Unkown - 「Other vulnerability type」因为上面漏洞类型选择的 Other，所以需要对这个漏洞进行简短的说明，国光的说明内容如下：
VERILOG
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，国光原文内容如下：
VERILOG
"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 中使用的建议和描述：
VERILOG
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）
漏洞详情已经披露了，可参考：https://medium.com/@dPhoeniixx/tiktok-for-android-1-click-rce-240266e78105
这才 是真的牛皮！！！
作者：国光大佬，转自其博客：https://www.sqlsec.com/2021/06/cve.html
如有侵权，请联系删除
推荐阅读
查看更多精彩内容，还请关注 橘猫学安全
每日坚持学习与分享，觉得文章对你有帮助可在底部给点个“ 再看 ”