共计 4120 个字符，预计需要花费 11 分钟才能阅读完成。
文章首发于：
前线 Zone 社区（https://zone.huoxian.cn/）
对象存储（Object-Based Storage），也能够叫做面向对象的存储，当初也有不少厂商间接把它叫做云存储。
说到对象存储就不得不提 Amazon，Amazon S3 (Simple Storage Service) 简略存储服务，是 Amazon 的公开云存储服务，与之对应的协定被称为 S3 协定，目前 S3 协定曾经被视为公认的行业标准协议，因而目前国内支流的对象存储厂商基本上都会反对 S3 协定。
在 Amazon S3 规范下中，对象存储中能够有多个桶（Bucket），而后把对象（Object）放在桶里，对象又蕴含了三个局部：Key、Data 和 Metadata。
Key 是指存储桶中的惟一标识符，例如一个 URL 为：https://teamssix.s3.ap-northe…，这里的 teamssix 是存储桶 Bucket 的名称，/flag 就是 Key
Data 就很容易了解，就是存储的数据本体
Metadata 即元数据，能够简略的了解成数据的标签、形容之类的信息，这点不同于传统的文件存储，在传统的文件存储中这类信息是间接封装在文件里的，有了元数据的存在，能够大大的放慢对象的排序、分类和查找。
操作应用 Amazon S3 的形式也有很多，次要有以下几种：
AWS 控制台操作
AWS 命令行工具操作
AWS SDK 操作
REST API 操作，通过 REST API，能够应用 HTTP 申请创立、提取和删除存储桶和对象。
对于对象存储就介绍到这里，上面来看看在对象存储下的一些攻防手法。
在 Bucket 的 ACL 处，能够抉择容许那些人拜访。
如果设置为所有人可列出对象，那么只有晓得 URL 链接就能拜访，对于设置为公有的状况下，则须要有签名信息能力拜访，例如
https://teamssix.s3.ap-northe…
对于敏感文件，倡议权限设置为公有，并造就爱护签名信息的安全意识。
实践上，如果公开权限文件的名称设置的很简单，也能在肯定水平上保障平安，但不倡议这样做，对于敏感文件，设置为公有权限的安全性要更高。
当不晓得 Bucket 名称的时候，能够通过爆破取得 Bucket 名称，这有些相似于目录爆破，只不过目录爆破个别通过状态码判断，而这个通过页面的内容判断。
当 Bucket 不存在有两种返回状况，别离是 InvalidBucketName 和 NoSuchBucket。
当 Bucket 存在时也会有两种状况，一种是列出 Object。
另一种是返回 AccessDenied。
这样通过返回内容的不同，就能够进行 Bucket 名称爆破了，晓得 Bucket 名称后，Key 的爆破也就很容易了。
在 s3 中如果在 Bucket 策略处，设置了 s3:ListBucket 的策略，就会导致 Bucket Object 遍历。
在应用 MinIO 的时候，如果 Bucket 设置为公开，那么关上指标站点默认就会列出 Bucket 里所有的 Key。
将 Key 里的值拼接到指标站点后，就能拜访该 Bucket 里相应的对象了。
如果对象存储配置不当，比方公共读写，那么可能就会造成任意文件上传与文件笼罩。
如果指标的对象存储反对 html 解析，那就能够利用任意文件上传进行 XSS 钓鱼、挂暗链、挂黑页、供应链投毒等操作。
如果指标的 AccessKeyId、SecretAccessKey 泄露，那么就能获取到指标对象存储的所有权限，个别能够通过以下几种办法进行收集：
Github 敏感信息搜寻
反编译指标 APK
指标网站源代码泄露
如果在进行浸透时，发现指标的一个子域显示如下内容：
通过页面特色，能够判断出这是一个 Amazon 的 S3，而且页面显示 NoSuchBucket，阐明这个 Bucket 能够接管的，同时 Bucket 的名称在页面中也通知了咱们，为 test.teamssix.com。
那么咱们就间接在 AWS 控制台里创立一个名称为 test.teamssix.com 的 Bucket 就能够接管了。
创立完 Bucket 后，再次拜访发现就显示 AccessDenied 了，阐明该 Bucket 曾经被咱们接管了。
将该 Bucket 设置为公开，并上传个文件试试。
在该子域名下拜访这个 test.txt 文件。
能够看到通过接管 Bucket 胜利接管了这个子域名的权限。
列出指标 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 时提醒被禁止。
查看指标 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 的相干对象了。
例如上面这个策略：
{
"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 的对象是否可能失常拜访。
1. 批改策略取得敏感文件
现有以下 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 的内容：
2. 批改网站援用的 s3 资源进行钓鱼
当策略可写的时候，除了下面的将可本来不可拜访的数据设置为可拜访从而取得敏感数据外，如果指标网站援用了某个 s3 上的资源文件，而且咱们能够对该策略进行读写的话，也能够将本来可拜访的资源权限设置为不可拜访，这样就会导致网站瘫痪了。
例如这样的一个页面：
查看源代码能够看到援用了 s3 上的资源：
查看 Bucket 策略，发现该 s3 的 Bucket 策略是可读可写的。
这时咱们能够批改 Bucket 的动态文件，使用户输出账号密码的时候，将账号密码传到咱们的服务器上。
当用户输出账号密码时，咱们的服务器就会收到申请了。
3. 批改 Bucket 策略为 Deny 使业务瘫痪
除了下面的利用手法外，也能够将策略设置为 Deny。
当策略 PUT 下来后，网站业务就无奈失常应用了。
参考文章：
https://www.ithome.com/0/501/…
https://mp.weixin.qq.com/s/eZ…
https://mp.weixin.qq.com/s/r0…
https://blog.csdn.net/bandaoy…
https://docs.aws.amazon.com/z…
https://docs.aws.amazon.com/z…
https://docs.aws.amazon.com/z…