網(wǎng)絡(luò)信息安全之GitHub敏感信息泄露監(jiān)控-徐慶臣（黑客洗白者）
結(jié)合管理和技術(shù)手段杜絕GitHub敏感信息泄露問題，做到近實時監(jiān)控預(yù)警。分享開發(fā)GitHub敏感信息監(jiān)控過程中的特征采集、最佳告警響應(yīng)方式、誤報規(guī)則類型、漏報處理思路以及整體GitHub敏感信息泄露的現(xiàn)狀等等一些經(jīng)驗。
漏洞背景
GitHub作為開源代碼平臺，給程序員提供了交流學(xué)習(xí)的地方，提供了很多便利，但如果使用不當(dāng)，比如將包含了賬號密碼、密鑰等配置文件的代碼上傳了，導(dǎo)致攻擊者能發(fā)現(xiàn)并進一步利用這些泄露的信息，就是一個典型的GitHub敏感信息泄露漏洞。
解決思路
制度為輔
新入職員工往往這方面的意識較為薄弱，通過對新入職員工的專項安全培訓(xùn)，著重普及下在工作和生活中因為意識不足所導(dǎo)致的一些安全問題及應(yīng)對方法。讓新人對此有個基礎(chǔ)的意識，知道上傳GitHub代碼會有風(fēng)險，并將其加入到內(nèi)部的信息安全守則或紅線中，有據(jù)可依也有據(jù)可罰，對惡意上傳者起到一定的威懾，對于老員工也有一定的意識提升。進一步可以細化GitHub開源規(guī)范，讓開源流程化，也讓安全團隊介入其中進行評估。
技術(shù)為主
內(nèi)外網(wǎng)隔離
從代碼泄露最終的結(jié)果上看，直接影響的是外網(wǎng)可訪問的接口被利用，比如郵箱賬號密碼泄露的話會被攻擊者所登陸并拿到郵件信息、組織架構(gòu)及花名冊等；數(shù)據(jù)庫使用外網(wǎng)IP會導(dǎo)致數(shù)據(jù)被盜取等。 所以可以先從內(nèi)外網(wǎng)隔離來做，規(guī)范代碼中統(tǒng)一使用內(nèi)部接口、內(nèi)部IP，迫不得已的外部接口可以通過增加二次驗證、限制訪問源IP等策略進行加固。 這樣這樣泄露出去的代碼無法對企業(yè)造成直接影響，至于代碼本身存在的一些漏洞就需要依靠白盒代碼審計日積月累了。
?
實時監(jiān)控
經(jīng)過內(nèi)外網(wǎng)隔離后，代碼雖然無法造成直接的危害，但畢竟是公司資產(chǎn)，涉及公司聲譽，還是需要進一步解決。所以實時的監(jiān)控很有必要，我們?nèi)绻茉诘谝粫r間內(nèi)發(fā)現(xiàn)泄露的信息并找到對應(yīng)人及時刪除，造成的影響將會被降到最低。需要再次強調(diào)的是，實時是整個技術(shù)最核心指標。
?
技術(shù)方案
監(jiān)控核心思路可以通過GitHub搜索代碼中的特征來發(fā)現(xiàn)泄露的信息。
?
同類型項目Hawkeye使用的是代理爬取的方式進行定期搜索，但代理爬取的方式有諸多弊端，最大缺點是爬取的時候GitHub是一個黑盒，你不知道他是什么頻率限制規(guī)則，也不知道他什么時候改變規(guī)則，一切都存在不確定性。
?
雖然GitHub API也有頻率限制，但他的文檔中明確了頻率限制的策略，我們可以通過做好頻率控制避免觸發(fā)GitHub API限制規(guī)則。
?
對于絕大多數(shù)的企業(yè)，做好以下兩條就不會被觸發(fā)GitHub頻率限制規(guī)則。目前已經(jīng)試驗過的2000條掃描規(guī)則15個token在多種時間頻率下未發(fā)現(xiàn)問題。
?
將掃描規(guī)則按優(yōu)先級拆分成不同類型并以不同的速度去運行
注冊多個賬號申請多個token
?
最佳實踐
收集特征
那如何找到我們的特征呢，GitHub作為一個開源代碼托管平臺，代碼首當(dāng)其中，但也會有人將GitHub僅當(dāng)做版本控制系統(tǒng)來管理自己的文檔、資料。這類資料都有一個共同特征，里面包含企業(yè)的專屬特征：代碼中接口的調(diào)用包含內(nèi)部API地址、代碼頭部包含企業(yè)的Copyright信息、代碼包名包含企業(yè)的主域名等。
?
常見幾類特征?
內(nèi)部域名，內(nèi)網(wǎng)接口使用的域名、測試域名等，比如
mogujie.org外部域名，對外使用的域名，可以選一些風(fēng)險較高的，比如
mail.mogujie.com代碼版權(quán)，代碼頭部注釋中的版權(quán)聲明，比如
Copyright 2018 Meili-Inc. All Rights Reserved主機域名，服務(wù)器HOST域名，比如
goods.db.mogujie.host代碼包名，Java代碼包名，比如
com.mogujie.goods
?
如何找到其它企業(yè)內(nèi)部特征？
可以從域名特征入手，最簡單的通過一些特定關(guān)鍵詞:
corpdevincpretestcopyright
?
搜索GitHub代碼，根據(jù)代碼人工確認是否是誤報。找到某個確定是該企業(yè)的工程后，分析改工程其它類型的特征即可，對于下屬企業(yè)可以通過域名注冊人反查并循環(huán)前面的邏輯。 比如要找蘑菇街的內(nèi)部特征，可以通過在GitHub中搜索mogujie dev即可找到屬于蘑菇街的工程，繼而我們再從這類工程中找到真正的內(nèi)部域名和其它類型特征。
?
實踐例子
聲明：通過本篇內(nèi)容任何人都可以輕易找到任何公司的內(nèi)部特征，例子只為提升理解，若覺得侵權(quán)請聯(lián)系我刪除。 僅列取部分典型廠商的典型內(nèi)部特征作為講解。
?
百度（http://BAIDU.COM）：公網(wǎng)域名和內(nèi)網(wǎng)域名混用
yx01.baidu.comvm.baidu.comepc.baidu.comiwm.namexdb.all.serv阿里巴巴（http://ALIBABA.COM）：INC和.NET是最喜歡用作內(nèi)網(wǎng)域名
alibaba-inc.comaliyun-inc.comalibaba-inc.vipserveralibaba.netalipay.netfliggy.nettaobao.net騰訊(http://TENCENT.COM)：用了一個不是自己的域名
tapd.oa.comproxy.tencent.comproxy.oa.comnpm.oa.comtencentdb.comtencent.com京東（http://JD.COM）：特征獨一無二，比較準
jd.local360（http://360.CN）：特征獨一無二，比較準
qihoo.netBilibili（http://BILIBILI.COM）：CO域名和COM域名在搜索分詞容易出問題，需要注意
bilibili.co餓了么(http://ELE.ME)：特征獨一無二，比較準
elenet.me陌陌（http://IMMOMO.COM）：特征獨一無二，比較準
wemomo.com搜狐（http://sohu.com）：喜歡INC
sohu-inc.comsohuno.comcyou-inc.com途牛（http://TUNIU.COM）：喜歡ORG
tuniu.orgtuniu-cie.orgtunie-sit.org去哪兒（http://QUNAR.COM）：和百度類似，但用二級域來區(qū)分，比百度清楚
dev.qunar.compackage.qunar.comtest.qunar.combeta.qunar.comlocal.qunar.comcorp.qunar.com攜程（http://CTRIP.COM）：：特征獨一無二，比較準
ctripqa.comctripcorp.com愛奇藝（http://IQIYI.COM）：愛奇藝是區(qū)分的最好的，數(shù)據(jù)庫、應(yīng)用間調(diào)用、人訪問的都區(qū)分開了
qiyi.domainqiyi.virtualqiyi.db
?
了解搜索特性有利于特征收集
像其它搜索引擎一樣，GitHub搜索會對內(nèi)容進行分詞，所以搜索的時候應(yīng)該以單詞為單位，如果有詞組可以拆開用空格拼接起來搜索。
如果遇到一些比較容易出現(xiàn)誤報的詞，可以使用雙引號括起來就行強制搜索，比如
"mi.com"。特殊字符不會被索引到。
使用時間倒序的方式，先處理最近上傳的。
?
告警與響應(yīng)
在告警這塊早期為了告警速度與響應(yīng)速度，選擇了郵件的方式，在后續(xù)的實踐過程中我們也嘗試想改成管理后臺、Slack等形式，但綜合評估后覺得郵件是最佳實踐。
?
漏洞告警實踐
調(diào)快郵件客戶端收信的輪詢時間，第一時間獲取漏洞信息
將所有客戶端調(diào)整為imap模式，這樣能保證我們在電腦上操作的漏洞結(jié)果在手機上狀態(tài)能同步過來
郵件發(fā)送頻率限制可以通過配置多個郵箱甚至是多個不同運營商的郵箱解決
?
漏洞響應(yīng)實踐
使用郵件來管理這類漏洞，證實存在或有研究價值的漏洞可以打上不同顏色星標，繼而提交給對應(yīng)廠商或發(fā)送給應(yīng)急響應(yīng)小組。而證實誤報的可以刪除到垃圾桶，定期通過優(yōu)化代碼和規(guī)則解決；
?
誤報與漏報
誤報
我們目前積累的常見的誤報規(guī)則
GitHub博客，比如
github.io github.comAndroid項目（甲方自家監(jiān)測建議去掉此條規(guī)則），比如
app/src/main爬蟲，比如
crawler spider scrapy 爬蟲插件，比如
surge adblock .pacLink，比如
"<a href <iframe src ]("其它，比如
linux_command_set domains jquery sdk linux contact readme hosts authors .html .apk
?
漏報?
我們可以不斷補充規(guī)則來覆蓋盡可能多的特征場景，但還是避免不了漏報，畢竟不是所有的項目都遵守或符合我們的特征。如果企業(yè)安全團隊推動力比較強，可以考慮給所有項目都加上一個文件，內(nèi)容可以是一個索引標記，之后就根據(jù)這些索引標記輸出為監(jiān)控規(guī)則來實現(xiàn)無漏報。
?
漏洞處理
通過GSIL發(fā)現(xiàn)泄露的信息后，可以通過以下方式處理。
?
找得到作者
先通過以下方法找到作者
查看Commits記錄，看其中作者名字和郵箱（往往大家在Git Config的時候會全局配置自己的提交用戶名和郵箱）
查看作者GitHub個人主頁，根據(jù)Nickname/Username/Email等關(guān)聯(lián)出上傳人的真實身份
查看項目類型，比如是前端項目可以找到前端負責(zé)人，讓其在團隊內(nèi)部詢問下
查看項目代碼中的蛛絲馬跡，比如注釋中會有編寫人姓名和郵箱、通過配置信息關(guān)聯(lián)出申請人
?
找到作者后，聯(lián)系其先不要刪除，保留項目Traffic頁面的截圖以作為風(fēng)險判斷依據(jù)，再刪除項目。最后根據(jù)項目泄露相關(guān)信息進行整改，比如泄露了項目配置信息（賬號密碼、密鑰等）則進行更改。
?
找不到作者
找不到作者先整改泄露的信息，優(yōu)先級由外而內(nèi)，把危害降到最低。 再讓公司法務(wù)或信息安全團隊通過GitHub DCMA（數(shù)字千年版權(quán)法案處理規(guī)則）向GitHub發(fā)送郵件進行處理，一般三天左右會有答復(fù)。
?
幾個注意的點
郵件格式和注意事項在GitHub DCMA處理規(guī)則中有詳細說明，請嚴格按照說明編寫
根據(jù)泄露的信息提供相對應(yīng)的證據(jù)，比如泄露域名相關(guān)信息可提供域名證書等能證明所有權(quán)相關(guān)證據(jù)
希望GitHub官網(wǎng)采取的操作，一般是刪除對應(yīng)GitHub倉庫
提供公司的聯(lián)系方式
簽名等
?
漏洞現(xiàn)狀
為了優(yōu)化速度及誤報問題，我們將國內(nèi)的漏洞盒子、補天及烏云歷史上的廠商都加入到監(jiān)控列表中進行測試，我們僅拿著這一類漏洞刷某漏洞平臺全部廠商進了排名榜前十，漏洞報告太多導(dǎo)致觸發(fā)郵箱頻率限制規(guī)則被ban了，由此可見這類問題在國內(nèi)的多么普遍。
?
有SRC（漏洞應(yīng)急響應(yīng)中心）的廠商我們都會盡量將漏洞反饋過去，每月單漏洞收入超過￥10k+，但大多數(shù)廠商是沒有對外接收漏洞的渠道，為避免這類漏洞被人惡意利用，我們開源了整個項目，所有廠商可以免費使用，移步https://github.com/FeeiCN/GSIL，據(jù)了解國內(nèi)已有數(shù)十家大型互聯(lián)網(wǎng)公司、證券公司、銀行等在使用GSIL，包括蘑菇街、美麗說、小店、大搜車、農(nóng)信銀行、泰康保險、傳化集團、投哪兒網(wǎng)、廣發(fā)證券等。
?
除了針對各個企業(yè)的特征外，我們還發(fā)現(xiàn)了一些通用特征，這些特征往往造成的影響更大，比如針對企業(yè)郵箱、私密文檔、公私密鑰、通用連接組件的規(guī)則所捕獲的信息也經(jīng)常會涉及到各家企業(yè)，比如之前某家云廠商員工將某個系統(tǒng)上傳到GitHub，其中包含了可通過公開API調(diào)用的公私密鑰，可控制其數(shù)萬臺服務(wù)器全部權(quán)限。
?
而且越來越多的線索表明這類漏洞越來越多的被惡意利用，比如之前曾發(fā)現(xiàn)黑灰產(chǎn)通過大批量監(jiān)控收集所有泄露的AppId和AppSecret來控制微信公眾號進一步達到盈利目的、通過泄露的SSH/Redis賬號密碼獲取主機權(quán)限并挖礦等。
?
只有將問題充分暴露出來，大家才會正視并解決問題。
