横向移动是云安全日益令人担忧的问题。也就是说，一旦您的云基础设施的一部分受到威胁，攻击者可以攻击多远？

在针对云环境的著名攻击中，经常发生的情况是，一个公开可用的易受攻击的应用程序可以作为入口点。从那里，攻击者可以尝试进入云环境，试图窃取敏感数据或使用该帐户来达到自己的目的，例如加密货币挖掘。

在本文中，我们将介绍一个分阶段但真实的场景，以展示攻击者如何获得对云帐户的完全访问权限。我们还将介绍如何使用 Sysdig Cloud Connector 检测和缓解此类攻击。

横向移动的场景

让我们从一个存在漏洞的 Struts2 应用程序开始这项云安全练习，该应用程序在 Kubernetes 集群中运行并托管在 AWS 账户内。

一旦攻击者获得对 pod 的访问权，他们就会评估环境，寻找秘密或凭证来执行横向移动并提升权限。

这些凭证可能在 aws 元数据中找到。一旦获得，攻击者将可以访问 AWS 账户，然后就可以开始四处搜索。

攻击者可以访问云基础设施，然后寻找错误配置，以便执行下一步操作。例如，通过保留权限、破坏云防御或提升特权来巩固地位。最终，攻击者可以通过寻找可窃取的数据、安装加密矿工或机器人控制中心来造成危害。

现在我们了解了对手的整体策略，让我们更深入地了解他们的行动。

步骤 1：利用面向公众的 Web 应用程序

Cloud MITRE ATT&CK 中报告的初始访问 TTP（策略、技术和程序）之一是通过利用面向公众的应用程序。这是有道理的。毕竟，任何公开的东西都是可以访问的。

在这种情况下，有一个公开可用的 Apache Struts2 应用程序。

为了查看可用实例是否受到众所周知的漏洞的影响，攻击者开始进行被动和主动的信息收集活动。通过与 Web 应用程序交互，攻击者可以检索软件版本以及有关所部署应用程序的其他附加信息。从那里，攻击者可以查询漏洞数据库以寻找入口点。

攻击者发现我们使用的 Apache Struts2 版本存在 CVE-2020-17530 漏洞，该漏洞允许在机器上执行远程代码。如果攻击者设法利用此特定漏洞，他们将能够在机器上执行任意代码，包括在系统内打开反向 shell。

攻击者向服务器发送精心设计的 HTTP 请求，然后，就会从受害者主机打开一个到攻击者机器的 shell。

打开反向 shell 所需的 bash 命令包含特殊字符，这可能会导致执行过程中出现错误。为了避免这种情况，通常使用 base64 对命令进行编码，然后在执行过程中对其进行解码。

从主机名中apache-struts-6c8974d494，攻击者可以看到他们进入了 Kubernetes 集群内的 pod 或容器。

第 2 步：横向移动到云端

现在我们的对手已经进入，他们必须考虑地形。您可能认为，进入容器后，攻击者会受到相当大的限制。您说得对，但他们仍然有一些方法可以破坏我们的云安全。

攻击者检查该 pod 是否可以访问 AWS 实例元数据。


看起来确实如此。可能存在有关云环境的有用信息，可帮助攻击者提升权限或执行横向移动。

通过查看 IAM 凭证，对手找到与运行 pod 的Kubernetes 节点关联的 AWS IAM 角色凭证。

攻击者现在可以在自己的环境中导入凭据并通过 cli 直接访问云帐户。

步骤3：通过策略配置错误进行权限提升

此时，攻击者可以使用窃取的凭证连接到 AWS 账户。

他们做的第一件事就是开始评估模拟角色所附带的角色和策略，尝试找到在云环境内提升权限的方法。

该devAssumeRole政策看起来很有希望。让我们看看它授予了哪些权限。


有了AssumeRole，攻击者就可以选择扮演其他用户。授予此类帐户的权限很奇怪。这可能是一种错误配置，而这正是攻击者想要的。

此外，有了ReadOnlyAccess权限，攻击者可以枚举 AWS 账户中可用的角色，并根据现有的限制找出他们可以承担的角色。在这种情况下，攻击者可以冒充以单词“dev”开头的角色。当前用户可以承担的角色之一是dev-EC2Full，它允许完全控制 EC2。


假设这个角色，攻击者可以像开发用户一样行事，对 EC2 实例具有完全访问权限，并能够为自己的目的创建新的实例。

下一步

让我们回顾一下迄今为止讨论的内容和两个主要流程：

  • Kubernetes 生产环境中正在运行一个存在漏洞的面向公众的应用程序。攻击者可利用该应用程序作为进入该环境的入口点。

  • 附加到生产实体（运行 Kubernetes 节点的 EC2 实例）的与开发相关的 IAM 策略中存在错误配置，允许攻击者承担更强大的角色并提升云环境内的权限。

  • 此时，攻击者拥有足够的权限来危害我们的组织。他们可以立即开始行动，或进一步尝试破坏我们的云安全并获得更大的访问权限。不要错过我们的“跨 AWS 云和容器的统一威胁检测”文章，以更全面地了解攻击者可以采取的以下步骤，并了解 AWS 提供哪些工具来防止、检测和缓解这些攻击。

使用 Sysdig Secure 检测横向移动攻击

幸运的是，这些类型的攻击留下了非常明显的痕迹。例如，反向 shell 是不常见的，运行时安全工具可以轻松发出警报。此外，安全工具可以标记错误配置。使用正确的工具，您可以增强云安全性。

Sysdig 安全 DevOps 平台提供您所需的可见性，让您可以放心地运行容器、Kubernetes 和云。它基于开源堆栈构建，采用 SaaS 交付方式，运行和扩展极其简单。

借助适用于云的 Sysdig Secure，让我们看看如何在每个步骤中检测到此攻击。

检测面向公众的 Web 应用程序漏洞

我们了解了攻击者如何利用漏洞，从而允许他们在受害者 pod 中打开反向 shell。

通过利用系统事件，Sysdig 知道发生了什么。其众多现成的Falco规则之一被触发，并生成了警报：


得益于部署在 Kubernetes 集群中的 Sysdig Agent 收集的元数据，警报包含大量有用信息。除了涉及的 IP 之外，警报还包括集群名称、命名空间和 pod 的部署。

但是一旦触发警报会发生什么？如果集装箱消失，你该如何调查该事件？

在运行时策略配置中，您可以启用系统事件捕获。这将收集策略触发时周围的所有系统事件。

然后，您可以使用 Sysdig Inspect 执行取证分析，并了解攻击者在系统中所做的事情。

检测云的横向移动

我们看到了攻击者如何与 pod 建立连接，然后通过读取 AWS 实例元数据来收集有关云环境的信息。

让我们看看这些命令，使用 Sysdig Inspect 分析触发反向 Shell 警报时策略所做的捕获。

首先，我们可以看到用于打开反向shell的bash脚本。

稍后，我们可以看到对内部 IP 的 curl 命令，该命令用于检索授予 AWS 账户访问权限的 IAM 机密。

检测云恶意行为和错误配置

得益于Sysdig Secure for cloud，安全保护已扩展到整个云环境。如果根据已存在的运行时规则检测到帐户中的安全问题，将生成安全警报。以下是攻击者可能以角色身份触发的安全警报示例dev-EC2Full.

在这个场景中，我们看到攻击者能够利用环境中的错误配置来提升权限。如果安全团队能够在错误配置应用于环境后立即检测到它，情况会怎样？

使用云连接器功能，可以创建自定义 Falco 规则，该规则在出现错误配置时会生成警报。

在我们的案例中，错误配置是将与开发相关的策略应用于与开发无关的实例角色。使用此处报告的自定义规则，可以针对此特定场景创建检测。


- rule: "Attach a dev-AssumeRole Policy to a non-dev Role"
  desc: "dev-AssumeRole Policy must be attached to only dev Roles so that only dev users can assume extra roles"
  condition:
    jevt.value[/eventName]="AttachRolePolicy"
    and (not jevt.value[/errorCode] exists)
    and (not jevt.value[/requestParameters/roleName] contains "dev")
    and jevt.value[/requestParameters/policyArn]="arn:aws:iam::720870426021:policy/dev-AssumeRole"
  output:
    The dev-AssumeRole has been attached to a Role (%jevt.value[/requestParameters/roleName]) which is not
     related to the dev. requesting IP=%jevt.value[/sourceIPAddress], AWS region=%jevt.value[/awsRegion],
     requesting user=%jevt.value[/userIdentity/arn]"
  priority: "WARNING"
  tags:
    - "cloud"
    - "aws"
  source: "aws_cloudtrail"

在下面的屏幕截图中，您可以看到，一旦用户将策略附加到错误的角色，规则就会被正确触发，并在几分钟内向安全团队发出错误配置警报。

与之前的安全事件一样，我们可以看到 Sysdig Secure for cloud 如何提供大量有用信息。得益于连接器收集的额外元数据，该事件包含有关 AWS 帐户、受影响的对象和执行操作的用户的关键信息。

结论

我们介绍的真实场景攻击展示了攻击者如何在云环境中横向移动。此类攻击可以从面向公众的易受攻击的容器开始，并且可以使用 Sysdig Secure 中的功能进行检测和缓解。

通过利用新的Sysdig Secure for cloud，安全团队可以汇总与容器和云资产相关的安全事件，集中威胁检测并加强云安全。所有这些都可以通过单一工具、现成的策略完成，无需进一步自定义集成。

我们的工具使安全事件调查变得更加容易。当它对安全团队至关重要时，他们可以将所有相关信息集中在同一个地方、一个集中的时间轴上，并且事件之间具有关联性。

免责声明

本文仅用于技术讨论与学习，利用此文所提供的信息而造成的任何直接或者间接的后果及损失，均由使用者本人负责，本平台和发布者不为此承担任何责任。