云服务，顾名思义就是云上的服务(阿里云、腾讯云、华为云、天翼云、金山云)
S3 对象存储Simple Storage Service，简单的说就是一个类似网盘的东西，当然跟网盘是有一定区别的。
EC2 即弹性计算服务Elastic Compute Cloud，简单的说就是在云上的一台虚拟机。
RDS 云数据库Relational Database Service，简单的说就是云上的一个数据库。
IAM 身份和访问管理Identity and Access Management，简单的说就是云控制台上的一套身份管理服务，可以用来管理每个子账号的权限。
S3 对象存储
S3 介绍
对象存储（Object-Based Storage），对象存储中可以有多个桶（Bucket），然后把对象（Object）放在桶里，对象又包含了三个部分：Key、Data 和Metadata
Key：唯一标识符
Key 是指存储桶中的唯一标识符，例如一个 URL 为：https://teamssix.s3.ap-northeast-2.amazonaws.com/flag，这里的 teamssix 是存储桶 Bucket 的名称，/flag 就是 Key
Data：数据，就是存储的数据本体
Metadata：索引标签，即元数据，可以简单的理解成数据的标签、描述之类的信息，这点不同于传统的文件存储，在传统的文件存储中这类信息是直接封装在文件里的，有了元数据的存在，可以大大的加快对象的排序、分类和查找
操作使用 Amazon S3 的方式也有很多，主要有以下几种：
AWS 控制台操作
AWS 命令行工具操作
AWS SDK 操作
REST API 操作，通过 REST API，可以使用 HTTP 请求创建、提取和删除存储桶和对象。
Bucket 公开访问
在 Bucket 的 ACL 处，可以选择允许那些人访问
Bucket 爆破
当不知道 Bucket 名称的时候，可以通过爆破获得 Bucket 名称，这有些类似于目录爆破，只不过目录爆破一般通过状态码判断，而这个通过页面的内容判断。
当 Bucket 不存在时有两种返回情况，分别是 InvalidBucketName 和 NoSuchBucket
当 Bucket 存在时也会有两种情况，一种是列出 Object，另一种是返回 AccessDenied
这样通过返回内容的不同，就可以进行 Bucket 名称爆破了，知道 Bucket 名称后，Key 的爆破也就很容易了。
Bucket 接管
假如在进行渗透时，发现目标的一个子域显示如下内容
通过 cname 记录，可以判断出这是一个 Amazon 的 S3，而且页面显示 NoSuchBucket，说明这个 Bucket 可以接管的，同时 Bucket 的名称在页面中也告诉了我们，为 test.teamssix.com
那么我们就直接在 AWS 控制台里创建一个名称为 test.teamssix.com 的 Bucket 就可以接管了
创建完 Bucket 后，再次访问发现就显示 AccessDenied 了，说明该 Bucket 已经被我们接管了。
将该 Bucket 设置为公开，并上传个文件试试
在该子域名下访问这个 test.txt 文件
S3 任意文件上传
如果对象存储配置不当，比如公共读写，那么可能就会造成任意文件上传与文件覆盖。
如果目标的对象存储支持 html 解析，那就可以利用任意文件上传进行 XSS 钓鱼、挂暗链、挂黑页、供应链投毒等操作。
Bucket ACL 可写
列出目标 Bucket 提示被拒绝
查看目标 Bucket ACL 策略发现是可读的，且策略如下
aws s3api get-bucket-acl --bucket teamssix
通过官方文档，可以分析出这个策略表示任何人都可以访问、写入当前 Bucket 的 ACL
那么也就是说如果我们把权限修改为 FULL_CONTROL 后，就可以控制这个 Bucket 了，最后修改后的策略如下：
{
"Owner": {
"ID": "d24***5"
},
"Grants": [
{
"Grantee": {
"Type": "Group",
"URI": "http://acs.amazonaws.com/groups/global/AllUsers"
},
"Permission": "FULL_CONTROL"
}
]
}
将该策略写入
aws s3api put-bucket-acl --bucket teamssix --access-control-policy file://acl.json
再次尝试，发现就可以列出对象了
Object ACL 可写
读取 Object 时提示被禁止
查看目标 Object 策略发现是可读的，且内容如下：
aws s3api get-object-acl --bucket teamssix --key flag
这个策略和上面的 Bucket ACL 策略一样，表示任何人都可以访问、写入当前 ACL，但是不能读取、写入对象
将权限修改为 FULL_CONTROL 后，Object ACL 策略如下：
{
"Owner": {
"ID": "d24***5"
},
"Grants": [
{
"Grantee": {
"Type": "Group",
"URI": "http://acs.amazonaws.com/groups/global/AllUsers"
},
"Permission": "FULL_CONTROL"
}
]
}
将该策略写入后，就可以读取对象了
aws s3api put-object-acl --bucket teamssix --key flag --access-control-policy file://acl.json
Bucket 策略可写
修改策略获得敏感文件
现有以下 Bucket 策略
可以看到根据当前配置，我们可以对 Bucket 策略进行读写，但如果想读取 s3://teamssix/flag 是被禁止的
因为当前策略允许我们写入 Bucket 策略，因此可以将策略里原来的 Deny 改为 Allow，这样就能访问到原来无法访问的内容了。
修改后的策略如下：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"s3:GetBucketPolicy",
"s3:PutBucketPolicy"
],
"Resource": [
"arn:aws:s3:::teamssix"
]
},
{
"Effect": "Allow",
"Principal": {
"AWS": [
"*"
]
},
"Action": [
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::teamssix/flag"
]
}
]
}
这里将第 20 行由原来的 Deny 改成了 Allow
当策略写入后，可以看到成功获取到了原本 Deny 的内容
修改网站引用的 s3 资源进行钓鱼
例如这样的一个页面
查看源代码可以看到引用了 s3 上的资源
查看 Bucket 策略，发现该 s3 的 Bucket 是可读可写的
这时我们可以修改 Bucket 的静态文件，使用户输入账号密码的时候，将账号密码传到我们的服务器上
当用户输入账号密码时，我们的服务器就会收到请求了
修改 Bucket 策略为 Deny 使业务瘫痪
当策略可写的时候，除了上面的将可原本不可访问的数据设置为可访问从而获得敏感数据外，也可以将原本可访问的资源权限设置为不可访问.
也就是说如果目标网站引用了某个 s3 上的资源文件，而且我们可以对该策略进行读写的话，就可以将原本可访问的资源权限设置为不可访问，这样就会导致网站瘫痪了。
例如这里将策略设置为 Deny
当策略 PUT 上去后，网站业务就无法正常使用了
Bucket Object 遍历
在 s3 中如果在 Bucket 策略处，设置了 s3:ListBucket 的策略，就会导致 Bucket Object 遍历
将 Key 里的值拼接到目标站点后，就能访问该 Bucket 里相应的对象了
特定的 Bucket 策略配置
有些 Bucket 会将策略配置成只允许某些特定条件才允许访问，当我们知道这个策略后，就可以访问该 Bucket 的相关对象了。
例如下面这个策略：
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "TeamsSixFlagPolicy",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::teamssix/flag",
"Condition": {
"StringLike": {
"aws:UserAgent": "TeamsSix"
}
}
}
]
}
当直接访问 teamssix/flag 的时候会提示 AccessDenied
而加上对应的 User-Agent 时，就可以正常访问了
在实战中，可以去尝试读取对方的策略，如果对方策略没做读取的限制，也许就能读到。
其次在进行信息收集的时候，可以留意一下对方可能会使用什么策略，然后再去尝试访问看看那些原本是 AccessDenied 的对象是否能够正常访问。
EC2 弹性计算
EC2 所面临的风险
1、凭证泄露
云场景下的凭证泄露可以分成以下几种：
- 控制台账号密码泄露，例如登录控制台的账号密码
- 临时凭证泄露
- 访问密钥泄露，即 AccessKeyId、SecretAccessKey 泄露
- 实例登录凭证泄露，例如 AWS 在创建 EC2 生成的证书文件遭到泄露
对于这类凭证信息的收集，一般可以通过以下几种方法进行收集：
- Github 敏感信息搜索
- 反编译目标 APK、小程序
- 目标网站源代码泄露
2、元数据
元数据服务是一种提供查询运行中的实例内元数据的服务，当实例向元数据服务发起请求时，该请求不会通过网络传输，如果获得了目标 EC2 权限或者目标 EC2 存在 SSRF 漏洞，就可以获得到实例的元数据。
在云场景下可以通过元数据进行临时凭证和其他信息的收集，在 AWS 下的元数据地址为：http://169.254.169.254/latest/meta-data/，直接 curl 请求该地址即可。
通过元数据，攻击者除了可以获得 EC2 上的一些属性信息之外，有时还可以获得与该实例绑定角色的临时凭证，并通过该临时凭证获得云服务器的控制台权限，进而横向到其他机器。
通过访问元数据的 /iam/security-credentials/<rolename> 路径可以获得目标的临时凭证，进而接管目标服务器控制台账号权限，前提是目标需要配置 IAM 角色才行，不然访问会 404
curl http://169.254.169.254/latest/meta-data/iam/security-credentials
通过元数据获得目标的临时凭证后，就可以接管目标账号权限了，这里介绍一些对于 RT 而言价值相对较高的元数据：
mac 实例 MAC 地址
hostname 实例主机名
iam/info 获取角色名称
local-ipv4 实例本地 IP
public-ipv4 实例公网 IP
instance-id 实例 ID
public-hostname 接口的公有 DNS (IPv4)
placement/region 实例的 AWS 区域
public-keys/0/openssh-key 公有密钥
/iam/security-credentials/<rolename> 获取角色的临时凭证
3、账号劫持
如果云厂商的控制台存在漏洞的话，用户账号也会存在一定的风险。
例如 AWS 的控制台曾经出现过一些 XSS 漏洞，攻击者就可能会使用这些 XSS 漏洞进行账号劫持，从而获得目标云服务器实例的权限。
4、恶意的镜像
AWS 在创建实例的时候，用户可以选择使用公共镜像或者自定义镜像，如果这些镜像中有恶意的镜像，那么目标使用该镜像创建实例就会产生风险。
以 CVE-2018-15869 为例，关于该漏洞的解释是：当人们通过 AWS 命令行使用「ec2 describe-images」功能时如果没有指定 --owners 参数，可能会在无意中加载恶意的 Amazon 系统镜像 ( AMI），导致 EC2 被用来挖矿。
对此，在使用 AWS 命令行时应该确保自己使用的是不是最新版的 AWS 命令行，同时确保从可信的来源去获取 Amazon 系统镜像。
5、其他的初始访问方法
除了以上云场景下的方法外，还可以通过云服务上的应用程序漏洞、SSH 与 RDP 的弱密码等传统场景下的方法进入目标实例。
AWS 控制台接管
如果拿到了 AWS 凭证，可以进行控制台的接管，这里以 pacu 工具为例。
关于 AWS 凭证的获取可以看 EC2 所面临的风险 部分的内容
pacu 工具里包含了很多 AWS 利用模块，首先使用 set_keys 命令将刚才获取到的 key 值添加到工具里。
接下来输入 console 命令，得到一个 URL。
将该 URL 粘贴到浏览器，就可以访问到目标的控制台了，这时就可以做很多操作了，比如连接到实例上执行命令。
在 pacu 下使用 list 还可以查看到其他的模块，例如使用run ec2__enum可以枚举出当前账号下的所有的 EC2
云服务器 SSRF 漏洞到接管你的阿里云控制台
利用SSRF窃取用户凭证，添加用户登录对方系统
111
使用用户数据执行命令
前言
在创建云服务器时，用户可以通过指定自定义数据，进行配置实例，当云服务器启动时，自定义数据将以文本的方式传递到云服务器中，并执行该文本，而且文本里的命令默认以 root 权限执行。
通过这一功能，攻击者可以修改实例的用户数据并向其中写入待执行的命令，这些代码将会在实例每次启动时自动执行。
控制台
在控制台界面可以直接编辑实例的用户数据。
在 AWS 下，修改用户数据需要停止实例，在 AWS 下停止实例会擦除实例存储卷上的所有数据，如果没设置弹性 IP，实例的公有 IP 也会变化，因此停止实例需谨慎。
修改用户数据的位置在：操作-> 实例设置->编辑用户数据