浅析云服务ossobscos对象存储安全攻防

admin 管理员组

文章数量: 887017

文章目录

• 前言
• 云存储服务
• • 1.1 初识对象存储
  • 1.2 腾讯云COS桶
  • 1.3 公开读取风险
• 对象存储桶风险
• • 2.1 Bucket Object遍历
  • 2.2 Bucket 名称的爆破
  • 2.3 Bucket ACL可读写
  • 2.4 任意写与文件覆盖
  • 2.5 Bucket 域名的接管
• AccessKey凭证泄露
• • 3.1 行云管家接管主机
  • 3.2 Github泄露AK/SK
  • 3.3 客户端程序泄露SK
  • 3.4 文件上传功能泄露
• 总结

前言

云服务至今已经发展成为各大企业青睐的部署自家应用服务的选择，云主机在为企业避免了自行搭建物理机房的高昂成本的同时，也提供了更为便捷的服务器运维管理、安全防护服务。这也就使得渗透人员在工作中不得不关注云上服务器的一些攻击面，同时也需要从关注传统的内网物理主机渗透切换到云上服务器的横向渗透。

为了方便理解本文所要重点讲述的云上对象存储服务，先来看看一张关于阿里云企业上云网络架构解决方案图（源自：阿里云企业上云网络架构解决方法）：

本架构方案采用跨可用区部署方式，实现故障恢复和高可用，涉及云产品有阿里云服务器ECS、负载均衡SLB、云数据库RDS、对象存储OSS、Redis、PTS和ARMS。

1. 云服务器ECS：阿里云明星产品，上云必备；
2. 负载均衡SLB：SLB用于提高系统高可用性和高并发负载能力的有效手段之一，通过将业务负载分按策略分发到后端多台应用服务器以应对高并发流量给整个系统带来的访问压力同时避免服务器的单点故障引起额业务中断，SLB自身也可以部署在同一地域的不同可用区自身具备高可用属性；
3. 云数据库RDS：云数据库可以部署在同一地域的不同可用区，实现数据库主备的高可用架构，同时可以根据业务需要开通只读节点，分担主数据库的业务压力，增加应用的吞吐量；
4. 对象存储OSS：OSS承载静态内容，通过阿里云CDN进行分发，当CDN的缓存未命中时进行OSS回源；
5. Redis：Redis作为底层数据库的缓存，可以有效降低数据响应时间，提高吞吐量和并发处理能力，降低后端数据库负载，提升整体业务处理性能；
6. PTS和ARMS：PTS和ARMS组合适合在互联网业务上线前以及应对大促活动等高流量业务前测试业务系统能否达到预期设计性能，找出性能瓶颈。

本文所要讨论的重点是对象存储服务，云上存储己经是企业中常见的一款云上产品，伴随着云上业务的发展，对象存储作为云原生一项重要的能力，暴露出一系列的安全问题，其中的权限配置是管理人员不可忽视的，本文将从攻击者的视角来看几大云存储的攻击方法与利用。

云存储服务

此处先附上 TeamsSix 大佬整理的《攻防矩阵 | 云安全知识库》，梳理了云安全攻防的攻击矩阵，并给出了几大云服务厂商（腾讯云、阿里云、华为云等）的云服务器攻防实践指导。

从该材料中也不难发现，几大云服务厂商的云存储服务存在的攻击面和利用手段基本上是一致的，故本文将只介绍并实践其中一个厂商（腾讯云）的云存储服务功能和攻击面。

1.1 初识对象存储

几大云厂商关于对象存储的概念简称上的一些区别：

看看阿里云官方文档如何解释对象存储的概念：


下面摘自华为云对 OBS 服务的架构解释：


相关概念参见官方文档最为准确，此处不扩展解释。

1.2 腾讯云COS桶

本文的大部分演示将基于腾讯云 COS 云对象存储服务，原因很简单，腾讯云 COS 支持为新人提供 50 G 容量的一年免费体验服务 hh，而阿里云则默认最低购买 1 年 500G 起步的 OSS 服务，价值近 120 元……

同时腾讯云 COS 提供了多种服务实例管理方式：

进入管理台创建存储桶（Bucket）实例，可以看到腾讯云会为我们的桶实例分配一个相应的域名，同时我们需要设置该存储桶的访问权限：

同时提供了版本控制、日志存储等服务：

我先默认不勾选上述附加配置项（后续需要还可以在管理台中进行动态修改），直接确认并创建桶：

创建完毕即可开始上传我们的文件：

1.3 公开读取风险

上传完文件，访问我的 COS 桶域名：https://tr0e-1302654076.cos.ap-guangzhou.myqcloud/ 以及 Tr0e.jpg 资源文件，可以看到是无权限访问“Access Denied.”，因为我刚才创建该 COS 桶的时候选择的是“私有读写”模式：


我们到管理台修改为“公有读私有写”的访问权限控制模式试试，发现提示开启该模式可能导致“外网下行流量费用”：

查看指导链接看看这个流量费用是个什么鬼……

好家伙，言下之意如果我开启“公有读私有写”的访问权限控制模式，恶意攻击者不仅可以看到我的 COS 桶数据，还能通过下载桶里面的对象文件来造成我的流量计费导致资金损失……

此处为了学习用，继续确认并开启“公有读私有写”的访问权限控制模式：

然后便可以在公网正常访问到 COS 桶里面的资源文件：

但是访问 COS 桶域名：https://tr0e-1302654076.cos.ap-guangzhou.myqcloud/ 的话依旧是拒绝访问状态（除非进一步配置 Policy 策略放开资源对象列表，否则访问 COS 桶域名将不会回显桶中资源信息，下文会进一步演示）：

从上面可以看到，如果运维人员错误地开放了 COS 桶的权限控制权限，那么将把 COS 桶中的文件暴露在公网之中，如果这是企业私密的资源文件（比如客户的身份证证件等），那么将产生严重的安全风险。

但是整体来说，腾讯云对于此高危操作的风控策略还是可以的，不仅用明显的告警信息告知用户可能造成的安全风险和资金损失，同时在开启此不安全配置的同时进行了扫码或短信验证的二次确认。

【注意】需要特别说明的是，也并非所有的 COS 桶都是设置为私有模式，比如有些 COS 桶就被企业正常用于静态网站资源的托管（完整指导文档可以参见：对象存储 托管静态网站-开发者指南-文档中心-腾讯云）：

对象存储桶风险

当腾讯云 COS 收到资源文件请求时，首先会确认请求者身份，并验证请求者是否拥有相关权限，验证的过程包括检查用户组策略、存储桶访问策略（Policy）和存储桶访问控制列表（ACL），对请求进行鉴权。

但是如果管理员进行了错误的访问控制配置，或者存在相关访问控制凭证信息泄露，将导致整个 COS 桶的资源文件存在暴露给攻击者的风险，下面来看看都有哪几类核心威胁。

2.1 Bucket Object遍历

如果运维人员在给 COS 桶开启“公有读私有写”的访问权限控制模式的同时，添加 Policy 策略允许“读操作（含列出对象列表）”的话，那么将允许访问 COS 桶域名的时候列举出该桶所有对象信息：



此时重新访问 COS 桶公网域名，将看到所有资源文件对象的信息：

通过获取的 Key 值，可以遍历访问、下载桶中的所有资源文件：

故运维人员轻易不要在给 COS 桶开启“公有读私有写”的访问权限控制模式的同时，添加 Policy 策略允许“读操作（含列出对象列表）”。

2.2 Bucket 名称的爆破

总结一下，对于 https://tr0e-1302654076.cos.ap-guangzhou.myqcloud/666.jpg：

1. Bucket 名称为：tr0e-1302654076；
2. 所访问的资源对象的 Key 为：666.jpg；

当我们访问的 COS 存储桶地址（比如 Bucket 名称）不存在时，返回的 Message 为 “NoSuchBucket”：

当输入的 COS 存储桶地址格式不正确时，返回的 Message 为 “InvalidRequest”（表示存储桶的名称不符合规范，属于无效的存储桶名称）：

这样通过返回内容的不同，就可以进行 Bucket 名称爆破了，知道 Bucket 名称后，Key 的爆破也就很容易了。

2.3 Bucket ACL可读写

在上面“Bucket Object 遍历”章节中实际上也可以看到，添加 Policy 策略的时候，添加的策略还可以包括如下诸多选项：


我们添加 ACL 读权限和 ACL 写权限，然后访问 /?acl （URI 可参见官方接口说明文档：对象存储 GET Bucket acl-API 文档-腾讯云） 即可看到当前的 ACL 策略：

查看官方说明文档（对象存储 ACL 访问控制实践-文档中心-腾讯云）可知 FULL_CONTROL 代表的含义：

也就是意味着当前 ACL 策略是所有人都能对存储桶和对象进行任意操作，此时存储桶是设置为私有读写状态的：
但是由于 ACL 策略开放为任意人可以读写，那么我可以借助修改 ACL 的 API 接口给 Bucket 添加访问策略（URI 可参见官方接口说明文档：对象存储 PUT Bucket acl-API 文档-文档中心-腾讯云），将“私有读写”模式改写为“公开读私有写”，如下：

PUT /?acl HTTP/1.1
Host: tr0e-1302654076.cos.ap-guangzhou.myqcloud
x-cos-acl: public-read
Cache-Control: max-age=0
Sec-Ch-Ua: "Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close

此时再访问 Bucket 对应 Object 地址，即可读取到所存储对象的信息：

同时到管理台中也可以看到存储桶的访问权限被改写了：

值得注意的是，通过这种方法修改 Bucket 访问规则并不像在管理台手动修改桶配置一样需要要求用户进行二次安全验证，故此未授权篡改 ACL 规则漏洞的危害更为巨大。同时攻击者也可以修改修改访问策略，比如将 Bucket 的“公开读”访问控制规则（前面已经提到了对于部分业务需要将 Bucket 作为静态网站资源开放到公网） 修改为“私有读写”，来实现拒绝服务攻击。

由此可见，管理人员在对 Bucket 进行策略配置管理的时候一定要小心谨慎配置 ACL 管理规则，不能错误地将 Bucket 桶的权限管理能力公开暴露给任意访问者。

2.4 任意写与文件覆盖

由于 Bucket 不支持 Object 重复命名，所以当匿名用户拥有写入权限时，通过 PUT 请求可上传和覆盖原有任意文件。

PUT /666.jpg HTTP/1.1
Host: tr0e-1302654076.cos.ap-guangzhou.myqcloud
Cache-Control: max-age=0
Sec-Ch-Ua: "Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua-Platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Connection: close
Content-Length: 12

Tr0e66666666

此时原有的 666.jpg 图片便被覆盖了：


奇安信安全社区有篇文章《奇安信攻防社区-实战阿里云OSS云攻防》分享了一个 OSS 桶任意写导致文件覆盖的实战案例，有意思的是作者发现该 Bucket 地址与目标站点一个静态资源网址存在映射关联关系，覆写桶数据会影响到相应静态资源网页的数据，故给出了如下攻击利用链路：

2.5 Bucket 域名的接管

这部分参见文章：《云安全｜子域名接管漏洞 | 霜刃安全》和 《阿里云 OSS 对象存储攻防 | 云安全知识库 》

子域名接管漏洞，简单来说通过该漏洞可以接管目标子域名，让其显示攻击者设置的页面，主要用于网络钓鱼。如伪造钓鱼页面，还可以利用其盗取 Cookie，伪造电子邮件等。

其大致攻击场景为:

1. 受害者曾经为目标域名设置了 cname 记录（别名记录，该记录允许将多个域名映射到同一个域名，常用于 CDN），比如设置了 a.aliyun 指向 b.oss-cn-aliyuncs；
2. 那么当受害者使用完 b.oss-cn-aliyuncs 这个网站后，将域名删除，但是忘记了删除 a.aliyun 这个 cname 记录；
3. 那么此时 a.aliyun 仍会解析到 b.oss-cn-aliyuncs，但是 b.oss-cn-aliyuncs 已经被删除了，那么此时便可以申请一个域名 b.oss-cn-aliyuncs，放上恶意文件，这样就成功接管了 a.aliyun 这个域名。

可能会出现这种漏洞的网站有很多，如常见的 Github（也就是github.io）、常见的 OSS/COS/OBS 对象存储平台等。我们可以使用 subtake 工具（https://github/jakejarvis/subtake）来快速的检查多种网站是否存在子域名接管漏洞。

【腾讯云 COS 不存在存储桶域名接管】

Bucket 域名接管就是由于管理人员未删除指向该服务的 DNS 记录，攻击者通过创建同名 Bucket 进而让受害域名解析到攻击者所指向的网站域名所造成的，这其中的关键点在于攻击者是否可创建同名 Bucket，腾讯云有特定的存储桶命名格式，即：
<BucketName-APPID>.cos.<Region>.myqcloud
而 appid 是在控制台用时间戳随机生成的，因此无法创建同名 Bucket，故腾讯云不存在 Bucket 接管问题：

但是腾讯云是提供 COS 桶域名的自定义映射的：对象存储开启自定义 CDN 加速域名-文档中心-腾讯云。

【阿里云 OSS 存在存储桶域名接管】

在阿里云下，当 Bucket 显示 NoSuchBucket 说明是可以接管的，如果显示 AccessDenied 则不行。
假设有以下一种情况，管理员通过域名解析并绑定了一个存储桶，但是管理员将存储桶删除后，没有将域名解析的 CNAME 删除，这时会访问域名就会出现上面的情况，NoSuchBucket。

首先发现一个报错页面（比如 abc.aliyun），在报错页面发现了 HostId 和 BucketName 两个字段，并且通过这两个字段我们知道他是使用阿里云对象存储提供服务的，并且给了 OSS 存储对象的名称。然后我们进入自己的阿里云，进入 OSS 存储对象，创建一个新的 Bucket，这里 Bucket 名称选择我们刚刚从报错页面中得到的 HostId 字段，注意下面的地区，我们在 HostID 或 URL 中可以得到关于地区的信息，要选择相同的地区。
然后将权限设置为公共读写：

此时我们便完成了对子域名的接管，我们尝试上传一个文件试试：

可以看到已经成功访问到了我们上传的 a.txt：

进一步地也就可以借助我们申请到的 Buncket 域名对受害域名（如 abc.aliyun） 进行钓鱼攻击。

最后补充一篇 SRC 文章：《【SRC挖洞经验】Amazon S3 Bucket桶接管教程》，介绍了 Amazon 云的对象存储 Bucket 桶接管的案例，赏金说是国外 100-1000 美金，还是相对有实际价值的漏洞。

AccessKey凭证泄露

几乎所有云厂商的云主机都支持通过使用 AccessKeyId、SecretAccessKey 加密的方法来验证某个请求的发送者身份。AccessKeyId（AK）用于标示用户，SecretAccessKey（SK）用于用户加密认证字符串和云厂商用来验证认证字符串的密钥，其中 SK 必须保密。

AK/SK 鉴权机制使用对称加解密。云主机接收到用户的请求后，系统将使用 AK 对应的相同的 SK 和同样的认证机制生成认证字符串（基于HMAC 算法对签名字符串进行加密后产生），并与用户请求中包含的认证字符串进行比对。如果认证字符串相同，系统认为用户拥有指定的操作权限，并执行相关操作；如果认证字符串不同，系统将忽略该操作并返回错误码。

因此如果目标的 AccessKeyId、SecretAccessKey 泄露，那么就能伪造用户身份接管云主机，获取到目标对象存储的所有权限。这其实也是对象存储桶的安全风险之一，本文将其作为一个独立的章节进行阐述是因为此类凭证信息泄露的渠道较多，同时在实战中较为常见且危害巨大。

3.1 行云管家接管主机

腾讯云 AK/SK 申请地址：腾讯云-API密钥管理，API 密钥代表用户的账号身份和所拥有的权限，使用腾讯云 API 可以操作用户名下的所有腾讯云资源，腾讯云给了很贴心的安全风险提示：

为了避免用户使用固定时密钥密钥泄露带来的安全风险，腾讯云引入了临时密钥来替换固定密钥，具体可参见：对象存储 临时密钥生成及使用指引-最佳实践-文档中心-腾讯云、云环境下密钥泄露导致的安全问题。

在获得用户在某云厂商的 AK、SK 的情况下，可以通过行云管家导入云主机并进行主机管理（包括主机登录密码修改），网站地址：https://yun.cloudbility/：


可进行的主机管理操作：

另外如果是腾讯云的 AccessKey，也可以使用腾讯云云主机接管平台来接管主机：https://cosbrowser.cloud.tencent/web/bucket

3.2 Github泄露AK/SK

3.3 客户端程序泄露SK

1、各类 APP 或小程序反编译的资源文件配置

2、各类网站的前端 JS 代码信息泄露

可以借助 Chrome 浏览器的插件自动寻找：Trufflehog

访问某网站，使用插件 Trufflehog 探测，会在 Findings 位置显示是否有密钥泄露：

3.4 文件上传功能泄露

渗透测试过程中可以多关注上传图片、下载文件、查看图片等等位置，说不定就有 AK、SK 泄露。

1、 比如在文件上传点，有时候抓包就直接泄露 SK 信息：
2、某小程序打开后在个人中心头像位置：

点击头像抓包，可以看到 accessKeyId、acesskeySecret 泄露：

总结

本文算是记录云安全学习的第一篇文章，主要学习了云储存服务的基础使用，实践掌握了 Bucket 对象存储服务错误配置带来的的安全风险，并重点分析了云主机 AccessKeySecret 认证凭据泄露所带来的风险。

各大云厂商的对象存储服务的攻防手段大同小异，完整的指导教程可参见 TeamsSix 大佬整理的《攻防矩阵 | 云安全知识库》，总结了全球六大云服务厂商的攻防知识，tql！

最后附上火线安全在 《云安全知识库》 提供的一张云服务攻防矩阵图最为本文结尾吧：

本文标签： 攻防 对象 OSS OBS cos