安全九月：云层编队中的大灾难

这是关于AWS漏洞和在2020年中发现的类似发现的5部分系列的第四部分。本系列中讨论的所有调查结果都已向AWS安全团队披露，并在必要时将补丁部署到所有受影响的区域。非常感谢我的朋友、澳大利亚同胞艾丹·斯蒂尔与我共同撰写了这个系列。这篇帖子是艾登写的。

早在2019年11月，AWS CloudFortification就添加了对“资源提供者”的支持--这是一种使用用户创作的资源来扩展CloudFortification的新的改进方式。不仅如此，这也是AWS自己将所有新资源添加到CloudForms的方式。与“定制资源”相比，这是一个实质性的改进，“定制资源”至少自2013年以来就没有任何变化，除了2015年对Lambda的支持。这篇文章不会涉及资源提供商的区别或好处，因此请查看这篇AWS博客文章。

1月17日，本·凯霍(Ben Kehoe CloudForformationExtradiaire)给我发来了一个Twitter DM，上面有一个GitHub拉取请求的链接，这引发了他的敏感。收到这封信我很兴奋，因为a)本想到了我！B)它以一种新颖的方式将云中的CloudForms和凭证结合在一起，这是我最喜欢的两件事。这是我最终需要的借口-尽管要到21日我才有时间去挖掘资源提供者。

我注意到的第一件事是(与自定义资源不同)您正在创作的Lambda函数最终不在您的AWS帐户中运行-它在AWS管理的帐户中运行。我立即对我的代码在他们的帐户中有什么权限感到好奇-您会希望它被锁定了！我也很好奇我写的代码是如何在我的账户中扮演一个角色的--这个角色是在哪里承担的？

我决定下拉一个级别并记录Lambda函数的原始输入，而不是试图理解CloudFortification提供的框架以及事情是如何工作的，以查看事情是如何实际工作的。这是创建资源时传递给Lambda的输入的摘录：

CallerCredentials：这些是我应该使用的凭据。它们用于在我的帐户中承担实际创建、更新、删除等相关资源的角色。

ProviderCredentials：这些是CloudFormationManagedUploadInfrastructure堆栈中LogAndMetricsDeliveryRole角色的凭据，即用于写入出现在My Account中的日志。

Lambda执行角色的凭证(未如图所示)：这似乎只允许在AWS管理的帐户内写入日志。

Platform Credentials：这些是有趣的。它们适用于AWS托管帐户中的角色。该角色有权调用少数权限，但吸引我眼球的是Events：PutRule、Events：PutTarget、Events：RemoveTarget、Events：DeleteRule。

为什么Lambda函数需要权限才能调用这些EventBridge API？资源创建可能需要很长时间，而Lambda被限制为15分钟，因此该服务支持定期重新调用Lambda以询问“完成了吗？”而EventBridge cron作业非常适合于此。它的工作方式是创建一个一次性规则，计划在将来运行一分钟，目标是相同的Lambda。它指定应该使用硬编码的输入字符串重新调用Lambda-即，这个Lambda调用接收到的输入。

这激起了我的好奇心。如果我使用API触发不同的目标，比如我帐户中的Lambda，该怎么办？运气不好，他们一定是使用了Events：TargetArn条件键将目标限制为只有这个Lambda。因此，我尝试了其他方法：如果我尝试了不同的规则，会怎么样？我尝试创建一条规则，在他们的帐户中调用我的Lambda，通过CloudTrail"；]}将事件与{"；Detail-type"；：["；AWS API调用]}相匹配。我马上就被一连串的事件淹没了。我急忙把它关掉，因为我不是故意要打碎东西的，只是出于好奇。

我看了一下这些事件。这真的是一个安全问题，还是更像是一种“很可爱”的事情？大多数活动都很乏味。但有一件引起了我的注意。这是对事件的召唤：PutTarget。CloudTrail事件包括有效负载。我已经强调了值得注意的部分。

为了在一分钟后使用相同的有效负载重新调用该函数，我们在前面确定了目标是使用常量JSON输入创建的。该输入包括客户帐户中角色的凭据。多个(全部？)。客户由AWS托管账户提供服务。因此，我可以查看使用资源提供商的其他AWS客户的凭据。他们可能在没有意识到的情况下使用它：AWS正在将此模式用于第一方类型-我在日志中看到AWS：：WAFv2：：RuleGroup飞过。

那天下午，我向AWS安全团队报告了该问题。他们在9小时内给我回了电话。他们要求澄清(公平地说，我写第一封电子邮件的时候有点疲惫！)。以及我能提供的任何复制步骤。考虑到我已经拼凑了一个非常手工的概念验证，我开始为他们创建一个更有用的复制品。

CloudForms服务团队也联系了我。他们表示，他们实际上已经在内部发现了这一点，正在进行修复。几天后，也就是1月25日，他们告诉我已经在几个地区部署了修复程序，并问我是否可以再试一次。几分钟后，我得到了AWS安全团队的跟进，提出了同样的要求-AWS的进展速度惊人！

我又试了一次。在创建了我的规则之后，我得到了一些事件，但它很快就枯竭了，我甚至不需要关闭它。我看了一下事件记录。无论我尝试了多少次，我以前都没有看到过任何这样的问题。不过，我确实看到了这个有趣的故事：

聪明的!。他们已经创建了一个警报，只要创建了恶意规则就会触发。这是一次坚实的战术缓解。不幸的是，可用于事件的IAM策略条件：PutRule不够丰富，不足以完全阻止我，但这止血了。我还注意到异常地没有任何事件：PutTarget API调用事件。我不知道他们是如何做到这一点的，因为客户的账户不可能省略CloudTrail/EventBridge中的那些内容。我猜AWS有一些秘密的调味汁。

1月31日，我收到一封来自AWS Security的后续电子邮件，通知我问题已解决。

6月30日，CloudForment团队发布了资源提供者协议的第2版。它带来了很多好处，但对我来说最明显的变化是PlatformCredentials字段消失了。这不再是必需的，因为CloudForment本身处理Lambda函数的重新调用。

最后，在8月26日，AWS发出了以下电子邮件，温和地鼓励人们为资源提供商迁移到新协议。如果紧随其后的是v1的最终弃用，我不会感到惊讶。

我要感谢本·凯霍首先向我指出了这一点。如果没有他敏锐的眼睛和对合理安全的直觉，我永远不会注意到这一点。我要感谢伊恩在整个过程中是一个很好的倾听者。他去年关于湖泊形成问题的推文让我相信AWS会积极回复我的电子邮件。我还想感谢AWS安全团队，他们让我感到非常舒服，既报告了我的第一个问题，也让我觉得这个问题得到了彻底和令人印象深刻的及时解决。第二，感谢伊恩激励我多年来第一次写博客帖子！