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

这些资料只公开，了5个小时，但是这时间够长了，足以被不法分子发现。 aws的一名工程师无意中将与客户，往来的邮件...



这些资料只公开，了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.ndss-symposium.org/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是不是应该在令牌出现在公共存储库中，之前而不是之后扫描令牌？是不是应该像微软似乎已经所，做的那样，对来自内部日志和支持数据的，此类数据加以修改，以防万一？

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

    关注 云头条