最近幾天金山和新浪又相繼推出了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推進這個漏洞的修復，只要有點問題，他們一般都不會公開。不過如果換作是我，我會禮讓三分，駁回我會主動再去溝通交涉，還是駁回我可能不會再提交到烏云，如果確實是很明顯的問題我直接寫個文章公開得了。所有有些廠商要小心了，我可能隨時發文章拍磚。俗話說的好：“我不裝逼，他們會對我這么恭敬嗎?”不過基本上被駁回的大多數都是中低危的漏洞。而且這些都是漏洞反饋過程比較細節的事情，我就不多操心了。

　　甲方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