建站
咨詢
售后
建站咨詢
新聞中心
本文不涉及常見的基于代碼關(guān)鍵字匹配的 GitHub 監(jiān)控。而是從 GitHub 的賬戶出發(fā)，通過人的關(guān)系來獲得一些代碼搜索不具有的優(yōu)勢。
創(chuàng)新互聯(lián)專業(yè)提供雅安機(jī)房托管服務(wù)，為用戶提供五星數(shù)據(jù)中心、電信、雙線接入解決方案，用戶可自行在線購買雅安機(jī)房托管服務(wù)，并享受7*24小時(shí)金牌售后服務(wù)。
疑云乍現(xiàn)
問題要從一個(gè)晴朗而又嫵媚的下午說起，我喝著娃哈哈，看著自認(rèn)為世界上***雅的代碼，然而當(dāng)我上傳到 GitHub 私有倉庫的時(shí)候，嘴角的一抹笑意停留在 10 秒 24 毫秒前的陽光下，因?yàn)槲野l(fā)現(xiàn)上傳顯示的用戶并非是我，換句話說，commit 頁面并未顯示我?guī)洑獾念^像，我的職業(yè)第二敏感性告訴我，這個(gè)事情有點(diǎn)蹊蹺：
a.這個(gè)人是誰？
b.我的機(jī)器被劫持了？
c.我的賬戶被黑了？
d.GitHub 出問題了？
e.某些未知原因？
a 問題是比較好回答的，點(diǎn)進(jìn)去發(fā)現(xiàn)是一個(gè)非常正常的用戶，我總不至于被黑了，不行，職業(yè)尊嚴(yán)讓我強(qiáng)制排除了這個(gè)選項(xiàng)，但是我比較關(guān)心的一個(gè)問題是 ta 是不是能看到我的代碼？ta 會不會因?yàn)槿绱藘?yōu)雅的代碼而感到自愧不如？所以隨后出于對他情感的考慮先清空了自己的代碼。
對于b，更換了多臺機(jī)器，發(fā)現(xiàn)仍然具有相同的問題，同樣出于職業(yè)尊嚴(yán)，我的機(jī)器不可能都被黑了，所以問題堅(jiān)決不在b。
隨后又細(xì)細(xì)過濾了最近的 GitHub 登錄記錄，c的可能性也被排除了；再問周圍的童鞋，d的問題也被排除了。
目前只剩下e原因，但是這句話其實(shí)相當(dāng)于沒有說，因?yàn)橐磺形粗寄軞w結(jié)到未知。
刨根問底
問題在這已經(jīng)陷入了死胡同，簡單描述下就是：因?yàn)槟承┪粗?，我?GitHub 的提交人變成了未知的某人，而且在換了多臺機(jī)器之后，問題依然重復(fù)。一般遇到這種情況，我的習(xí)慣都是從頭梳理整個(gè)流程，從全局分析可能存在問題的環(huán)節(jié)。當(dāng)務(wù)之急是需要重新梳理下所有的流程，然后不斷嘗試，那么問題來了，從編寫代碼到下載 Git 并使用 Git 提交到 GitHub 的流程是什么呢？
Git 首先需要下載到本地，下載本地的時(shí)候需要使用 HTTP 協(xié)議，HTTP 協(xié)議是基于 TCP 的，說到 TCP，那么就要了解三次握手…….
半小時(shí)后……
看著 16 位微處理器芯片 8086 微處理器總線接口部分(BIU) 和執(zhí)行部件(EU)知識的我……感覺再深挖下去估計(jì)要開始學(xué)習(xí)二氧化硅的化學(xué)反應(yīng)了，呵，知識啊。
只好另辟蹊徑，找了一個(gè)熟悉 Git 的強(qiáng)力外援，我們先嘗試了……然后嘗試了……接著又嘗試了……終于功夫不負(fù)有心人，找到了***的癥結(jié)所在。不是故意跳過這段，實(shí)在是這個(gè)過程乏善可陳。
總之看下邊重點(diǎn)了：
這個(gè)問題引發(fā)的根本原因是使用某發(fā)行版源倉庫安裝的 Git 默認(rèn)內(nèi)置了一個(gè)郵箱和用戶名，然后 GitHub 在上傳的時(shí)候識別用戶是默認(rèn)通過 Git 中配置的郵箱來識別，倘若用戶郵箱存在（在 GitHub 注冊或者登記）則顯示匹配到的用戶名，否則會顯示 Git 配置中的用戶名，驗(yàn)證之后發(fā)現(xiàn)這個(gè)郵箱不一定是注冊郵箱，而是在設(shè)置里添加的都可以關(guān)聯(lián)到，也就是剛剛提到的登記郵箱，即使你沒有驗(yàn)證郵箱的歸屬權(quán)限，如下圖：
而且尤其比較詭異的是使用 Git config user.name 和 Git config user.email 這兩個(gè)命令查看均顯示為空，就像這個(gè)命令從未執(zhí)行一樣，但是在使用 Git log 的時(shí)候才會真正顯示提交本次 commit 的用戶名和郵箱，也就是該發(fā)行版 Git 內(nèi)置的缺省賬戶和郵箱。
撥云見日
上邊說了那么多，那么這個(gè)東西有什么用呢？我一直秉承一個(gè)觀點(diǎn)：安全總是跟場景相關(guān)的，所以要想知道這個(gè)有什么危害，首先需要做的就是設(shè)想一些可利用的場景。
在這里最基本的利用方式是可以偽造別人去提交代碼，但是這個(gè)對我們來說其實(shí)并沒有什么太大的用處。準(zhǔn)確來說，更多有一種惡作劇的味道。
那有沒有什么其他的場景是比較有用的，其實(shí)在寫這篇文章之前，我還是比較猶豫的，眾所周知，GitHub 有很多用戶提交了一些比較敏感的東西，而作者是不想在現(xiàn)實(shí)中被發(fā)現(xiàn)的，但是上述提到這個(gè)接口，可以通過批量爆破郵箱從而獲得對應(yīng)的用戶名。那么也有可能獲得了那些不愿意公開自己身份用戶的聯(lián)系方式。
扯的有點(diǎn)遠(yuǎn)了，還是回歸到題目當(dāng)中 GitHub 監(jiān)控的問題，當(dāng)前 GitHub 監(jiān)控一直是基于代碼搜索中的關(guān)鍵字匹配，真的是誰用誰知道——那是相當(dāng)?shù)碾y用。所以目前很多人也是在爬蟲和更好的過濾上下功夫。但是這個(gè)流程還有一個(gè)盲點(diǎn)存在，就是在發(fā)現(xiàn)違規(guī)上傳的***時(shí)間并不能特別準(zhǔn)確的定位到具體的個(gè)人。
說完傳統(tǒng)監(jiān)控的缺陷同時(shí)，我們其實(shí)也找到了新的利用場景，因?yàn)槿肼毿畔⒌怯浂紩懙阶约旱某Ｓ绵]箱（還沒有入職，所以基本填寫自己私人常用郵箱），那么可以通過這個(gè)接口來獲得對應(yīng)的用戶賬戶，換句話說，安全團(tuán)隊(duì)基本就有了部分員工注冊的 GitHub 賬戶，這個(gè)時(shí)候違規(guī)上傳公司代碼的監(jiān)控是不是可以做一些分級管理，重點(diǎn)監(jiān)控。而且更重要的一點(diǎn)，這也解決了發(fā)現(xiàn)問題簡單、定位人員困難的問題。
至于操作過程，就相當(dāng)簡單了，新建一個(gè)項(xiàng)目，然后使用腳本修改自己用戶郵箱進(jìn)行 commit，在這里我以修改自己的郵箱為例：
之后 push 到 GitHub 上去，***在 GitHub 上就可以看到綁定了對應(yīng)郵箱的用戶，如下圖（項(xiàng)目地址：https://github.com/daysdaysup/TSRC_TEST）：
至于剩下的就不用再多說了。套用一句比較流行的打油詩：懂的自然懂，刀劍俠客夢，事了拂衣去，深藏身與名。
***特別致謝我的師兄吳恒，感謝他在撰寫本文時(shí)提供的幫助。
文章標(biāo)題：舊樹開新花：再談GitHub監(jiān)控
路徑分享：http://m.fisionsoft.com.cn/article/cddhhed.html
