云渗透：不是典型的内部测试

对于投入云渗透测试世界的经验丰富的渗透测试人员来说，似乎有一条共同的道路。内部（又名假设违规）测试，其目标是证明受感染的用户可以访问云或云中受感染的应用程序的影响。

这条路通常从无知开始，接着是完全的困惑和质疑你所知道的关于渗透测试的一切，最后……永远不会结束。为什么？因为在这些云中运行的云提供商和云原生技术不断以惊人的速度发展。总是有更多的东西需要学习，还有更多的攻击路径等待被发现。

希望走过的道路，以一种有趣的方式定义遇到的无知和意识阶段，可以帮助其他人比我更快地度过早期阶段。

级别 1：就像任何其他内部渗透测试一样，对吗？

连接到内部云网络中假定的违规起点：类似于在 EC2 实例上运行的 Kali。针对 VPC 的内部 /16运行nmap并希望获得最好的结果。很快意识到可能有更好的方法来做到这一点。

第 2 级：得到了利用云魔法的第一个火花

应意识到，如果请求并接收目标环境的 IAM 凭证，可以使用这些云凭证和 AWS API 来枚举账户中所有 EC2 实例的 IP 地址，然后仅 nmap 这些 IP地址。拍拍自己的背，认为现在可能实际上是一名云安全专家。不幸的是，仍然认为云攻击面的范围仅限于运行在 EC2 上的服务。这样的 2 级移动。

3级：哇。不仅仅是EC2！？！

意识到如果你有 Route53 访问权限，可以枚举AWS管理的DNS区域中的所有A记录，这让你非常高兴。许多新的攻击面。开始发现由其他服务托管的东西，比如 Kubernetes、ECS、API 网关、ELB 等。你可能还没有意识到 Kubernetes、ECS、API 网关和 ELB 做了什么，但是在第 3 级就可以了。重要的是是你有更多的东西要破解。去寻找那些带有默认凭据、SSRF 漏洞、缺少身份验证等的服务，并享受一些乐趣！

第 4 级：被 IAM PrivEsc 唤醒

开始了解 IAM 是什么以及它如何被错误配置。将了解 IAM 权限升级。利用ec 2:RunInstance + iam:PassRole攻击路径并获得对 AWS 账户的管理访问权限。或者，弹出一个服务并意识到该服务具有一个可以承担其他 IAM 角色的 IAM 角色。你意识到，就像你之前的所有人一样，Spencer Gietzen 是一个非常聪明的人，他与社区分享了大量惊人的信息，你渴望了解更多关于 IAM privesc 的信息。此时可能应该查看IAM Vulnerable 。

级别 5：错误位置的秘密可能非常糟糕

开始查看其他关键的 AWS 服务，如 S3、Lambda、ECR、EKS、CloudFormation，并且您开始看到导致其他（非 IAM）类型的特权升级的模式：存储在错误位置的秘密（S3 存储桶对象、Kubernetes 秘密、Lambda 环境变量、EC2 用户数据等）可以提供意外的权限升级机会。提醒在可通过 SMB 共享访问的 powershell 脚本中查找密码。

第 6 级：开始用图表思考，甚至逆向思考

现在总是在环境中寻找秘密、易受攻击的软件和配置错误的 IAM 策略。但是，当您找到这些时，现在可以向后工作并专注于谁可以访问该秘密/漏洞软件/IAM 策略，并且构建并执行攻击路径以证明用户 X 具有通往渗透测试奖杯目标的路径。还意识到 AWS 账户之间可能存在关系，例如如何在单个林中连接多个 Active Directory 域。正在寻找可以使用来自较低信任账户的访问权限来访问较高信任账户（例如，角色信任）的方法，并且攻击链变得更具影响力。

第 7 级：CI/CD 工具是一个该死的金矿

正在测试 ACME corp，这是一个从安全角度来看相当成熟的组织。除了 Ops 团队和自动化部署工具之外，没有人拥有对生产云环境的写入权限。但是，您意识到所有开发人员都可以访问持续部署工具，而且事实证明 RBAC 并没有在这里强制执行。意识到这意味着所有开发人员都可以访问 CI/CD 工具软件中的所有秘密，因此获得了生产云环境的管理员权限，完成了评估目标，并跳起了胜利之舞。将其归档在“我总是需要寻找的东西”类别中。它很少让人失望。

第 8 级：开始认为技术垄断是一件好事

这些天您对云安全性感觉非常好。（你可以看出我个人在 AWS 上花费的时间最多，但你的旅程可能从 GCP、Azure 或什至其他之一开始。）但最终，你将需要在另一个中运行渗透测试公共云，很快就会注意到它们之间确实存在很大差异。开始渴望 Active Directory 的普及。感到欣慰的是，至少有一半的云渗透测试方法与云无关并且适用于所有云提供商。但是每次您必须重新开始并了解新的云提供商的来龙去脉时，都会感到难过。关于这一点，当您不得不将上下文切换到您有一段时间没见过的云提供商时，也会感到有点难过。

第 9 级：对云一无所知

对云渗透测试了解得越多，就越相信自己对云一无所知。已经了解到每个组织的攻击面完全取决于目标组织使用的特定服务、组织如何部署这些服务、所有服务如何相互交互以及它们如何与第三方服务交互. 换句话说，知道需要采用的一般方法，但不得不接受这样一个事实，即在可预见的未来将学习新的云服务和新的云原生技术。

荣誉奖：

• 为什么 Responder 在云中没有按预期工作？
• Hey Google：“什么是云原生？”、“什么是无服务器？”以及“什么是 Kubernetes？”
• Azure Active Directory 是 Azure 的托管 Active Directory，对吗？正确的！？

在您的云渗透测试之旅中有哪些“啊哈”时刻？

原文始发于微信公众号（祺印说信安）：云渗透：不是典型的内部测试