根據(jù)coinmarketcap統(tǒng)計,2019年6月,區(qū)塊鏈加密貨幣的市值就已經(jīng)突破了2500億美元,2018年初更是一度突破8000億美元,已經(jīng)在市場流通的加密貨貨幣高達2000多種,再考慮到未反映在其中的交易所、錢包、挖礦、媒體等相關產(chǎn)業(yè),整個行業(yè)已初具規(guī)模,且仍有較大的成長速度和成長空間。
另一方面,區(qū)塊鏈行業(yè)仍處于初級發(fā)展階段,技術和理念的不成熟造成安全問題頻出,加之區(qū)塊鏈產(chǎn)品多具有金融屬性,鏈上資產(chǎn)在很多國家又不受法律保護的,且去中心化屬性導致資產(chǎn)難以控制和追索,使得區(qū)塊鏈項目成為黑客理想的攻擊目標。
據(jù)統(tǒng)計,區(qū)塊鏈相關的安全事件造成的損失一直處于上升的趨勢。 BCSEC的統(tǒng)計數(shù)據(jù)顯示,2018年區(qū)塊鏈重大安全事件數(shù)量達到創(chuàng)紀錄的139起,造成的經(jīng)濟損失為 22.38億美元,歷史最高;2019年上半年重大安全事件已達68起,造成的經(jīng)濟損失為6.84億美金;攻擊手段層出不窮,難以招架。
因此,區(qū)塊鏈安全變得尤為重要,與區(qū)塊鏈行業(yè)同步發(fā)展刻不容緩。
然而,與區(qū)塊鏈安全的嚴峻形勢相對應的,是區(qū)塊鏈安全公司和安全研究人員匱乏的現(xiàn)狀。在這種情況下,區(qū)塊鏈的發(fā)展是沒有保障的,尤其考慮到當前的區(qū)塊鏈企業(yè)多為初創(chuàng)企業(yè)、中小企業(yè),資金實力有限,難以聘請到專業(yè)的安全研究人員對自己的區(qū)塊鏈產(chǎn)品進行持續(xù)的安全測試。
在這樣的條件下,安全眾測是理想的解決方案,可以更加靈活地對區(qū)塊鏈安全人員進行動態(tài)分配,更好地支撐區(qū)塊鏈的發(fā)展。區(qū)塊鏈企業(yè)可以對安全測試進行懸賞,激勵白帽子自發(fā)去尋找區(qū)塊鏈的潛在漏洞,依靠白帽子的力量發(fā)現(xiàn)安全問題并及時排除。然而,這一模式的問題在于:廠商和白帽子如何建立信任關系。
而信任問題,正可以通過區(qū)塊鏈技術來彌補。通過區(qū)塊鏈技術搭建可信任的漏洞平臺,再反過來為區(qū)塊鏈安全提供保障,彼此相輔相成,可以真正做到區(qū)塊鏈與區(qū)塊鏈安全同步發(fā)展。
基于這樣的理念,為了更好的保護區(qū)塊鏈生態(tài)安全,BCSEC 和 PeckShield 共同發(fā)起建立了 DVP——Decentralized Vulnerability Platform,去中心化漏洞懸賞平臺。
DVP 協(xié)議和公鏈
DVP 協(xié)議通過創(chuàng)建可伸縮低成本的系統(tǒng),來解決區(qū)塊鏈項目的安全問題。隨著時間的推移,我們希望每一個區(qū)塊鏈項目都能使用 DVP 協(xié)議來執(zhí)行安全審計,因為在區(qū)塊鏈項目中安全是最基本的要求。
協(xié)議包含主要的懸賞支付系統(tǒng):
一個自動的賞金支付系統(tǒng),用于獎勵查找漏洞的人工參與者,建立白帽子與項目方的一個自動懸賞支付系統(tǒng)。
DVP 協(xié)議依賴于參與者們的分布式網(wǎng)絡,來減輕壞角色的作用,提供所需的算力,還有提供治理。每一個參與者都使用 DVP 協(xié)議積分來支付、接收,或者提高驗證服務。
1. 參與者
白帽子
通過發(fā)現(xiàn)漏洞獲得積分作為賞金,通過平臺查看懸賞任務,發(fā)現(xiàn)漏洞后通過平臺,或者客戶端將報告用廠商的公鑰進行內(nèi)容加密提交。
廠商任務發(fā)布者
廠商生成后需要等待治理結點仲裁機構進行廠商身份確認,完成后將由任務發(fā)起方,發(fā)布任務,填入懸賞標準,以及測試范圍信息,并且存入,將生成私鑰,公鑰信息,公鑰用于提交者加密提交漏洞信息,私鑰用于查看安全測試報告內(nèi)容,對于未注冊的廠商漏洞將自動發(fā)送到治理結點仲裁結構查閱。
仲裁機構(治理結點)
運行 DVP 驗證節(jié)進行仲裁判定,并且用于所有區(qū)塊的記賬寫入數(shù)據(jù)操作,然后進行廣播,最終并獲得積分激勵,該節(jié)點需要是具備安全驗證能力的節(jié)點(可以為個人,團隊,組織,或者公司)最終會在漏洞的提交者與項目廠商之間產(chǎn)生爭議的時候,由治理結點進行投票裁定結果 。
普通節(jié)點
任何一個客戶端都是一個普通節(jié)點,普通節(jié)點作為 DVP 的分布式數(shù)據(jù)存儲,但沒有寫入權限,最終區(qū)塊內(nèi)容由仲裁機構治理結點維護寫入。
2. 區(qū)塊信息結構
寫入操作最終由治理結點進行寫入記賬操作,內(nèi)容只能新增,不能刪除修改。整個信息結構將由仲裁機構維護(治理結點)
3. 懸賞合約
生成 DVP 的廠商賬號,在項目設置中填寫測試目標和漏洞獎金等信息,提交后等待治理結點審核廠商身份,完成廠商賬號押金充值,即可開始公開懸賞項目。
懸賞合約將通過在線的 B/S 客戶端,或者 C/S 客戶端,移動端等進行任務發(fā)布,內(nèi)容對每個等級的漏洞懸賞定義,例如:高危 1000$, 中危 500$,低危 200$;項目審計的資產(chǎn)范圍,可以是錢包、公鏈項目,或者某個系統(tǒng)等;漏洞定義將對每個等級的情況進行說明;
4. 架構圖
普通節(jié)點:用于接受治理結點的廣播的區(qū)塊信息存儲記錄,保證整個網(wǎng)絡的數(shù)據(jù)去中心化。
治理結點:用于廣播記賬計算全網(wǎng)的交易,懸賞,合約等信息記錄,將由擁有一定安全能力的安全廠商運營
DVP 去中心化平臺
DVP 公鏈發(fā)布后,搭建在線的漏洞信息展現(xiàn)平臺(區(qū)塊信息瀏覽器)
在線展現(xiàn)平臺主要用于提交漏洞,廠商注冊生成,白帽子注冊生成,包含廠商列表,廠商信息頁,排行榜頁面,公告頁面,獎勵計劃說明頁面,漏洞說明頁面,但是整個平臺的數(shù)據(jù)是去中心化的,只是一個在線的客戶端 DVP 瀏覽器,用于展現(xiàn)區(qū)塊中的數(shù)據(jù)。同時形成一個安全生態(tài)社區(qū),聚集更多的白帽子與項目方的入駐。
漏洞列表
顯示漏洞的列表,其中包含,漏洞標題,漏洞提交公鑰地址,漏洞對應的廠商,漏洞獎金,漏洞發(fā)布時間。
提交漏洞
白帽子提交漏洞的入口,白帽子需要提交漏洞標題,影響廠商,官方網(wǎng)站,類型,危害,自評分,自評等級,簡介,詳情,驗證代碼(PoC),修復建議。
廠商發(fā)布懸賞合約
廠商填入安全審計的資產(chǎn)范圍,懸賞標準后,直接將押金存入合約,懸賞合約將通過治理結點進行廣播寫入全網(wǎng)區(qū)塊。
自定義活動
廠商項目方可以自定義時間段,節(jié)假日發(fā)起特定時間段的懸賞活動,除了正規(guī)的懸賞合約信息外指定合約有效期。
注冊廠商
填入廠商聯(lián)系郵箱,廠商官方主頁,介紹信息,然后轉(zhuǎn)入相應的押金,注冊完成后會自動生成相關私鑰,公鑰,作為廠商后續(xù)登入的唯一憑證。公鑰也是錢包地址
注冊白帽子
填入個人介紹,昵稱,注冊完成后 生成相關私鑰,公鑰。作為廠商后續(xù)登入的唯一憑證。公鑰也是錢包地址
登陸
通過私鑰即可登入自己的個人頁面。
廠商列表
廠商列表部分則主要顯示廠商的名字,廠商的網(wǎng)站地址,廠商注冊時間。
廠商信息頁
除顯示廠商信息外,還顯示廠商介紹,廠商發(fā)放獎金情況,廠商個人信息管理,以及廠商對應的漏洞提交情況。
排行榜
排行榜分為白帽子積分排行榜,廠商獎金方法排名。白帽子排行榜根據(jù)白帽子提交漏洞所得積分進行排名,排名為季度排名,展現(xiàn)當季度的所有漏洞信息合集。
每個季度在 DVP 協(xié)議中將自動按照排名選擇 top10 的白帽子進行積分獎勵,以保證整個社區(qū)的活躍度積極性。
公共頁面
廠商發(fā)布懸賞合約顯示平臺的最新的動態(tài),新聞。
獎勵計劃說明
說明漏洞的懸賞規(guī)則。
漏洞說明頁面
漏洞對應的危害等級,積分,獎金計算規(guī)則說明。
1. DVP 流程示例
(1)任何一家區(qū)塊鏈廠商將可以通過我們的官方平臺(在線的客戶端)提交發(fā)布懸賞標準,測試范圍(可以是合約,也可以是任何公鏈項目等),提交后存入相應倍數(shù)的積分到獎金池,完成操作后將自動為該懸賞事務生成公鑰(加密漏洞內(nèi)容),私鑰(廠商查看安全報告內(nèi)容)
(2)漏洞提交者同時也可以通過我們的官方平臺(在線客戶端)實時查看目前在區(qū)塊里發(fā)布寫入的懸賞事務,選擇自己要參與的,當發(fā)現(xiàn)漏洞后可以通過該廠商公布的公鑰進行加密漏洞內(nèi)容,然后發(fā)送,廠商則可以在區(qū)塊獲取跟自己有關的漏洞信息,然后進行解密查看,當對漏洞進行確認后,事務會自動對該漏洞的提交者進行發(fā)布的標準獎勵(根據(jù)漏洞的高中低等級確認)。
(3)當廠商對漏洞產(chǎn)生任何疑問的時候,廠商可以將該漏洞事務重新寫入?yún)^(qū)塊發(fā)送給仲裁機構(治理結點),這時候由仲裁機構(治理結點)進行仲裁,然后進行漏洞判斷,仲裁結果以驗證者投票決定結果,超過 50%的票數(shù)將決定漏洞的裁定,然后將狀態(tài)廣播到網(wǎng)絡。
(4)漏洞被提交寫入?yún)^(qū)塊后,超過 24 小時未被處理,將自動進行消息推送給項目方提醒。
2. 提交的漏洞報告要求:
漏洞標題
標題描述:標題可基本概括漏洞情況,描述語言缺乏規(guī)范性。如“一處注入漏洞”“另外一處注入”“網(wǎng)站某處存在越權”
基本信息
漏洞類型:填寫信息準確無誤
漏洞等級:填寫信息準確無誤
廠商信息:填寫信息準確無誤,
漏洞描述
漏洞簡述:包含漏洞概述
漏洞正文
漏洞復現(xiàn)過程:復現(xiàn)過程基本完整,個別地方描述不清或缺少數(shù)據(jù),對漏洞評估、復現(xiàn)有一定影響
分步驟圖文描述:關鍵測試步驟完整,但復現(xiàn)步驟缺失,對漏洞復現(xiàn)有一定影響。如直接粘貼出漏洞利用請求包,但缺乏測試步驟如何獲取此請求包,需要二次溝通方才可復現(xiàn)
漏洞危害證明:漏洞危害證明基本完整
修復建議
漏洞修復建議:修復建議基本無誤,但過于簡單,無實際參考意義。如“控制權限”,“過濾參數(shù)”,“校驗身份”
3. 漏洞信息
漏洞報告整個信息體由公鑰進行加密,只有廠商可以使用私鑰進行解密
1. 廠商未確認
當漏洞報告被提交寫入?yún)^(qū)塊后,漏洞報告會自動加蓋時間戳,超過 24 小時未處理,將自動觸發(fā)聯(lián)系廠商動作。在沒被任何人確認的情況下將顯示“廠商未確認”。
2. 廠商確認完成
廠商可以查看自己懸賞合約的相關漏洞信息,通過私鑰能解密得到報告內(nèi)容詳情,然后進行判斷,當無誤時,懸賞動作將自動打入該漏洞提交者的地址。
3. 爭議
爭議是指目前提交的漏洞信息,廠商不予認同,存在疑問,這時候需要廠商發(fā)送解密過后的漏洞細節(jié)報告給仲裁節(jié)點,進行投票仲裁,最終結果以投票數(shù)》50%的結論進行裁定。
4. 公開
在廠商主導確認下可以發(fā)布漏洞公開內(nèi)容,進行披露漏洞細節(jié),這些內(nèi)容將被寫入到區(qū)塊中,供大家查看。
4. 廠商審核漏洞
廠商發(fā)布懸賞合約后,能通過客戶端+私鑰登入 DVP 主網(wǎng),查看提交的漏洞細節(jié),當漏洞被確認后,將自動完成轉(zhuǎn)賬懸賞操作,當出現(xiàn)異議時:
漏洞重復:按照提交時間以提交時間最早的為準,后面提交的廠商有權拒絕,發(fā)起仲裁。
漏洞無效:廠商認為該漏洞無效,無法復現(xiàn),或者無危害,這時候廠商將細節(jié)解密重新加密發(fā)送給仲裁節(jié)點進行投票仲裁。根據(jù)仲裁結果,如果確定有效自動轉(zhuǎn)入提交者的錢包地址,非有效漏洞,將直接廣播全網(wǎng)告知該漏洞無效。
5. 業(yè)務獎勵
DVP 平臺將對每筆業(yè)務收取一定比例的礦工費(初始參數(shù)設置為 10%),形成獎勵池,用于獎勵回饋對 DVP 社區(qū)生態(tài)貢獻價值的廠商和白帽子(初始參數(shù)比例 3:7)。廠商和白帽子所貢獻的價值將按照一套規(guī)則透明的排名算法計算,算法細則請關注官方網(wǎng)站的披露。
優(yōu)勢
漏洞懸賞源起于美國,前有 Facebook,Google,微軟;后有 HackerOne,BugCrowd 等商業(yè)公司,通過白帽社區(qū)幫助企業(yè)發(fā)現(xiàn)安全漏洞。國內(nèi) 3BAT 等一線互聯(lián)網(wǎng)廠商均有 SRC(安全應急響應中心)進行漏洞懸賞計劃,他們通過這種方式使外部漏洞數(shù)量直線下降至可控范圍內(nèi),為自己長線的安全體系建設贏得時間和方向指引。
但是目前市面上還沒有一個去中心化的漏洞懸賞平臺。所有的懸賞任務,都是通過中心化的平臺,或者郵件等方式溝通,低效且耗時,限制了懸賞活動的使用范圍,并且它要求企業(yè)雇用專門的人員審核所有的懸賞任務,而提交者又不愿意過多的暴露自己的身份,以及聯(lián)系方式等個人隱私。而現(xiàn)有平臺都沒有解決這些問題, 市面上現(xiàn)有的 Bug Crowd 和 Hackerone 等其他網(wǎng)站,側重于傳統(tǒng)的網(wǎng)絡安全問題,且沒有提供去中心化的審查機制,而 DVP 的核心價值點就在于,隱私保護,以及匿名的設計,以及去中心化的審查機制來保障漏洞的保密性,公平性。
1. 完全的隱私保護
白帽子不用體現(xiàn)真實身份
目前其他的懸賞平臺都需要提交者提供私人信息,包括領取獎勵的信息,提交漏洞的安全人員多數(shù)不愿意透露自己的個人信息,很多白帽子因為不愿意跟廠商溝通,以及留下個人信息等原因放棄提交漏洞,而 DVP 的匿名性等特點能有效的保護白帽子個人隱私,所以能更好的吸引更多的白帽子參與。
企業(yè)的漏洞只有自身能夠看到
提交漏洞只與廠商進行結果確認,保證漏洞的保密性,當出現(xiàn)爭議時候,由過個治理結點投票決定保證公正性,目前現(xiàn)有的漏洞平臺都是基于中心化的平臺,所以平臺方是能查看到所有項目方的漏洞信息,而廠商項目方并不想把這些信息給平臺方查看,歷史上就有因為中心平臺方的問題導致漏洞細節(jié)被暴露,最終導致漏洞細節(jié)被二次利用,使廠商遭受損失,而目前 DVP 的對稱加密方案結合公鏈的方式讓漏洞細節(jié)只有廠商能查看,且最終的公開與否的權利都在廠商手上,有效的保證了漏洞細節(jié)的保密性。
2. 匿名設計,公平性
懸賞獎勵交易匿名記賬,對于獎勵無需任何個人信息,且任何的獎勵懸賞記錄都能公開透明,保證公平公正性。每筆懸賞都有歷史的記錄,能完整的溯源獎勵記錄。
3. 去中心化的審查機制
所有的審核標準都由廠商來確認,傳統(tǒng)的漏洞平臺,通常都由中心平臺來進行審核驗證漏洞,中心平臺擁有絕對的控制權,對于漏洞有疑問的地方,白帽子或者廠商是沒有話語權的,而 DVP 以去中心化的機制進行審核,廠商在出現(xiàn)異議的時候,由仲裁方(治理結點)進行仲裁投票方式審核該漏洞保證絕對的公平性。
來源;區(qū)塊網(wǎng)
評論
查看更多