倒霉的AWS工程师将密码、密钥、机密内部培训信息和客户邮件泄露到了公开的GitHub上

这些资料只公开了5个小时，但是这时间够长了，足以被不法分子发现。

 

AWS的一名工程师无意中将与客户往来的邮件以及“系统登录信息（包括密码、AWS密钥对和私钥）”发送到了公开的GitHub存储库上。

1月13日，信息安全公司UpGuard发现了一个容量为954MB的存储库，其中含有用于创建云服务的AWS资源模板，以及主机名和2019年下半年生成的日志文件，还有被标为“机密级”的内部亚马逊培训资源。

UpGuard今天声称：“几个文档含有各种云服务的访问密钥。有多个AWS密钥对，其中包括一个名为‘rootkey.csv’的密钥对，这表明它提供了对用户AWS帐户的根访问权限。其他文件含有第三方提供商所用的一大堆验证令牌和API密钥。一家保险公司的一个此类文件含有消息传递和电子邮件提供商的密钥。”

UpGuard继续说：

除了与计算机系统有关的数据（比如登录信息、日志和代码）外，存储库还含有各种文档，这些文档明确了所有者的身份及其与AWS之间的关系。

这些文档包括银行对账单、与AWS客户的往来信件以及包括驾驶执照的身份证明文件。多个文档包含所有者的全名。全名完全对得起来的LinkedIn个人资料显示，有个人在工作角色中将AWS列为其雇主，信息与该存储库中的数据类型相匹配。存储库中的其他文档包括AWS人员的培训信息以及被标为“亚马逊机密”的文档。

从这些证据来看，UpGuard确信数据源自AWS的一名工程师。

发现信息泄露几小时后，UpGuard通知了AWS安全团队，该存储库随即下线。存储库公开时间不到5个小时。然而，正如UpGuard引用北卡罗来纳州立大学的这篇论文（https://www./wp-content/uploads/2019/02/ndss2019_04B-3_Meli_paper.pdf）所特别指出的那样，有多个方法可以通过GitHub的搜索功能迅速发现此类意外事件。

UpGuard说：“你能够实时发现刚提交的含有机密信息的文件中99%的内容。”这些研究人员认为，“每天都有成千上万新的独特机密信息被泄露”。这意味着，即使泄露5个小时，这时间也足以让犯罪分子获取机密信息。

为什么这么多的机密信息最终出现在GitHub存储库中？一个常见的原因是，尝试一些新想法的开发人员将登录信息硬编码到应用程序中，然后在未认真考虑影响或后果的情况下发布了代码，或者忘了自己发布到公开的存储库上。

这个问题非常普遍，GitHub现在有一项令牌扫描服务，该服务会搜索“公开的存储库，查找已知的令牌格式，以防止意外提交的登录信息被欺诈性使用。”

GitHub还建议“应将GitHub发送给你的任何令牌视作公开、已受危及的消息。”

然而就本文这起事件而言，UpGuard特别指出，存储库“设计成常规存储区而不是应用程序代码，顶层目录中有许多文件，子目录没有明确的约定。”为什么这出现在GitHub存储库中？原因不得而知，有可能是错误的脚本，也可能是有人试图像Dropbox那样使用GitHub用于交换或备份文件。

UpGuard特别指出：“没有证据表明该用户存在恶意行为或最终用户的任何个人数据已受到影响，一方面是由于UpGuard及时发现了数据，随后AWS迅速修复了问题。”

GitHub是不是使搜索存储库以寻找密码和访问令牌变得太容易了？GitHub是不是应该在令牌出现在公共存储库中之前而不是之后扫描令牌？是不是应该像微软似乎已经所做的那样，对来自内部日志和支持数据的此类数据加以修改，以防万一？

亚马逊发言人告诉我们，那名工程师私下使用了核心存储库，声称没有任何客户数据或公司系统因此泄露。