白帽子看过来:漏洞报告平台那点事

安全 漏洞
我既不是互联网公司的员工,也不是知名白帽子,但这一段时间关于甲方SRC平台与第三方平台的种种故事,老马我实在看不下去了了,不吐不快。

最近几天金山和新浪又相继推出了SRC(安全应急响应中心),目前国内排的上号的互联网公司大部分都有了自己的漏洞收集报告平台(有人问,就一个漏洞报告平台,为什么要取名应急响应中心呢?高端大气上档次吗?)。我既不是互联网公司的员工,也不是知名白帽子,但这一段时间关于甲方SRC平台与第三方平台的种种故事,老马我实在看不下去了了,不吐不快。虽然在以前在微博上说过几次,但每条微博每次只能说那么几个字,根本不能表达我的观点,所以干脆写一篇文章说说我的一点看法。本文仅代表老马个人观点,与任何组织无关,不是任何单位的软文枪文,但绝不排除这是炒作。欢迎转载,但请保留出处版权。拍砖请到http://weibo.com/topiceyes

  提交漏洞与奖励

  上月26日参加京东安全沙龙,在最后的讨论环节,刺总(@aullik5)提了几个比较有意思的问题,其中一个大致意思是“白帽子把漏洞提交给第三方漏洞平台厂商是否应该给予奖励。”这个第三方平台主要是指乌云。这个问题问的时间恰好属于一个非常敏感的时期,沙龙的前几天,我因为报告了“来往”安全漏洞而获得ASRC的IPAD奖励,而小伟同学虽然比我早发现但因为报告到乌云平台错过了这个机会,这在当时引起了很多的口水。不管这是炒作,还是措辞不当的问题,但不可否认的一点,这基本上代表了大部分甲方SRC的态度。沙龙上我第一个阐述了自己的观点,虽然算是局中人,不过我脸皮比较厚,回答起来脸不红心不跳。但几位嘉宾还是很赞同方兴(@flashsky)的看法,他的观点之前已经在微博上阐述过。大致内容是“挖漏洞是高智力活动,漏洞信息是知识成果,但这种知识成果很难归宿产权,如果你不公开,无以鉴别拥有者先后和抄袭性保证权益;如果你公开,漏洞修复的代码知识产权在开发者手上,修复不用支付对价,而一旦修复漏洞价值就消失。厂商买漏洞是买成果还是产权?二者都是可交易的,厂商出1万奖励但要求发现者不公开漏洞细节,是买漏洞的产权了,厂商出1万奖励许可发现者公布漏洞细节,是买成果的知情权。这是单方的一个要约,对价是否合理,取决于售卖者自己的评估,只要没有强买强卖,都是可以接受的。”以上是之前方兴在微博上发表的观点,大部分是原话。沙龙上各嘉宾的看法我总结了一下大概是:“白帽子拥有漏洞成果的支配权,爱提交到哪里由白帽子自己决定。白帽子将漏洞直接提交给厂商,厂商理所应当给白帽子一定的报酬,至于报酬是不是合理不在讨论范围之内。但如果白帽子将漏洞提交给第三方平台,再由第三方将漏洞反馈给厂商。和厂商直接接口的是第三方平台,这是male to male的关系,和白帽子没有直接的关系,要谈报酬也是乌云平台和厂商之间谈,是否给报酬要看乌云和厂商之间的协议。而厂商加入乌云平台时并没有关于支付报酬的相关条约规定,所以厂商如果在正确评价和反馈漏洞的条件下不给白帽子额外的奖励也是符合逻辑的。”厂商可以根据自己的情况给白帽子发放礼物。这事之后我与阿里的同学了解过,在自建平台之前,他们是根据漏洞的情况给白帽子发放了不少礼物的。

  我认为关于给不给礼物的问题各方不必太纠结。目前乌云上给白帽子发礼物厂商也不是很多,而大部分提交漏洞到乌云平台的白帽子也主要不是冲着礼物去的,厂商平台混点KPI也不容易。不过从另外一个角度去看,不管是通过什么途径反馈漏洞给厂商,结果都是一样的,甚至有些漏洞在第三方平台反馈效果更好。白帽子付出了劳动,情理应获得一些回报。有很多根本厂商就联系不上,更不用谈礼物了。

  我强烈建议各厂商如果有条件,不管通过什么方式,给乌云平台提供一些赞助。乌云可重新合理支配资源,受益的白帽子范围更大,更利于乌云平台的发展。

  那天会场聊这个问题时有人在下说“京东的安全沙龙,在背后说乌云的事情,不是很好吧。”我想说,其实我还没有说完。漏洞平台的那些事,给不给礼物算不上什么大事情。#p#

  建漏洞平台的目的

  各厂商相继建立了自己的SRC,为了“抢生意”已经出现了好几次不和谐的事情。厂商为什么要建漏洞平台,有很多人说是为了不让漏洞信息公开。确实,在做任何事情,大家都希望自己能掌握主动权,任何一个公司都不希望自己公司的问题被曝光在其他网站上,被其他人掌握。但如果仅仅是为了这个目的而建平台,那就太肤浅了。引用黑哥的一条微博。“第3方漏洞平台不是*SRC的敌人,*SRC是不针对第3方漏洞平台而存在。”

  乌云平台是SRC的祖师爷,而TSRC无疑是甲方SRC的带头大哥,后建的大部分SRC多多少少都可以看见TSRC的影子。不管是无意还是有意的“模仿”,基本上各厂商SRC模样都差不多。再次引用黑哥的话“都被TSRC带到沟里去了”。或许初建漏洞报告平台,大家都会想到这种打怪升级的模式,有江湖英雄榜,有江湖门派排行榜。。。。。。但是SRC的长远发展不知道各位平台产品经理有没有好好的想过,还是目前这个样子就可以了?当然这些都不是老马我需要操心的事情了。

  也许我们仅仅看到SRC前台表面的东西,并不清楚每一个SRC后台的机制。但SRC平台的主要功能仅仅就是吸引白帽子直接提交漏洞,然后藏着掖着悄悄的处理吗?那何必要挂个应急响应中心这么大一个招牌。

  自建SRC的一大功能好处就是方便提交漏洞的白帽子与厂商及时沟通确认。上次我和小伟发现的那个来往漏洞,虽然小伟同学先提交到乌云平台,但是阿里的同学是先看到我这边直接提交到ASRC的漏洞信息,而且在次日上班之前就协助重现演示了这个漏洞。厂商一般都会优先处理提交到自己平台的漏洞。在与白帽子与厂商沟通渠道上,腾讯依靠自己的IM软件的优势算是做的最好的。尽管几次提交漏洞被忽略,通过QQ直接交涉还是被忽略。其他SRC如果有条件的,还是尽量提供即时通讯交流的条件,我相信更起步的SRC会很快跟上。

  SRC平台也不能仅仅是一个漏洞收集的平台,在平台建设上JSRC已经走在前面,从上次发布介绍的PPT里面看,漏洞和业务部门做了关联。我不知道它这个到底与业务及开发部门结合有多深,但这让提交的漏洞进入固化的一个事件处理流程是一个很好的方向。为了缩短乌云平台和SRC平台之间的距离,乌云和各SRC是否可以通过一些API,让厂商SRC集成调用,改善提交时间先后、重复提交的问题?

  前面说了一些SRC应该具有的一些基本功能,可能平台就可以比较好的运转了,但我总感觉各SRC都过于自私。虽然各厂商都会给一些积分及兑换的奖励,但是这相比漏洞本身的价值来说,奖励是微不足道的,礼品奖励对于有些人来说真的算不上什么。积分奖励政策之前有同学做过对比拍过砖,具体文字我也没有细看。但各位如果有兴趣,可以到各平台的去看看,一个非常严重的漏洞,顶破天了,看看给的积分能换什么东西,价值多少钱。所有的SRC平台这辈子都是欠白帽子的。其实SRC本身就不能算是花钱买漏洞的平台,这不是一个公平交易的平台。大家都可以理解礼品、预算等一系列问题,这个方面无法更多提高,但是可以在其他方面回馈白帽子。

  大前天晚上整理电脑文件时偶然翻出了黑客联盟网站的背景音乐,听的我汹涌澎湃。感慨之余,我是非常想念那个时代互联网沟通交流的环境,提个问题都有一堆热心人来回答。厂商要想未来还有源源不断的白帽子给报告漏洞,就该花点精力搞个交流的平台。

  我建议各大平台为白帽子的研究和奉献买包烟。我看到有几个平台已经在做文章分享的事情了,但是力度还是不够,文章内容寥寥无几。靠厂商自己员工的分享内容也很有限,但可以提供平台让白帽子做分享。我希望有能力的平台可以付费(其实付费不付费并不重要)征集一些有价值的资料,可以是工具、文章、方案等。光挖漏洞,散兵游勇,没有什么沉淀,如果有个好平台,经历过那个时代的老家伙们应该都会来支持支持,漏洞真心是挖不动了。目前都有个rank指数,可以加个power指数。你会挖洞,我会拍砖。白帽子还得讲究文武双全,德智体全面发展。这方面乌云和TSRC又走在前面了(就在本文写到一半的时候,TSRC的实验室板块偷偷的发布了),乌云君应该在首页给某些子站加个链接。#p#

  漏洞提交与驳回

  前面说过白帽子有权利自由支配自己发现漏洞,想获得更多礼物就提交到官方SRC,无视就提交到乌云,通用的系统的漏洞可以卖360。我不是什么挖洞的大牛,提交次数比较少。不过即便有漏洞我也不想给厂商的带来太多其他负面影响,一般都直接提交到厂商平台。但是很多问题都给驳回了,虽然有些经过交涉和沟通最终确认了,但是还有一些不认可,特别有很多非技术的业务安全问题,不去深究到底是验证人员能力问题还是提的漏洞根本无影响。一方面我是希望厂商能更多的投入漏洞验证人员,合理分配每个人员验证负责的板块,另一方面也要加强内部与业务部门的沟通机制,不管是不是认可这个漏洞,都应该尽量白帽子的建议传达。

  那么被SRC驳回的漏洞,白帽子不服该怎么处理?上周我们看到一个乌云有个来往安全漏洞,标题写的很玄乎,“来往导致淘宝账号可被破解波及余额宝支付宝”(http://www.wooyun.org/bugs/wooyun-2013-041388),然后一时间某公司公关的同学就大肆宣扬“支付宝曝安全漏洞或因“来往”账号易被破解”(http://tech.qq.com/a/20131030/004029.htm)看2个的时间差,公关的同学很努力。我不知道这位FOX同学当时是出于什么情况搞这么个标题,也不知道出于什么情况提交到了ASRC,然后又提交乌云。即便被驳回也应该心平气和的对待,如果没有被驳回还是再等等,大公司如果部门跨的比较远,沟通起来会比较慢。这算是一个提交与驳回的经典列子。

  被驳回也分为两种,一种就是别人之前已经提交了,这个情有可原,如果他们能拿出证据,那各位白帽子就最好就此作罢吧。如果是不认可该漏洞而被驳回,那再提交到乌云反倒是可以帮助SRC推进这个漏洞的修复,只要有点问题,他们一般都不会公开。不过如果换作是我,我会礼让三分,驳回我会主动再去沟通交涉,还是驳回我可能不会再提交到乌云,如果确实是很明显的问题我直接写个文章公开得了。所有有些厂商要小心了,我可能随时发文章拍砖。俗话说的好:“我不装逼,他们会对我这么恭敬吗?”不过基本上被驳回的大多数都是中低危的漏洞。而且这些都是漏洞反馈过程比较细节的事情,我就不多操心了。

  关于漏洞提交的合法性,各平台我观察了一下,几乎没有一个漏洞平台在法律层面有明确的详细的授权和限制。也许是在乙方呆太多的原因,每次给客户做安全测试,都需要甲方的授权才会进行。双11如果搞些流量干天猫一天,然后说在做安全测试,你看妥吗?哪些可以测试,哪些不能测试应该有所规定。甚至授权测试反馈结果的方式都可以限制。

  甲方SRC这块的问题不算大,乌云平台这块问题比较多。我们经常可以看到有一些白帽子提交一些漏洞,然后渗透进入内网之类的,挖个漏洞需要上传真实的shell,进入内网转一圈吗?你看到别人家房门没有关,然后你就跑进去给熟睡的女主人拍了几张裸照,然后发到她的邮箱里面说,你家门没有关,你看这个照片就是证明,然后你还评论了一下,女主人的屁股还挺白。你让人家情以何堪?也许我这个比喻打的不是很恰当。

  乌云是一个第三方平台,只负责接收和转发漏洞,并不能对白帽子测试的行为负责。有兴趣可以看乌云的相关说明:http://www.wooyun.org/about都是说的使用乌云平台是的注意事项,提交漏洞前的事情和乌云没有关系,提交后如果不合适删除就可以了,如果造成甲方损失又不是乌云平台干的。最尖锐的问题,白帽子你测试的目标网站谁给你授权了?真出了问题,没有人给你担着。我相信大部分白帽子都是好孩子,但是不能排除部分人员想利用乌云平台给自己洗白白。我衷心希望乌云能正视这个问题,要好好引导你们的小伙伴,好好保护他们。

  不过白帽子也不需要太过于担心,只要行得正不怕影子歪。只要把握好尺度的,发现问题积及时沟通反馈,大部分人都不会去计较。这里提一下我的看法。我认为目前市面上的系统大体可以分为两类。一类是面向目标用户提供服务的,另外一类是面向系统自身管理提供服务的。对于这两类不同的系统测试的态度和反馈的方式应该有所不同。对于面向用户的系统,本身就是提供开放访问的。测试行为基本上与正常访问区别不大,只要不把系统搞挂掉。而且发现的问题往往都是直接影响所有用户的安全问题。基本上上可以大胆的测试。而面为提供系统自身管理的服务,甲方并没有授权或邀请普通用户访问。以前访问老美的远程桌面,经常会弹出一个警告勿非授权访问的对话框,当然对我没有任何威慑。对于这类系统,我个人建议如果发现了漏洞,还是不要过于深挖,更不能篡改破坏系统,一定发现问题还是低调处理。这仅仅是我的个人的观点,赞同同学如果有兴趣可以把这两类系统再做一些细化,供那些茫然的同学参考。#p#

  漏洞信息公开与保护

  关于漏洞详细信息是否应该公开的话题大家已经争论很多次了。目前甲方SRC基本不公开任何漏洞信息,而乌云平台时间一到,所有的信息都公开。这两个极端,我觉得都很不妥。因此引出了2个问题,SRC平台漏洞公开和乌云平台漏洞信息保护。

  SRC平台有哪些漏洞可以公开,哪些漏洞应该公开?我个人认为至少漏洞的标题、漏洞类型、漏洞等级、rank等公开是不伤大雅的。这也可以给个位白帽子更多的展示,某种程度上可以调动白帽子的积极性。我们也可以看看黑哥到底有多牛,最擅长什么。同时也可以方便猎头定向挖人,方便白帽子就业嘛!

  另外对于有些高危的漏洞影响较大的,如果不能在服务端完全修复(特别是客户端漏洞),应该发布相应的安全公告,提醒用户及时处理,这个应该向微软好好学习。如果一味想用物质去收买,钱永远比不上漏洞实际的价值,有些白帽子完全不屑,要是被竞争对手拿去,造成的损失就无法估量了。我想最近几天搜狗的事情大家都看到了。

  说完厂商,我该说说乌云平台。他是国内漏洞报告平台、SRC的祖师爷,这是毋庸置疑的。他开创了一个时代,给白帽子一片新天地。经常有人问我想学习web安全怎么办,我说你去把乌云上公布的漏洞好好研究研究,都掌握了就很牛了。乌云平台的知名度非常高,得到很多人的认可。据说前段时间某公司招标书里要求乙方项目成员必须有在乌云top X的白帽子。可见乌云平台目前在甲乙方的影响力。但乌云平台的成长一直都是伴随着争议声。乌云的漏洞公开机制是平台最大的争议点之一。乌云给自己定义的是“自由平等开放的漏洞报告平台“,漏洞到一定条件就会自动公开,不管是什么单位,不受人为控制,都按照这个流程执行。乌云也因为某运营商的漏洞而被报复。一路跌跌撞撞,成长到现在的规模也不容易。但是有些问题还是不得不去面对。我看到主要问题是“没有人认领的漏洞的公开”,“涉及隐私信息或有后续影响漏洞信息的公开”。这些地方我个人认为乌云是必须要改进的地方。

  我举个具体点的例子。假如白帽子提交了一个sql注入漏洞,漏洞证明里面写的很详细,包括了数据库名称、字段名称。然后甲方反应很快漏洞修复了,然后公开了,漏洞截图信息也一起公开了。但是甲方往往不可能去修改数据库名称,字段。信息公开的结果带来的次生灾害等同于一次信息泄露的漏洞。还有乌云上提交比较多的dns域传送漏洞及其他信息泄露漏洞,这种漏洞证明公开的不就是持久的信息泄露吗?

  还有一些漏洞被白帽子发现并提交了,但是白帽子没有给出有价值的修复建议,或者白帽子也不知道怎么去修复,也许这个问题就没人能解决。假如有人在小区公告栏里面发了信息说:”XXX,你有病,不治就会死.”然后他还给你分析了一下,你觉得自己还真是有问题。然后你问他,那该怎么治呢。他说他就会找毛病不会治病,他也不知道该怎么办。然后过了一段时间以后全小区的人都知道你有病而且病的不轻。你说你是要感谢他呢还是恨他呢?

  这些对甲方来说是不公平的,与“自由平等开放”是违背的。不过老马是个负责的人。既然说到问题,我也给一些可实施的建议。就看乌云君有没有意愿和条件去改进了。

  我觉得乌云首先要做的是加强漏洞提交的规范,漏洞信息描述内容中不能包含涉及隐私的信息,关键的部分要马赛克处理。

  建立漏洞信息公开隐藏协商和仲裁机制,厂商可以提出对涉及隐私及其他可能因为公开而给业务带来次生灾害的信息部分进行不公开保护处理的要求。由白帽子、第三方机构、乌云管理员等进行投票仲裁。或者单独设置一个仅提交给厂商查看而不公开的部分,白帽子可以将涉及隐私的信息填写到这个区域。

  乌云还应该建立一个常见漏洞的修复建议知识库,对于一些漏洞的修复建议因为确实很常见,很多白帽子修复建议都写,“你懂得”之类的。有些甲方及漏洞处理人员没有白帽子水平那么高,一句你懂得让他们束手无策。如果建立知识库,完全可以根据漏洞类型在安全建议处自动加入参考建议的链接。

  以上这些我之前也私下里和剑心交流过,他表达过自己的难处,可能需要投入很大的研发工作量。所以为了平台的发展,希望各方热心人士都给点帮助。老马我只能为你呐喊助威,厂商和土豪们也多多少少给点资源吧。

  说到漏洞平台,我还得最后说一下360的裤带计划,虽然是小众,但也是土豪。上次京东沙龙讨论环节刺总还问了关于第三方机构收购漏洞问题的看法。方兴的看法是“如果把漏洞信息看成知识成果,买与卖没有什么问题,关键要看买了漏洞拿去干什么。挖漏洞没有罪,拿着漏洞去干非法的事情才有问题。很多安全产品厂商都会去购买漏洞信息,从而完善自己安全产品的防御能力,这是一种常见的做法。“ 第三方收购漏洞,如果处理不当却会带来很大影响。任何在官方发布补丁前无意还是有意的泄露漏洞细节都是不妥的。360也许是为了完善自己网站安全产品的防御能力收购0day漏洞。但是如果代替官方擅自发布补丁是可取的,发布补丁基本上就等同于公开漏洞。完全可以通过防护设备上安全策略做一些虚拟补丁提供防护。但是话说回来,已经公布的漏洞不管是漏洞数量以及黑客攻击频繁的程度都要比0day多的多,那些没有能力打补丁或者根本不知道有漏洞的网站更需要防护。所以我一直看不太明白360收购0day提高系统防护能力的意义有多大。当然如果有个第三方机构能统一收集漏洞,然后共享给各web安全防护厂商,那会很有意义。关于360裤带计划我接触较少,就不多说了。#p#

  结束语

  SRC与第三方平台有着太多的不和谐,常常上演土豪与小妇人的舞台剧。不管是SRC还是第三方平台,都是一个纯技术交流的平台,前几天媒体借助来往一个漏洞进行炒作,这样的事情已经发生过好几次了。技术交流的平台却成为了媒体公关的阵地,而我们这些单纯的小伙伴成了炮灰,这是我不愿意看到的。前段时间我写了一篇关于手机丢失给支付宝账户带来影响的文章,就有好几个记者联系到我,要采访我一些问题。我不知道对方是出于什么目的,我都给回绝了,我想说的话都已经在文章中表达,不必再来问我。我也希望白帽子们也能保持一颗有节操的心,维护圈子的健康。

  以上这些都是我个人的一些看法和期望,但是愿望是美好的,现实是残酷的。每个人都有自己的难处都有自己想法。每个平台的都有自己运营的策略,拿钱砸、玩暧昧、捡肥皂只要对白帽子有利,我们都应该点赞。我不在乎写的这个文章最后的反响有多大,只是希望各位平台负责人考虑考虑我的一些建议,或许可以有一些启发。多沟通交流是化解矛盾的基础,退一步海阔天空是解决问题的办法。如果各位有需求,我完全不介意组个局,让各大平台坐在一起面对面的沟通。

  关于漏洞披露以及SRC平台建设,黑哥、鹰总等大佬之前已经发过多篇文章,各位有兴趣也去看看。

  负责的安全漏洞披露过程

  http://hi.baidu.com/hi_heige/item/a12774dacb1a721dd68ed05b

  给TSRC等甲方平台建设的一些建议

  http://hi.baidu.com/hi_heige/item/937357b12bed3aa1ebba9316

  再谈企业漏洞收集平台建设

  http://hi.baidu.com/hi_heige/item/b619f44cc11996af61d7b9dd

  浅谈企业漏洞收集平台建设

  http://www.freebuf.com/articles/others-articles/8963.html

责任编辑:吴玮 来源: FreebuF
相关推荐

2015-02-27 15:14:05

2013-10-14 14:15:21

程序员读书

2018-09-29 15:59:18

APPiOS优化

2009-08-05 09:37:11

云计算CIO

2020-11-05 10:57:47

云计算多云公有云

2015-11-30 14:10:49

大无线eLTE华为

2009-10-20 14:10:00

CCIE考试

2022-05-11 07:17:29

MySQLAnsible运维

2015-09-15 09:12:04

程序媛Google特殊奖励

2011-05-27 11:21:58

打印机技巧

2015-02-09 13:48:12

2019-08-08 17:14:31

5G手机华为三星

2017-10-12 12:13:09

设计师搜索功能搜索框

2012-03-31 11:05:00

水冷服务器液体刀片服务器

2016-04-10 15:35:18

2013-05-23 11:22:04

Android开发者UI设计Android设计

2019-01-24 10:18:25

机器学习深度学习图像处理

2020-05-26 15:16:44

5G两会全息

2009-03-25 19:05:24

四核服务器AMD
点赞
收藏

51CTO技术栈公众号