云安全案例15: 亚马逊云供应链攻击的三大提权路径
Wiz研究团队对在亚马逊云环境中提供给第三方供应商的权限进行了广泛的研究， 结果应该是一个警钟：
-
82% 的公司给第三方供应商提供高度特权的角色
-
76% 的公司存在允许完全接管帐户的第三方角色
-
超过 90% 的云安全团队并不知道他们向第三方供应商授予了高权限。
最常见的例子是亚马逊云ReadOnlyAccess策略，它在第三方供应商中非常流行，有25%供应商拥有这个权限。供应商和客户认为这是一项无害的策略，但它提供了对许多数据库、DynamoDB、S3 存储桶、SQS 队列等的广泛读取访问权限。
亚马逊云拥有大约 250 种不同的服务和约 9000 种不同的权限, 以至于大多数客户不了解他们向供应商提供了哪些权限。
在这里，分析一下由于权限复杂度导致的三大提权路径：
提权路径1： iam:PutRolePolicy
iam:PutRolePolicy是现有最强大的 亚马逊云 权限之一，因为它允许用户将任何策略添加到任何角色，只需两个简单的步骤即可有效地使权限所有者成为超级用户。
不用说， 在没有适当条件和限制的情况下，绝不应将此权限授予第三方供应商 。
令人惊讶的是，供应商中有超过 10% 使用此策略，影响了很多的环境并导致关键账户接管风险。
在最流行的供应商中, 其中一个需要iam:PutRolePolicy权限是 Spot。
为什么供应商请求 iam:PutRolePolicy？
Spot 是一个编排平台，可能需要广泛的权限才能在环境中生成不同的资源。
怎样才能降低风险？
使用编排平台时，应该始终有一个子集，它包括着平台允许使用的策略和角色。这些策略和角色应该被标记，并且iam:PutRolePolicy应该存在适当的使用条件，从而减少对这些角色的访问。
提权路径2：lambda:AddPermission
lambda:AddPermission权限用于将资源策略添加到Lambda函数，确定哪些服务可以访问该函数、触发其代码，甚至更新它。此权限非常强大：如果落入黑客手里，它可以让黑客接管帐户中任何现有的lambda并使用其特权成为超级大BOSS。
-
在帐户中找到一个高权限的
lambda函数 -
使用
lambda:AddPermission对原始IAM角色添加lambda:UpdateFunctionCode和lambda:InvokeFunction -
将攻击代码注入原始
lambda -
黑客现在可以提升权限并利用提供使用该
lambda的角色
为啥供应商需要这个权限
在大多数情况下，特定的低风险场景需要这个权限。例如。供应商有一个lambda函数，并希望动态地向该函数添加触发器（例如，连接一个S3存储桶事件通知以发送到lambda），但在不添加任何限制的情况下，会导致主要升级风险。
如何缓解风险
在向供应商提供高风险权限时，始终尽可能限制范围。为此，请将策略中的 lambda 函数名称限制为供应商使用的名称（例如 example-vendor-*），并将Principal限制为计划的触发器类型（例如存储桶事件通知场景中的 S3）。
{ "Sid": "LimitAddPermission", "Effect": "Allow", "Action": [ "lambda:AddPermission" ], "Resource": "arn:aws:lambda:*:*:function:example-vendor-*", "Condition": { "StringEquals": { "lambda:Principal": "s3.amazonaws.com" } }}
限制权限范围：亚马逊云身份引擎具有一组丰富的条件，可用于降低风险。在加入第三方供应商时，第一步应该是缩小资源范围，将资源限制由访问所有内容到访问特定资源。第二步是使用更高级的条件进一步限制，比如使用lambda:Principal来限制对S3服务的权限。
提权路径3：ReadOnlyAccess 托管策略
最臭名昭著的是亚马逊云ReadOnlyAccess策略。这项策略之所以具有如此重大的风险，是因为它看起来无害。 “没有什么可担心的，我们只需要只读访问权限”，给客户团队一种虚假的安全感。由于这是一项托管的亚马逊云策略，安全团队认为它是安全的，但他们往往没有意识到，亚马逊云ReadOnlyAccess是一项高度危险的策略，会使客户面临重大数据泄露威胁。如果访问权落入坏人之手，此策略可能会导致极端数据泄露，包括 PII、机密和存储在云中的任何其他数据。
25% 的供应商请求了ReadOnlyAccess，因此可以获得对客户数据的广泛访问权限。
以要求ReadOnlyAccess的领先供应商之一NewRelic为例：
为什么供应商需要ReadOnlyAccess
为了方便部署，推荐的策略是ReadOnlyAccess：
然而，当更仔细地检查每个集成所需的权限时，似乎NewRelic只需要来自不同服务的元数据，这就引出了为什么将ReadOnlyAccess用作默认策略的问题。一个示例是请求的DyanmoDB权限：
如何缓解风险
永远不要给第三方供应商ReadOnlyAccess权限，如果是访问元数据，只需要给ViewOnlyAccess权限，这样不会访问到真实数据。另一个步骤是尽可能利用加密，因为它要求读取方对KMS密钥具有额外的权限，从而减少攻击面。
