在过去的一年里，我看到人们对使用云本地技术处理云内安全事件的具体建议的兴趣大幅上升。 随着组织将其生产工作负载转移到云中，安全专业人员很快就会意识到，基本原理虽然在概念上相似，但在实践中却大相径庭。 其中一个核心概念就是斩杀链，这个术语最早由洛克希德 · 马丁发明，用来描述攻击者的攻击过程。 破坏任何某个链都会破坏攻击，因此这很好地映射到了将深度防御与事件响应的活动组件结合起来。

在云部署中，我们有四种主要的攻击类型，每种都有不同的斩杀链:

1. 对云平台本身的攻击。这是忽略云提供商的一个根本性的危害(在云客户手中之外) ，这些攻击通常集中在云服务的错误配置上。 如果你将 S3 存储桶公开，未能将授权程序放在 API 网关上，或者在 GitHub 上公开 AWS 的凭证，那么它就属于这一类。

2. 针对云端客户部署的资源和应用程序的攻击。 这些传统的攻击与针对数据中心的攻击没有什么不同。 常见的例子包括 web 应用程序中的 SQL 注入，以及对互联网打开错误端口的易受攻击的服务器。 假设你使用帐户 / 订阅 / 项目和VPC或虚拟网络来限制风险范围，那么与针对数据中心的限制相比，这些限制可能更严格一些。

3. 针对云管理员和开发人员的攻击。 下次运行渗透测试 / 服务器时，确保让攻击者尝试对你的开发人员和管理员发起钓鱼攻击。 这是入侵云环境的最好方法之一，因为对于攻击者来说，访问开发人员系统比破坏云应用程序本身要容易得多。 我们将在以后讨论这个问题，但是让我们从“MFA是我的朋友”开始。

4. 混合攻击。 这就是我们今天要关注的类别。 在这些攻击中，威胁执行者破坏部署在云中的某些内容，然后利用这些内容将重点转移到云管理平台上。 (有些人可能认为对开发人员的攻击是混合的，但我喜欢把它们分开)。

作为一个经验法则，我总是从假设任何级别的成功攻击都可以升级或转变为混合攻击开始，在这一点上，你的管理层安全和事件响应成为你最好的防御。

今天，我将重点介绍一种最常见的混合攻击过程，并概述侦查和预防控制的组合，以帮助打破斩杀链。 在我深入讨论细节之前，不要把这篇文章看作是对一个复杂问题的过度简化。 即使你知道自己在做什么，但在规模上管理我将要讨论的内容也是非常困难的。

在接下来的几个星期里，我们将向我们的早期客户推出针对这些问题专门设计的第一个 Ops，在那之后我们应该会在相对较短的时间内投入生产。

混合 AWS 攻击: 提取 IAM 角色凭证

在混合攻击中，威胁执行者突破了一些更传统的东西，然后利用这些东西转向云管理平台。 发生这种情况的主要方式有三种。 在每种情况下，攻击者都会提取静态存储凭证或临时 IAM 角色凭证，我们稍后将对此进行解释。

1. 实例或容器被直接入侵。 例如，如果你打开22端口，攻击者可以侵入或以其他方式获得 shell 访问权。

2. 服务器端请求伪造(SSRF)。 攻击者利用了 web 服务器或web服务的漏洞，可以执行命令而无需获得 shell 访问权限。

3. 对 Lambda 函数的攻击。 虽然你不能在 Lambda 上获得一个 shell，但是如果它们存在一个应用程序缺陷，它们仍然会受到代码执行漏洞的影响，甚至会被随意执行。 确切的含义类似于 SSRF。

在每种情况下，攻击者的目标都是获得 AWS 管理平台的凭证，然后利用现有的特权或升级特权。 我们将在后续的博文中讨论权限提升，现在我们将集中讨论这些凭证是什么，以及如何防止它们被滥用。

大多数人理解静态凭证; 在 AWS 中，静态凭证是访问密钥和秘密密钥。 它们类似于用户名和密码，但用于 AWS API  调用。 当前版本在进行这些 API 调用时使用一个称为 Signature 4的加密过程进行 HTTP 请求签名。 你可以也应该像对待用户名和密码一样对待它们，而且永远不要将它们存储在诸如示例和 Lambdas 这样的云资源中。

当你刚开始学习 AWS 的时候，IAM 角色是个骗子，他们既可怕又令人敬畏。 AWS 中的 IAM 角色实际上是你对会话使用的权限的容器。 IAM 角色很棒，因为它们本身并不是凭证… … 当你假定角色 AWS 为一个有时间限制的会话提供一组凭证时。 角色是“仅限于 AWS 内部”的东西。 你可以将它们分配给 AWS 中的资源(比如实例或 Lambda 函数) ，而且该资源现在可以在没有静态存储凭证的情况下进行 API 调用！ 我们将角色用于联合身份连接、实例、 Lambda 函数以及 AWS 中的所有其他服务。 实际上，只有当你在 AWS 帐户中创建用户的访问密钥时，我们才会对其他所有事情都使用角色。

角色有四种与之关联的权限类型

1. 这个角色在 AWS 中能做些什么，这些是你附加到角色的直接许可策略。

2. 谁或什么可以使用这个角色(信任策略)。创建一个角色并不意味着任何东西或任何人都可以使用它，这个策略限制对AWS实例或特定Lambda函数的访问。

3. 限制角色范围的权限边界。这有点复杂，与我们今天的讨论无关，所以我们将在稍后进行讨论。

4. 当你为会话假定一个角色时，你还可以指定现有权限的一个子集来使用该会话。这是一个很酷的特性，但对于我们今天的讨论也不是完全相关的。

通过遍历来解释它是如何工作的可能更容易。假设我有一个需要访问S3 存储桶或Dynamo数据库的应用程序。我为实例创建了一个IAM角色，并设置了信任策略，以便EC2服务可以使用该角色。然后我启动一个实例并分配角色。AWS运行实例并让实例承担角色。假设角色打开一个会话并分配一个访问密钥、一个秘密密钥和一个会话令牌。然后AWS每1-6小时轮换一次这些凭据，那么实例现在就可以进行由权限策略授权的 API 调用。

虽然凭证不在实例中，但是实例仍然可以访问凭证。 内部运行的任何代码都需要知道凭证，才能进行实际的 API 调用，以访问 S3和 Dynamo，所以元数据服务按需提供这些服务。 例如，一个服务器能够获得它的 IP 地址是相当重要的。

这就是攻击发生的地方

元数据服务只是一个可以访问的 url，它返回请求的信息。 执行curl 169.254.169.254/latest/meta-data/ 将提供所有的基本信息，你可以执行 curl 169.254.169.254/latest/meta-data/iam-security-credentials/ ，这将提供访问密钥、秘密密钥和令牌。 (对于基于 Lambda 的攻击来说，所有这些看起来都不同，它使用的是 SDK 代码而不是 curl，但适用的原则是相同的)。

然后，攻击者可以复制这些凭证，并在其他地方将其嵌入到工具中，而不必在拿到的服务器上加载和运行代码。 此外，由于是基于 URL的，所以它打开了元数据服务到更广泛的 SSRF 攻击范围，因为你不需要完全任意的代码执行。 这些凭证将在某个时候到期，但是根据攻击情况，当他们看到当前的凭证停止工作时，他们可能会返回并获得一个新的凭证集。

现在，聪明的攻击者会在他们控制的AWS帐户中使用凭证，因为亚马逊有一些工具来检测在已知地址范围之外提取和使用的凭证。

下面是我们在 Securosis 高级云安全培训课程中使用的一个短视频，学生们在实验室中学习这个过程:

点击查看视频

突破 IAM 角色提取斩杀链

让我们来规划一下斩杀链，攻击者需要做到以下几点:

· 发现并利用实例、容器或 Lambda 中允许他们访问角色凭证的漏洞。 在客户方面来说，这几乎总会是一个错误… 例如未能修补、打开错误的端口或部署易受攻击的代码。

· 提取当前角色的凭证

· 在它们控制的环境中成功运行允许的 API 调用。

· 在允许的 IAM 角色的权限策略范围内做一些不好的事情。 我的意思是，可能很糟糕，它不像大多数攻击者会为你修补代码。

下列技术可以打破链条中的不同环节，并包括侦查和预防性控制的混合。 如果这看起来势不可挡，不要感到难过… … 我工作的组织中很少有全面实施这些措施的，特别是在规模上。

6种技术助你打破攻击链中的不同环节

1. 漏洞管理

2. 具有资源限制的最小权限IAM权限策略

3. 在权限策略中使用IP、VPC或其他请求源条件限制

4. 使用带有策略+资源策略的服务端点

5. 使用HTTP用户代理过滤器添加元数据代理(元数据服务保护)

6. 重复角色使用保护

漏洞管理

· 复杂度: 中等

· 有效性: 低

· 可扩展性: 困难

· 类型: 侦查和预防

毫无疑问，你的开始应该是清除所有最初的漏洞和错误配置，攻击者可以利用这些漏洞获取凭证。 我只将复杂度评为中等，因为这并没有什么新的或特定于云计算的内容。 但我也认为它的有效性很低，因为它不像综合性的漏洞管理在过去几十年里防止了大量的漏洞。 概念简单，规模复杂得令人难以置信。

具有资源限制的最小权限IAM权限策略

· 复杂度: 中等

· 有效性: 高

· 可扩展性: 中等到难

· 类型: 预防

AWS 中的 IAM 策略默认为拒绝，并包含明确的允许和拒绝声明。 例如，你可以编写一个只允许读取 S3存储桶的策略。 它们还包括资源限制，因此当 allow 语句授权角色调用“读” API 时，资源限制只允许角色读取特定的存储桶或对象。 你应该总是在这里开始你的防御。 当我对几乎每个项目执行评估时，我发现 IAM 策略允许过多的特权(API 调用)和过少的资源限制。 是的，这个服务可能需要访问 Dynamo 数据库，但是它需要访问每个表吗？ 这种特殊的控制在小范围内实施并不是太糟糕，但你的规模越大，做出这些政策决定的人越多，在大范围内保持一致就越困难。 在有人向角色添加具有新权限的新策略时，添加显式的deny语句也很重要。权限是累积的，但是任何deny语句都会覆盖allow语句。

在权限策略中使用IP、VPC或其他请求源条件限制

· 复杂度: 高

· 有效性: 中等到高

· 可扩展性: 困难

· 类型: 预防

IAM 策略支持条件语句支持一系列选项，包括 IP 地址或源 VPC。 如果你知道某个特定角色应该只从应用程序堆栈中的特定资源进行 API 调用，那么你可以将授权锁定到该确切的 IP 地址或子网。 如果攻击者窃取凭证并试图在其他地方运行它们，API 调用将失败。 这是一个精确引导的大锤——概念上容易，执行上难，因为你可能会发现其他复杂性会干扰正确的实现。 例如，对 AWS 服务的 API 调用要么直接进入互联网，要么通过 NAT 网关运行，要么通过服务端点在内部进行路由(稍后我们将讨论)。 检测到的 IP 地址将取决于到 互联网的 API 调用的路由。 这些都是可管理和可检测的(并且是可自动化的) ，但是你首先需要仔细阅读以确保你理解了这些排列。

看看这篇文章的第一部分，可以找到一些例子。

除非你在一个 VPC 上运行你的 Lambda 函数，否则这不会是一个保护受损函数的选项。

使用带有策略+资源策略的服务端点

· 复杂度: 中等

· 有效性: 中等到高

· 可扩展性: 中等

· 类型: 预防

在 AWS 中，服务端点就像网络上的一个点，它接收通常通过呼啦圈传输到AWS服务的流量，并在内部重新路由这些流量。它们最初是为了允许AWS中的完全私有子网(那些没有任何方式接入互联网的子网)仍然可以访问某些AWS服务而创建的。你可以使用与IAM策略非常类似的方式使用端点支持策略来限制访问和操作。在这种情况下，你可以向端点策略添加限制，只允许访问端点背后的特定资源(S3是最常见的示例)。指定允许哪些存储桶，并且子网中的任何其他资源都不能访问该服务。可以认为这是IAM策略的后端——服务端点使用了限制性策略，即使有人意外地(或故意地)允许角色进行超出其权限的访问，它仍然不能访问服务端点策略中不允许的任何内容。这意味着我们现在有三层策略，所有这些策略都需要允许访问资源：

· 允许角色访问资源的IAM权限策略。

· 服服务端点策略，该策略允许在请求通过端点时访问资源，而不管使用的角色的权限如何。

· 存储桶或资源策略(这取决于资源的类型)可以限制只能访问经过批准的IP地址。

除非你在一个 VPC 上运行你的 Lambda 函数，否则这不会是一个保护一个受损函数的选项。

使用HTTP用户代理过滤器添加元数据代理(元数据服务保护)

· 复杂度: 高

· 有效性: 中等

· 可扩展性: 困难

· 类型: 预防

所有这些控件都假设攻击者可以窃取角色凭证，但是如果我们有办法降低攻击者获取这些凭证的能力，即使他们破坏了已授权的实例或容器，又该如何呢?(这种技术不适用于Lambda函数)。一个新出现的方法是首先限制对元数据服务的访问。尽管有一些尝试使用IPTables来实现这一点，但也可能破坏在实例上运行的代码所需的功能。2018年11月，AWS和Netflix合作，开始将AWS SDK API调用的用户数据添加到HTTP头文件中。这是对 SSRF 的一种防御，因为大多数 SSRF 攻击依赖于欺骗应用程序代表攻击者发出 HTTP 请求，但这些请求通常来自命令行工具，如 curl 或其他进程，并且缺少来自 AWS SDk 的用户数据头。 要做到这一点，你需要为这些请求插入一个代理。 对于实例和容器有一些开放源码的选择，包括运行在实例上的代理，而不是要求你把流量路由到虚拟设备或者 squid 代理。

如果攻击者破坏主机实例并运行 shell，这种技术将不起作用，因为它们可以禁用 Roxy 或劫持已批准的进程。

你可以在这篇 Netflix 的博文中读到所有关于它的细节。

重复角色使用保护

· 复杂度: 高

· 有效性: 高

· 可扩展性: 高

· 类型: 侦查

这是另一个来自 Netflix 团队的想法。 他们发布了一个很好的技术指南，用于检测在未经授权的位置(甚至在 AWS 中)何时正在使用 IAM 角色。 我强烈建议你阅读这个链接的博文，简短的总结一下就是他们将 CloudTrail 日志与其他一些工具结合起来，产出一张表，其中显示哪些实例使用哪些角色的 IP 地址。 然后，它们监视其他 API 调用，以查找某个角色何时从一个新 IP 地址重新使用，同时又从一个已批准的 IP 地址重新使用该角色。 使用这种方法，你不需要知道整个组织中正在使用的所有 IP 地址，你可以动态地构建正在使用的 IP 地址表，并检测同时在其他地方使用该角色的情况。 这种做法的可伸缩性很好，因为如果集中使用 CloudTrail，就可以集中运行逻辑，这是一种常见的最佳实践。

总结

这是另一个棘手的问题，我们不希望每个人都能在所有部署中实现所有这些选项。简单来说，让我们来看看IAM角色滥用的斩杀链:

· 发现并利用实例、容器或Lambda中的漏洞，允许它们访问角色凭据。这通常是客户端的一个错误，比如没有打补丁，打开了错误的端口，或者部署了易受攻击的代码。

· 漏洞管理(包括用于应用程序的SASST和DAST等工具)和评估你的云配置(使用DisruptOps等工具或Prowler和CloudMapper等开源工具)是你的第一道防线。

· 提取当前角色凭据。

· 元数据服务保护与漏洞管理。

· 在攻击者控制的环境中成功运行允许的API调用。

· 重复角色使用检测，在权限策略中使用IP、VPC或其他请求源条件限制，使用带有策略+资源策略的服务端点。

· 在允许的IAM角色的权限策略范围内做一些坏事。我的意思是，可能很糟糕，它不像大多数攻击者会为你修补代码。

· 具有资源限制的最小权限IAM权限策略。

希望这能让你更好地了解如何减少这类攻击的成功。