GitHub告急！黑客攻擊勒索的驚魂記

5月3日，當(dāng)中國(guó)程序員正愉快地過五一節(jié)時(shí)，國(guó)外程序員突然發(fā)現(xiàn)自己GitHub上的代碼不翼而飛！自己的GitHub一秒變成懸疑片現(xiàn)場(chǎng)，不僅被黑客攻擊刪代碼了，囂張的黑客還留下一封勒索信：

如果你要恢復(fù)丟失的代碼和避免我們泄漏代碼：需要先支付0.1個(gè)比特幣（約3838元）到這個(gè)地址：1ES14C7QLB5cyhlmuektxlgc1f2v2ti9da，再將Git登錄名和支付證明發(fā)送到這個(gè)郵箱里admin@gitsbackup.com。

如果你不相信我們是否真的有你的數(shù)據(jù)，我們可以向你發(fā)送證據(jù)。你的代碼我們已下載并備份到服務(wù)器上。

如果我們?cè)?0天內(nèi)沒有收到錢，我們將公開你的代碼或亂使用它們。

不僅是GitHub被黑客攻擊，據(jù)ZDNet報(bào)道，還有Bitbucket、GitLab也遭受同樣的攻擊。

這究竟是發(fā)生了什么事呢？

黑客攻擊勒索的驚魂記

一程序員在Reddit發(fā)帖講述其遭遇黑客攻擊被勒索的過程：當(dāng)他修復(fù)一個(gè)Bug正要用SourceTree提交，當(dāng)點(diǎn)擊提交按鈕時(shí)，電腦死機(jī)了。因?yàn)樗碾娔X經(jīng)常會(huì)死機(jī)，所以他一開始沒有察覺到異常?？僧?dāng)他重啟動(dòng)電腦后，SourceTree崩潰了，并提示重新安裝。重新安裝后，他又發(fā)現(xiàn)一個(gè)問題：Git索引文件損壞了！于是他在網(wǎng)上找了個(gè)簡(jiǎn)單的命令來修復(fù)程序。他先是刪除了索引，然后點(diǎn)擊重置。

然后他發(fā)現(xiàn)他落后了超3200個(gè)Commits！這時(shí)他這才停下來看看自己最近提交的內(nèi)容，代碼全沒了！整個(gè)項(xiàng)目?jī)H剩下一個(gè)上述勒索信的文件！他還看了下Bitbucket，所有的遠(yuǎn)程分支都不見了！

這不僅是個(gè)別用戶，截至發(fā)稿，在GitHub搜索比特幣地址，還有326個(gè)被黑的項(xiàng)目。

又是DDoS攻擊？

這不是第一次GitHub遭遇黑客攻擊了：

2018年2月28日，GitHub遭到峰值攻擊流量高達(dá) 1.35Tbps的DDoS攻擊，導(dǎo)致官網(wǎng)在一小段時(shí)間內(nèi)無法訪問。

2015年3月28日，GitHub經(jīng)歷了史上最大規(guī)模的DDoS攻擊，連續(xù)兩天使用“一種復(fù)雜的新技術(shù)來劫持無關(guān)用戶的瀏覽器對(duì)我們的網(wǎng)站發(fā)起大量流量”。

難道這次又雙叒叕是黑客DDoS攻擊？

不，這次竟是程序員缺乏基本的安全意識(shí)造成的：明文存儲(chǔ)密碼。

據(jù)GitLab安全總監(jiān)Kathy Wang回應(yīng)道，“我們根據(jù)Stefan Gabos昨天提交的贖金票確定了信息來源，并立即開始調(diào)查該問題。我們已經(jīng)確定了受影響的用戶帳戶，并通知到這些用戶。根據(jù)調(diào)查發(fā)現(xiàn)，我們有強(qiáng)有力的證據(jù)表明，被泄露的帳戶在部署相關(guān)存儲(chǔ)庫(kù)時(shí)，其帳戶密碼是以明文形式來存儲(chǔ)。我們強(qiáng)烈建議使用密碼管理工具以更安全的方式存儲(chǔ)密碼，并且有條件的話，啟用雙因素身份驗(yàn)證，這兩種方法都可以避免此問題發(fā)生?！?/p>

幸運(yùn)的是，根據(jù)StackExchange安全論壇的成員發(fā)現(xiàn)，黑客實(shí)際上并沒有刪除源碼，但是改變了Git的head，這意味著在某些情況下可以恢復(fù)代碼提交。

眾多程序員對(duì)黑客的行為表示不滿，齊齊去黑客留下的比特幣收貨地址舉報(bào)，目前該地址已收到34個(gè)舉報(bào)：

先別給錢，有免費(fèi)救命妙招

那么面對(duì)被黑客“端了老窩”的程序員，只能雙手奉上贖金嗎？

不，在推特上，開發(fā)者社區(qū)的大V建議受害者在支付贖金之前先聯(lián)系GitHub、GitLab或Bitbucket，因?yàn)樗麄兛赡苡衅渌椒梢詭椭慊謴?fù)已刪除的代碼。

一位“遭殃”的開發(fā)者先使用命令git reflog瞅了瞅，能看到他自己所有的提交，所以他猜測(cè)黑客很可能沒有克隆存儲(chǔ)庫(kù)。

接著他給出嘗試自救的步驟：

1.看到黑客的提交：

gitcheckoutorigin/master

2.看到自己的所有文件：

gitcheckoutmaster

3.將修復(fù)origin/master：

gitcheckoutorigin/mastergitreflog#taketheSHAofthelastcommitofyoursgitreset[SHA]

4.但是查看代碼狀態(tài)時(shí)：

gitstatus

會(huì)發(fā)現(xiàn)：

HEADdetachedfromorigin/master

所以還得想別的辦法修復(fù)。

接著他還提到，如果你本地有代碼備份的話，直接用就能修復(fù)：

gitpushoriginHEAD:master--force

因弱密碼被“祭天”的程序員

據(jù)調(diào)查，僅在 2018 年的500 多萬個(gè)泄漏密碼顯示，有近 3% 的人使用“123456”作為密碼。

加入我們程序員在企業(yè)項(xiàng)目開發(fā)里，使用這種弱密碼會(huì)有什么危害呢？

2018年8月，華住酒店集團(tuán)數(shù)據(jù)庫(kù)采用簡(jiǎn)單的賬戶名和密碼：root/123456，含達(dá)五億條用戶的詳細(xì)信息的數(shù)據(jù)庫(kù)遭到泄露。

在互聯(lián)網(wǎng)時(shí)代，作為開發(fā)者尤為具備安全開始的意識(shí)。在日常開發(fā)中，我們?cè)撊绾巫瞿兀?/p>

可以參照5 天 6 億 3000 萬數(shù)據(jù)泄露一文的方案：

在架構(gòu)和研發(fā)過程中要配合安全團(tuán)隊(duì)或綜合考慮信息安全管理要素；

在實(shí)際開發(fā)過程中要避開常見安全問題，如上傳 Github、SQL 注入、任意命令執(zhí)行、緩沖區(qū)溢出、水平越權(quán)、日志敏感信息記錄、敏感文件任意存放等問題。

在數(shù)據(jù)泄露事件發(fā)生時(shí)，開發(fā)者應(yīng)發(fā)揮自身的技術(shù)和業(yè)務(wù)優(yōu)勢(shì)，積極配合安全團(tuán)隊(duì)、法務(wù)團(tuán)隊(duì)對(duì)事件溯源中所涉及到的業(yè)務(wù)場(chǎng)景和數(shù)據(jù)證據(jù)，提取固化提供支撐，在很多數(shù)據(jù)泄露事件溯源中開發(fā)者都是最有利的技術(shù)支撐，比如數(shù)據(jù)流程梳理、關(guān)鍵日志提取等。

開發(fā)者在配合過程中需要嚴(yán)格注意，避免破壞數(shù)據(jù)完整性。

再見，123456！

參考：

https://www.zdnet.com/article/a-hacker-is-wiping-git-repositories-and-asking-for-a-ransom/

https://security.stackexchange.com/questions/209448/gitlab-account-hacked-and-repo-wiped