GitHub告急！黑客攻击勒索的惊魂记

5月3日，当中国程序员正愉快地过五一节时，国外程序员突然发现自己GitHub上的代码不翼而飞！自己的GitHub一秒变成悬疑片现场，不仅被黑客攻击删代码了，嚣张的黑客还留下一封勒索信：

如果你要恢复丢失的代码和避免我们泄漏代码：需要先支付0.1个比特币（约3838元）到这个地址：1ES14C7QLB5cyhlmuektxlgc1f2v2ti9da，再将Git登录名和支付证明发送到这个邮箱里[e-mail]。

如果你不相信我们是否真的有你的数据，我们可以向你发送证据。你的代码我们已下载并备份到服务器上。

如果我们在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