【漏洞评分和奖励标准】深信服安全应急响应中心漏洞审核标准和奖金奖励机制

作者:sangfor公布时间:2022/07/22

编写人:深信服安全应急响应中心

版本号:V7.7

更新日期:2022-06-15


致谢

在制定该新版本的漏洞审核标准中,特别感谢腾讯安全应急响应中心(以下简称“TSRC”)对深信服安全应急响应中心(以下简称“深信服SRC”或“SSRC”)的漏洞审核规则制定提供了支持和建议。

1 深信服SRC漏洞审核规则和标准文件信息

1.1 适用范围

本标准适用于深信服安全应急响应中心SRC(https://security.sangfor.com.cn/)所收到的所有情报。

1.2 实施日期

本标准将于2022年6月15日起执行

1.3 修订记录


image.png

image.png

image.png

image.png



2 深信服SRC基本原则

1. 深信服科技股份有限公司(以下简称“我们”、“我司”、“深信服”)非常重视自身产品和产品效果的安全问题,我们针对您反馈的问题都会有专人进行分析、跟进和处理,对于书写完整的安全漏洞报告并协助我们更快响应修复的用户,我们真诚表示感谢并承诺给予相应的报酬回馈。

2. 我们希望通过此平台与白帽子、安全研究者建立良好的互动关系,安全行业的发展离不开业界各方的共同合作,欢迎白帽子、安全组织和安全研究者加入到深信服的安全生态中,共同为网络安全事业保驾护航。

3. 我们严禁一切以漏洞测试为借口,利用安全漏洞进行破坏、损坏用户利益的黑客攻击行为,包括但不限于利用漏洞入侵业务系统、窃取敏感数据、恶意传播漏洞、暗藏木马后门以及不完整上报等。

4. 我们强烈反对和谴责任何未经深信服许可就擅自曝光所有提交至深信服SRC的安全问题与漏洞详情的恶意行为(包含已忽略状态的报告工单)。一经证实将严肃处理,我们对给与您的奖励与积分一并悉数收回,不再对该漏洞计分。同时,您需要承担因此造成的法律后果。

5.针对已提交SRC的任何漏洞,均不允许对外讨论,包括但不限于通过github、知识星球等国内外知名平台,个人博客,QQ及微信群等任何形式进行讨论。同时须对前述漏洞信息予以保密,严禁另行披露给其他任何第三方。如有违反,我司将依法保留追究法律责任的权利,包括但不限于要求赔偿由此给我司造成的损失等。

您同意:您将我们的漏洞信息通过本平台提交后,即视为您同意遵守保密的要求,未经我们公开披露相关漏洞信息之前,您不得向第三方披露该漏洞信息。

温馨提示:所有漏洞提交及审核通过涉及的奖励机制有效性均须满足上述基本原则条件一旦违反以上条例,您所提交的漏洞将不再计入奖励范围。此外,针对违规披露漏洞行为,深信服保留追究法律责任的权利。

3 漏洞/情报处理流程

1. 报告阶段:您注册并登录深信服SRC平台,提交相关信息(状态:待审核)。

    提交漏洞请按照漏洞提交报告模板中的内容和格式(粗体部分为必填项)填写一同上传。以下是漏洞提交模板:

一、漏洞环境信息

1.漏洞URL/产品版本号

2.所需权限和测试账号:

权限:匿名\超级管理员\普通管理员\无等

账号1:用户名/密码

3.漏洞利用前置条件

二、漏洞利用过程证明

1.清晰利用流程\截图或视频

2.如有涉及所需的HTTP报文,请附上完整HTTP数据包报文

温馨提示:漏洞通过代码审计方式挖掘的师傅们,麻烦还请附上成功复现和利用的截图或视频,谢谢合作。

2. 处理阶段:一个工作日内,我们会确认收到的报告并跟进处理(状态:审核中);三个工作日内会给出结论并计分(状态:已确认/已忽略),必要时会与您沟通确认,请您予以协助。对于不符合评定标准和基本原则的报告,我们有可给予降级或忽略处理的权利。若您后续补充说明或重新提交,则可以重新审核并定级。

3. 修复阶段:针对安全漏洞、安全情报,业务/产品部门修复并安排更新上线,修复时限根据实际情况而定,比如:安全情报分析调查的时间较长,因此确认周期相比漏洞的时间较长。

4. 完成阶段:我们处理完成后,更新处理状态,您可获得金币奖励和积分奖励,您可通过积分在深信服SRC平台兑换礼品。

5. 二次审核:如漏洞提交者对确认信息有疑问,请将疑问整理后反馈至SRC漏洞审核人员,将根据疑问开展二次审核。为二次审核顺利,深信服SRC可能会向您要求提供漏洞演示复现视频。二次审核总体流程如下:

image.png

4 漏洞审核规则和评定说明

4.1 漏洞审核规则

1.评分标准仅针对在深信服SRC平台提交的对深信服相关产品和业务有危害且基于深信服SRC原则有效的安全漏洞/情报,在漏洞/情报为处理完成前公开,则不对漏洞计分。

2.按照产品线划分,同一漏洞源*(定义见附录2)的多个漏洞,以最高级别的漏洞奖励标准执行,数量记一个,仅给予最高级漏洞报告积分和金币奖励,其他漏洞可视情况给予积分奖励。不同产品线的同源漏洞处理办法按照本节第4条处理(同一产品线可能存在有多个产品分支)。如若连续提交同一产品线或业务线多个同类型的漏洞,报告者可在反馈漏洞时明确给出导致漏洞和触发漏洞的关键代码,以便快速确认是否为相同漏洞,加快漏洞审核时间。

3.同一漏洞/情报重复被提交,我们将以最先提交且清晰表达、能够重现此问题的报告者为唯一金币奖励者;第二位重复提交该问题的人员将给予1积分,为后续进入SRC活动提供参加资格。

4.如所提交的漏洞与深信服内部发现的漏洞同源或重复,则以漏洞的修复情况裁定是否进行奖励:若漏洞修复完毕并发布了相应补丁包或在发布的新版本中修复了该漏洞等类似能在公网上查询出该漏洞修复完毕信息的情况,则不再对提交者发放金币,并且仅对第一位提交者给予1积分奖励;反之,该漏洞算作内部已知漏洞,进行降级处理。

5.可以通过修复一个点使得后续利用均不可行的情况,后续漏洞提交均视为重复*漏洞(“重复”定义查看附录3)。

6.同一资产等级中,评级已经为低危的漏洞,降级时按照如下方式降级:A、B类低危降级为C类中危,C类低危降级为D类中危;D类低危不进行降级,给予奖励时仅给予相应的积分奖励,不再给予安全币奖励。

7.漏洞修复完毕,即SRC平台漏洞最终状态以已完成状态闭合后,您发现该安全问题仍然存在可绕过利用方式或修复方案有缺陷并未修复完善,可重新提交该漏洞,并附上原漏洞SRC编号,注明针对原漏洞新提交的漏洞报告。新漏洞可再次按照评分标准计分。

8.各漏洞/情报的最终得分有危害大小、利用难易以及影响范围综合考虑决定。

9.拒绝无实际危害证明的扫描器结果。所有提交的漏洞报告中均须附上复现和利用成功的证明过程,即须提供完整的利用链(POC或EXP等)过程。

10.部分漏洞审核中本身比较复杂并且涉及到其它的开发部门,审核时间可能较长,有时可能由于您提供的漏洞细节不够详尽,导致漏洞审核无法按原定时间(三个工作日)内给出结论,请各位白帽子理解。因此,请您在反馈漏洞时提供详尽的POC或EXP等漏洞利用成功的证明过程,并提供相应的漏洞分析,以加快管理员处理速度。对于上述未提供完善利用过程的漏洞将可能直接影响评分与奖励。

11.由于业务调整,不再更新或维护的产品或者业务系统、网站等深信服资产将不给予金币奖励,原则上也不会修复。

12.所提交的漏洞报告如在审核中存有疑问或者需要联系漏洞提交者时,审核者通过留言联系提交者,若审核3天内无法联系上提交者,则对所提交的漏洞报告暂评为“已忽略”状态。审核者后续能够联系上该提交者后则重新修改漏洞报告状态为“审核中”状态,重新或继续对该漏洞审核。

13.确立了安全问题的奖励范围后,根据漏洞利用前提条件与权限来确定具体的漏洞奖励:

(1)匿名权限:给予奖励范围的最高线值

(2)超级管理员权限:给予奖励范围的最低线值

(3)系统管理员组/安全管理员组/审计员组:给予奖励的范围高于超级管理员权限,低于普通用户权限

(4)普通用户权限:给予奖励的范围高于系统、安全管理员组、审计员组,但低于匿名权限

在此基础上,再判别前提利用条件:给予“默认开启/关闭的配置条件”比“需要手动开启/关闭的配置条件”的奖励范围更高。

14.本规范的最终解释权归深信服安全应急响应中心所有。

4.2 安全问题评定说明

4.2.1 安全问题奖励说明

image.png

奖励公式计算=基础值✖应用系数(1金币=10元),无特殊情况下,积分奖励与金币奖励对等给予。

深信服SRC接收以下四种类别的问题:产品/业务漏洞、产品安全效果、威胁情报和BUG(不属于漏洞范围)。这四种安全问题均使用以上“安全问题评级标准”作为基础评定标准。漏洞报告提交的时候须选定确切的安全问题类别归类,后续的评定奖励才能根据上述评定标准表格中的内容给予相应奖励。奖励公式计算=基础值✖应用系数(1金币=10元),无特殊情况下,积分奖励与金币奖励对等给予。

漏洞定级所涉及的资产具体依照漏洞触发点所涉及的产品或业务决定资产范围,如产品线管辖的业务资产,属于业务线范围,不按照产品定级。

4.2.2 资产等级划分

image.png

1. 业务资产中仅域名绑定跳转到公司或各个产品线管辖的网站站点,需根据具体情况确认是否属于对应深信服资产范围。例如:该域名为深信服所申请域名,但绑定服务器为第三方,判定该资产不属于深信服资产范围。

2. 托管云、云盾类XaaS云服务产品或资产对应CDN问题不进行收录,IP绑定至x.sangfor.com上是某客户托管云站点此资产不为深信服资产故不收录。

3.根据实际风险评估aTrust控制台的登录后漏洞B资产漏洞UEM沙箱资产的相关漏洞暂不收录。

4. 漏洞所涉及的资产确认大致流程:

(1)漏洞点确认触发在哪个资产,决定属于哪个资产等级。例如:EDR技服工具导致RCE,资产定位于技服工具所在部门,而非EDR产品线部门。

(2)漏洞资产定位的确认由资产等级和资产定义共同决定,资产定义*请查看附录1

4.2.3 安全问题评级说明

深信服SRC对所提交的安全问题评级划分为五个等级:严重、高危、中危、低危和无效。所有漏洞评级流程以所提交的报告内容为准。

【严重】

1. 默认配置下直接稳定获取设备或主机root权限的漏洞,包括但不限于上传Webshell(需要登录为高危,不能上传Webshell的文件上传等文件操作为中危)、任意代码执行、远程命令执行等。同时需满足以下规定:

l无需用户交互(“用户交互”定义见附录)

l不借助第三方漏洞或深信服资产已修复的漏洞

l不借助其他方式才能获取最高权限

注:由于主机侧影响面没有设备侧危害大,客户端最高到高危评级。

2. 不需登录直接导致严重的信息泄露漏洞,特别是涉及的可影响客户身份信息安全的信息,包括但不限于重要数据库的SQL注入、系统权限控制不严格等导致的敏感数据泄露漏洞等。

3. 不需登录直接导致严重影响的逻辑漏洞,包括但不限于核心账户体系的账密校验逻辑、支付逻辑漏洞等。如果漏洞利用时没有明显恶意利用操作,则不适用于定级为严重漏洞。

【高危】

1. 需要登录的重要业务敏感数据信息泄露漏洞,包括但不限于重要用户信息、配置信息、数据文件信息等。

2. 需要登录的重要业务的逻辑漏洞,包括但不限于权限绕过等。权限绕过需要获取到权限后造成较大影响或者具体敏感信息等明显恶意效果。

3. 包含重要业务敏感信息的非授权访问,包括但不仅限于绕过认证直接访问管理后台、后台弱密码、SSRF等。SSRF需要能够直接访问并连接内网设备且可获取到回显的。例如,SSRF只能获取各个服务器等连接或者端口等信息;后台弱密码仅能查看非敏感文档信息等影响不高的操作,或非后台用户账户弱密码泄露则不适用于定级为高危,可降级处理。

4.登录前影响应用服务正常运转,包括但不限于应用层远程拒绝服务等。比如,服务器或进程崩溃后不在被持续攻击的情况下仍然处于崩溃状态,需要人工干预恢复正常的情况等定级为高该情况登录后的漏评级为中;单纯造成进程崩溃短时间占用所有访问资源的情况定级为低或无效具体视情况而定

5. 越权使用他人身份进行敏感操作,比如修改配置设定、删除备份文件等;越权后无任何操作或进行非核心功能的操作,无较大影响,例如访问非敏感项目信息等不能定级为高危,可降级处理。

【中危】

1. 不需交互对用户产生危害的安全漏洞,包括但不限于存储型XSS、DOM-XSSCSRF等。

2. 普通信息泄露漏洞,包括但不限于用户敏感信息泄露(例如身份证号、姓名、地址、手机号等)、业务敏感信息泄露(例如明文存储密码、含敏感信息的源代码压缩包泄漏等)等漏洞。

3. 普通的逻辑设计缺陷和流程缺陷,包括但不限于越权查看非核心系统的订单信息、记录等。

4. 部分本地任意代码执行漏洞,根据实际触发漏洞的条件、难易程度、实际危害等可进行降级或升级处理

5. 其他造成中度影响的漏洞,例如:没有敏感信息的SQL注入、无法回显的SSRF漏洞等。

【低危】

1. 轻微信息泄露,包括但不限于路径信息泄露、SVN信息泄露、日志文件、配置信息等。

2. 本地拒绝服务,包括但不限于客户端本地拒绝服务等引起的问题。

3. 需点击链接进行交互的OAuth登录或绑定劫持。

4. 可能存在安全隐患但利用成本很高的漏洞,包括但不限于反射型XSS、只能在特定或非主流浏览器环境下才能成功利用的存储型XSS、DOM-XSS等XSS漏洞、需要用户连续交互的敏感安全漏洞。例如:解析漏洞、暴力破解等。

【无效】

1. 不涉及安全问题的BUG问题,包括但不限于功能缺陷、网页乱码、样式混乱、静态文件遍历、应用兼容性等问题。

2. 难以或无法利用的漏洞,包括但不限于以下漏洞情形

lSELF-XSS无法获取CookieXSS

lphpinfo相关漏洞

l无敏感操作的CSRF如收藏、非重要业务的订阅、非敏感信息或资料修改等

l无意义的异常堆栈

l没有实际意义的扫描器漏洞报告(如Web Server的低版本)

l无敏感信息的JSON Hijacking

l无意义信息漏洞源码泄漏、内网IP地址/域名泄漏、401基础认证钓鱼、程序路径信任问题、无敏感信息的logcat、无敏感信息的日志文件泄露等

l文件上传不配其他漏洞无法直接解析情况

l实际意义的破解或授权安全问题破解功能不完全破解后无法更新使用核心功能例如病毒库无法更新使用最新版新版降级固件破解或者屏蔽授权

3. 无任何证据的猜测,包括但不限于扫描后发现组件低于某版本则断定存在某漏洞等。非深信服资产范围的任何安全问题。

4. 部分本地任意代码执行漏洞:文件关联的DLL劫持(如若属于但不限于以下:加载不存在的DLL文件、加载正常DLL未校验合法性、需要管理员权限操作、需要用户大量交互以及基于KnownDLLs缺陷所导致的DLL劫持等情况)。

5 荣誉榜单与奖励发放

5.1 荣誉榜单

深信服SRC为感谢每一位提交有效安全问题的白帽子,特设荣誉榜单,以示感谢。一般情况下,总共设置了三种荣誉榜单:总排行榜、年度排行榜、月排行榜。此外,每隔半年在深信服SRC和深信服安全应急响应中心微信公众号分别发布深信服SRC半年榜单,同时联合应季活动,颁发相应的奖励和礼物,感谢您对深信服SRC长期以来的支持,表达了内心由衷的喜悦和崇敬之意。

5.2 奖励发放

5.2.1 常规奖励发放

所提交的安全问题已经审核通过,状态变更为已确认状态后,深信服SRC平台一般情况下会给予一定的金币奖励。金币(深信服SRC平台上的一种虚拟货币)可以用于SRC商城中兑换礼品。每个账户提交的安全问题产生的安全币可累加,金币数目除非特别情况下,未使用的安全币不会过期。

平台商城支持实时兑换奖励,其中商城礼品上架时有数量限制,当期上架奖品被兑换完后不再接受兑换。每月月初会定期增加礼品数目和处理礼品兑换订单。处理兑换订单时候会联系兑换人确认信息,以便核对订单和兑换人信息的真实有效性。如若未能及时完善个人信息导致的延误将顺延至下周发放。

对于由于兑换者个人过失、快递公司问题以及人力不可抗拒因素产生的奖品损坏或丢失,深信服SRC不承担责任。

5.2.2 年度贡献奖励

综合考虑您的贡献值排名、报告质量、协助复现和修复、遵守安全测试规范、保持友好沟通等多方面贡献,评选深信服SRC年度特别贡献奖。

5.2.3 年度漏洞额外奖

对于为深信服提交核心业务严重且影响范围较大的漏洞,并提供了高质量漏洞报告协助业务团队更快响应修复,对深信服业务安全做出了重大贡献的白帽子,深信服SRC将颁发年度漏洞额外奖:神秘大礼包一份。

5.2.4 高价值漏洞额外奖励

针对漏洞挖掘技巧多,漏洞触发简单但漏洞价值很高或影响面广、程度严重的漏洞可以适当提升奖励,最高不超过上一级漏洞奖励区间的底线。相反地,漏洞评级确认后单但漏洞价值在实际情况中较低,如资产列表泄露或登录后DOS漏洞、越权访问某资产列表等,保留原评级,但奖励适当降低,奖励标准统一为D类低危,金币奖励范围为1-10金币。

6 保护机制

6.1 举报机制

为维护良好的SRC生态,欢迎内/外部人员监督举报。举报内容包括但不限于任何人员对深信服资产的违规测试、违规漏洞提交(例如内部人员借用外部账号)、恶意刷洞、内部环境泄露等情况。提交举报时须提供被举报人的详细名字,完整截图等信息,具体联系方式请参考第七章。

6.2 厂商保护机制

1. 深信服集团及相关所属子公司、分公司的员工(包括正式员工、外包员工)或就职于本公司的实习生或临时工均不能通过直接或者间接的方式将深信服资产的漏洞提交至深信服SRC(间接方式比如由亲属代提交,朋友代提交等)。前述人员视为内部人员,内部人员提交漏洞需走内部通道*(详情查看附录5),一经发现违规提交行为或违规披露情形,深信服保留追究法律责任的权利。

2. 同一IT资产(站点、系统等)或产品的若并未对某类漏洞做过滤,最多只收取5个,超过5个将不再发放奖励,以提交时间顺序为准。

3.针对通用型漏洞处理:

- 提交多个通用型漏洞,处理方式等同于同源漏洞,奖励只给予一份。包括但不限于:同一JS发布系统框架泛域名解析导致的整站XSS/CSRF/注入漏洞同一域名下同一组件产生的多个flash XSS漏洞等

- 第三方未披露:审核人员将联系白帽子提交至国家监管平台(CNVD/CNNVD)

- 第三方已披露:根据官方或公开修复方案确认漏洞并修复,SRC以事件型漏洞处理并同样给予奖励(产品线产品漏洞按照产品资产等级,产品线业务资产漏洞按照业务资产等级确认)

4. 0day在外部首个媒体公开72小时内,深信服SRC将收到该0day漏洞利用不再进行奖励发放。

7 争议解决办法

平台对于每一份安全漏洞报告都会安排专人进行跟进、分析和处理,并及时给予用户答复。如果您对本标准有任何的建议,欢迎通过以下方式与我们联系:

1. 向深信服安全应急响应中心微信公众号SangforSRC留言;

2. 直接将反馈发送到官方邮箱,官方邮箱anquan@sangfor.com.cn;

3. 进入“深信服安全应急响应中心”反馈;

4. 通过深信服SRC外部白帽交流群(微信群)联系SRC运营进行反馈。

注意事项

1. 本规则发布之前漏洞评级均不再更改,更新后的新标准于2022年6月15日开始执行。

附录

附录1 深信服资产(产品)定义

一、资产等级对应的资产版本定义

image.png

注:

1、补丁包信息等详情可查看“安全公告”下的【资产更新】公告,补丁包版本可从/app/appversion查看

2、该资产版本号并不是资产最新版本,深信服社区同理

附录2 “同一漏洞源”定义

以下情况视为同源:

- 同一功能模块下的不同接口

- 同一文件的不同参数

- 同一参数出现在不同文件

 -不同版本或不同平台的同一漏洞

- 同一函数导致漏洞

- 同一漏洞不同利用链(不包括若多个漏洞触发点中若有漏洞触发点不一样的利用链的情况)

- 多个产品复用同一段代码,如果不能够给出明确证明的情况下除外

具体视实际情况而定

附录3 “重复”定义

1. 所提交的漏洞同源或重复与SRC平台上其他白帽子所提交的漏洞重复,执行本文4.1节第3条

2. 所提交的漏洞未与SRC平台上漏洞重复或同源,但与内部漏洞同源或重复,执行本文4.1节第4条

3. 针对本文4.1节第5条举例说明:如多个接口中使用了同一个全局函数进行数据处理,该函数导致了漏洞形成,则所有此类漏洞均视为同一漏洞。

附录4 “用户交互”说明

不需要登录、需登录(开放注册)、需登录、需人为触发(包括但不限于客户端需要权限才能触发)

附录5 “内部通道指引

产品漏洞提交MOA搜索psirt即可提交IT业务漏洞提交:MOA搜索security即可提交

附录6 文档下载

该文档提供pdf版本下载,下载地址为:

 https://edradmin.sangfor.co/app/file/tool/深信服安全应急响应中心漏洞标准和奖金奖励机制V7.7.pdf