5月3日，當中國程序員正愉快地過五一節時，國外程序員突然發現自己GitHub上的代碼不翼而飛！自己的GitHub一秒變成懸疑片現場，不僅被黑客攻擊刪代碼了，囂張的黑客還留下一封勒索信：

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

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

如果我們在10天內沒有收到錢，我們將公開你的代碼或亂使用它們。

不僅是GitHub被黑客攻擊，據ZDNet報道，還有Bitbucket、GitLab也遭受同樣的攻擊。

這究竟是發生了什么事呢？

黑客攻擊勒索的驚魂記

一程序員在Reddit發帖講述其遭遇黑客攻擊被勒索的過程：當他修復一個Bug正要用SourceTree提交，當點擊提交按鈕時，電腦死機了。因為他的電腦經常會死機，所以他一開始沒有察覺到異常。可當他重啟動電腦后，SourceTree崩潰了，并提示重新安裝。重新安裝后，他又發現一個問題：Git索引文件損壞了！于是他在網上找了個簡單的命令來修復程序。他先是刪除了索引，然后點擊重置。

然后他發現他落后了超3200個Commits！這時他這才停下來看看自己最近提交的內容，代碼全沒了！整個項目僅剩下一個上述勒索信的文件！他還看了下Bitbucket，所有的遠程分支都不見了！

這不僅是個別用戶，截至發稿，在GitHub搜索比特幣地址，還有326個被黑的項目。

又是DDoS攻擊？

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

2018年2月28日，GitHub遭到峰值攻擊流量高達 1.35Tbps的DDoS攻擊，導致官網在一小段時間內無法訪問。

2015年3月28日，GitHub經歷了史上最大規模的DDoS攻擊，連續兩天使用“一種復雜的新技術來劫持無關用戶的瀏覽器對我們的網站發起大量流量”。

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

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

據GitLab安全總監Kathy Wang回應道，“我們根據Stefan Gabos昨天提交的贖金票確定了信息來源，并立即開始調查該問題。我們已經確定了受影響的用戶帳戶，并通知到這些用戶。根據調查發現，我們有強有力的證據表明，被泄露的帳戶在部署相關存儲庫時，其帳戶密碼是以明文形式來存儲。我們強烈建議使用密碼管理工具以更安全的方式存儲密碼，并且有條件的話，啟用雙因素身份驗證，這兩種方法都可以避免此問題發生。”

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

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

先別給錢，有免費救命妙招

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

不，在推特上，開發者社區的大V建議受害者在支付贖金之前先聯系GitHub、GitLab或Bitbucket，因為他們可能有其他方法可以幫助你恢復已刪除的代碼。

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

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

1.看到黑客的提交：

gitcheckoutorigin/master

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

gitcheckoutmaster

3.將修復origin/master：

gitcheckoutorigin/mastergitreflog#taketheSHAofthelastcommitofyoursgitreset[SHA]

4.但是查看代碼狀態時：

gitstatus

會發現：

HEADdetachedfromorigin/master

所以還得想別的辦法修復。

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

gitpushoriginHEAD:master--force

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

據調查，僅在 2018 年的500 多萬個泄漏密碼顯示，有近 3% 的人使用“123456”作為密碼。

加入我們程序員在企業項目開發里，使用這種弱密碼會有什么危害呢？

2018年8月，華住酒店集團數據庫采用簡單的賬戶名和密碼：root/123456，含達五億條用戶的詳細信息的數據庫遭到泄露。

在互聯網時代，作為開發者尤為具備安全開始的意識。在日常開發中，我們該如何做呢？

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

在架構和研發過程中要配合安全團隊或綜合考慮信息安全管理要素；

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

在數據泄露事件發生時，開發者應發揮自身的技術和業務優勢，積極配合安全團隊、法務團隊對事件溯源中所涉及到的業務場景和數據證據，提取固化提供支撐，在很多數據泄露事件溯源中開發者都是最有利的技術支撐，比如數據流程梳理、關鍵日志提取等。

開發者在配合過程中需要嚴格注意，避免破壞數據完整性。

再見，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