SCARLETEEL:利用 Terraform、Kubernetes 和 AWS 窃取数据(3)
时间:2023-03-02 22:55 来源:网络整理 作者:默认发布 点击:次
为了让 Terraform 知道哪些资源归它控制、以及何时更新和销毁资源,它默认使用了名为 terraform.tfstate 的状态文件。当 Terraform 在持续集成 / 持续交付(CI/CD)管道中被集成和自动化时,要有适当的权限才能访问状态文件。尤其是,运行管道的服务主体需要能够访问保存状态文件的存储帐户容器。这使得像亚马逊 S3 存储桶这样的共享存储成为保存状态文件的理想选择。 然而,Terraform 状态文件以明本形式保管所有数据,这可能包含密文。将密文存储在安全位置以外的任何地方不是好主意,绝不应该放在源代码控制系统中! 攻击者能够列出可用的存储桶,并检索所有数据。若在事件调查期间使用不同的工具(比如 Pacu 和 TruffleHog)分析数据,可以在 S3 存储桶中的 terraform.tfstate 中同时找到明文 IAM 用户访问密钥和密文密钥。以下是来自 TruffleHog 的截图。 这些 IAM 凭据属于第二个连接的 AWS 帐户,从而使攻击者有机会横向移动,在整个组织中传播攻击。 横向移动—— AWS 帐户 获得新凭据后,攻击者重新启动枚举和信息收集过程,以确定是否可以从这个额外的受攻击帐户获得额外的资源。此外,CloudTrail 记录了上述的连接 AWS 帐户中的可疑活动。 攻击者试图对连接云帐户中的不同 AWS 资源执行枚举。幸好 IAM 用户被界定了明确范围,所以所有请求因缺乏权限而失败,只留下无害的 GetCallerIdentity API,它默认被允许。 建议 本文阐述的攻击清楚地表明威胁分子如何将试图到达云作为主要目的。这一切始于一项受攻击的服务,不过攻击者一旦获得了有效凭据就试图在云端横向移动,找到专有代码等有价值的信息。他们还试图转向其他云帐户以获得更多的信息。 以下是可以帮助你更谨小慎微的几个建议: 对你的应用程序和面向公众的容器运用漏洞管理周期,及时打上补丁。你会意识到暴露了什么,可以按轻重缓急处理修补活动。 使用 IMDS v2,而不是 IMDS v1。增强版需要面向会话的请求以增强深度防御,以防范未经授权的元数据访问。此外,为了确保只有授权的 pod 才能在集群中承担特定的 IAM 角色,尽可能采用最小权限原则,并使用服务帐户 IAM 角色(IRSA)。IRSA 限制了对资源的访问,降低了未授权访问的风险。未授权的 pod 将坚持使用 IMDS 设置。 不要低估只读访问的功效。面对特定的 AWS 资源(比如 Lambda 函数),即使只读也意味着数据泄露或凭据收集。仅对所需资源设置只读访问范围是保证帐户安全的基础。 监视云帐户中的过时对象。未使用的权限可能很危险,即使是旧的、从未使用的权限。贵组织一旦受攻击,将蒙受重大损失。留意过时的对象和定期评估云对象应该必不可少。 Terraform 是出色的工具,但需小心使用。采取最佳实践,并将状态文件存储在安全位置。若使用 AWS KMS、GCP KMS 或 Azure Key Vault 等密钥管理服务(KMS),可以确保密文安全,需要时加密或解密密文。 攻击总结和结论 总之,SCARLETEEL 攻击始于利用一个易受攻击的 pod。攻击者使用了与 pod 运行所在的节点关联的 IAM 角色相关的身份,然后利用这个角色在云端进行枚举,搜索敏感信息,并盗取专有软件。一旦他们发现了新的凭据,就利用新凭据获得持久性,并试图获得更多特权。 发现攻击后为保护环境而采取的措施包括:禁用和删除用户的访问密钥和密文访问密钥,在进行一些审计和渗透测试后保护易受攻击的应用程序,通过使用限制性策略限制对敏感 S3 存储桶的访问,以及采用额外的最小特权措施以减小潜在的攻击面,防止云端横向移动活动。 在这起复杂攻击中,我们看到了易受攻击的应用程序在缺乏足够的安全措施的情况下,攻击者如何能够深入云环境的底层。这次事件强调了众所周知的道理:首先,零信任和最小特权原则很重要;如果你实施它们,就会减小受攻击的可能性。其次,强大的检测和警报可以帮助你在攻击者进一步深入之前揪出这些活动。 攻陷指标(IOC) IP 地址:80 [ . ] 239 [ . ] 140 [ . ] 66, 45 [ . ] 9 [ . ] 148 [ . ] 221, 45 [ . ] 9 [ . ] 148 [ . ] 121, 45 [ . ] 9 [ . ] 249 [ . ] 58 (责任编辑:admin) |

