浅析OSS存储桶漏洞
环境搭建
搭建一个阿里云OSS,可以选择试用
访问存储桶的几种场景
- 这种有key id等等数据的就算成功访问了,说明该存储桶配置为了公开的,而且允许了文件路径列出 “只读(包含ListObject)”
- 这种是有权访问,但是文件路径不正确
- 403拒绝访问,这种有很多可能性:可能是没有权限访问,配置为了私有需要身份认证、文件路径不对、目前没有任何文件、特定的Bucket策略限制,后面专门详细解释。
- 这种是存储桶虽然是公开的,但是是该存储桶目前没有任何文件,且开启了文件列出(ListObject)权限
- 这种是不存在这个存储桶
- 这种是存储桶名无效
漏洞分析
接下来介绍几种不安全配置导致的安全漏洞:
如果配置为公共读/公共读写,那么所有人可以不用经过身份验证就可以访问存储桶的数据
oss凭证泄露
- 可以直接看我博客这篇文章
https://x1lys.github.io/2024/07/12/%E4%BA%91%E4%B8%BB%E6%9C%BA%E5%AF%86%E9%92%A5%E6%B3%84%E9%9C%B2/
OSS存储桶路径列出
- 如果配置为公共读/公共读写,且权限控制中的Bucket授权策略配置了”只读(包含ListObject)”,那么访问存储桶会直接列出所有文件路径(Key),类似于Apache的目录遍历漏洞,都是配置错误的原因。那就不用爆破存储桶文件名路径了,只需提取出路径来访问就行
- 当文件太多,一个一个手动去拼接访问链接太慢了,可以用这个工具,提取文件的具体路径
OSS爆破
如果配置为公共读/公共读写,但知道的信息很少,想得到更多的数据,还可以试试爆破来碰碰运气。
1. 存储桶名爆破
对存储桶名的爆破其实就是对子域名的爆破,因为存储桶名会被用来作为子域名,通过查看响应得知是否成功。但是其实如果都不知道目标的存储桶的名字,那么想单纯靠爆破的方式得到目标的存储桶名,几乎是不可能的,除非目标的存储桶名有规律,比如以企业名+其他标识为存储桶名的话可能还有一丝丝希望,不过也难。又但是,一般情况下,存储桶名很容易就得到了:访问存储桶的文件看子域名,查看响应包,FindSomeThing插件就可直接得到了
2. 存储桶文件名路径爆破
可以尝试一些常见的文件名比如1.pdf 1.docx test.jpg 等等,准备好字典跑就完事
说明oss配置为了私有,需要经过身份验证或者满足配置的特定Bucket策略才可以访问。还有一种可能是,该存储桶虽然是公开的,但是是你不知道文件的访问路径,或者该存储桶目前没有任何文件,且关闭了文件列出(ListObject)权限
403的场景与绕过
上图出现了403 AccessDenied,有如下几种情况:
存储桶被配置为了私有
需要带上正确的身份验证参数才能访问,这种情况直接跳过,没法利用了,除非通过泄露达到了ak sk等等身份验证数据
不知道文件路径key
这种情况是,明明存储桶是公开的,但是不知道文件路径的话,且没有开启文件列出(ListObject)权限,也会出现403 AccessDenied
这种就按照上面提到的直接爆破文件名就行
如果开启了文件列出(ListObject)权限,会是这样
当前存储桶没有文件
这种情况还是和”不知道文件路径key”的情况差不多,也会出现403 AccessDenied,存储桶不一定就是私有的
存储桶地点错误
如果存储桶端点错误,也会出现403 AccessDenied,但存储桶不一定就是私有的,它会出现提示,给出正确的地点,只需要改为正确的地点访问就行,改为正确地点后,再根据响应包进行判断
特定的Bucket策略配置绕过
如果管理员设置了某些IP,UA才可以请求该存储桶的话,访问时还是会出现这种403 AccessDenied,但存储桶不一定就是私有的。也就是需要满足特定的Bucket策略才可能访问,有办法绕过吗?有的:如果错误的配置了GetBucketPolicy,可导致攻击者获取策略配置,那么直接改成特定的Bucket策略不就行了吗,于是我们使用aliyun cli官方工具查看存储桶的特定配置:
安装阿里云 CLI
- 下载并解压阿里云 CLI:
1 | curl -sS https://aliyuncli.alicdn.com/aliyun-cli-linux-latest-amd64.tgz | tar -xz |
- 移动
aliyun
可执行文件到/usr/local/bin
目录:
1 | sudo mv aliyun /usr/local/bin/ |
配置阿里云 CLI
- 配置阿里云 CLI:
1 | aliyun configure |
配置过程中,您需要提供以下信息:
- Access Key ID:您的阿里云 Access Key ID
- Access Key Secret:您的阿里云 Access Key Secret
- Default Region Name:您想要使用的默认区域,例如
cn-hangzhou
- Output Format:输出格式,通常选择
json
或text
查看 OSS 存储桶策略
- 使用以下命令查看 OSS 存储桶策略:
1 | aliyun oss get-bucket-policy --bucket-name <your-bucket-name> |
将 <your-bucket-name>
替换为您实际的 OSS 存储桶名称。
修改为正确的配置
比如,策略限制了只能本地访问,只能某个UA头访问,等等其他的根据策略来修改请求包即可
到这里,那可能就有师傅要问了,既然需要知道AK/SK才能查看存储桶策略配置,那为什么不直接使用oss-browser工具+AK/SK直接就接管了存储桶了,为什么还要利用AK/SK,查看存储桶策略配置,再修改为正确的策略,再获取存储桶的信息呢?好问题哈哈
一个是手工,一个是工具,就这么简单,只是oss-browser工具已经帮我们封装了这些操作而已,于是这些手工操作还是需要了解的
任意文件上传与覆盖
如果在配置存储桶时,管理员错误的将存储桶权限,配置为可写,这将会导致攻击者可上传任意文件到存储桶中,或覆盖已经存在的文件
- 懒得放图了,借用一下云安全知识库的图
OSS-CNAME接管
CNAME 记录
- CNAME 记录是一种 DNS 记录类型,用于将一个域名的请求指向另一个域名。例如,将
cdn.example.com
指向oss-bucket-name.oss-cn-region.aliyuncs.com
案例解释
场景描述
域名绑定和存储桶删除
- 管理员将一个域名(如
example.com
)通过 CNAME 记录绑定到一个 OSS 存储桶(如my-bucket
)。 - 管理员删除了存储桶
my-bucket
,但没有删除域名解析中的 CNAME 记录。 - 现在访问
example.com
时,会显示NoSuchBucket
错误,因为存储桶my-bucket
不存在。
- 管理员将一个域名(如
接管存储桶
- 创建同名存储桶:
- 您使用自己的阿里云账号,创建一个与被删除存储桶相同名称的新存储桶(
my-bucket
)。
- 您使用自己的阿里云账号,创建一个与被删除存储桶相同名称的新存储桶(
- 域名解析生效:
- 由于 CNAME 记录仍然存在且指向
my-bucket
,当您创建了同名存储桶后,访问example.com
的请求将指向您新创建的存储桶。 - 这实际上“接管”了原先绑定到该域名的存储桶,因为域名解析会指向新创建的存储桶。
- 由于 CNAME 记录仍然存在且指向
验证接管
- 验证访问
- 访问
example.com
,现在不会再显示NoSuchBucket
错误,而是指向您创建的新存储桶。 - 您可以上传文件并配置权限,验证您已经成功接管了该存储桶。
- 访问
举例说明
假设以下场景:
- 原始配置:
- 域名:
example.com
- 原存储桶名称:
my-bucket
- CNAME 记录:
example.com
→my-bucket.oss-cn-region.aliyuncs.com
- 域名:
- 存储桶被删除后:
- 访问
example.com
时,显示NoSuchBucket
错误。
- 访问
- 接管过程:
- 您登录自己的阿里云账号,创建一个同名的存储桶
my-bucket
。 - 由于 CNAME 记录没有更改,访问
example.com
时,现在指向您创建的新存储桶。
- 您登录自己的阿里云账号,创建一个同名的存储桶
- 接管验证:
- 访问
example.com
,可以正常访问存储桶内容。 - 您可以上传文件并设置权限,确认已成功接管。
- 访问
Bucket 策略配置可写
当我们访问存储桶的时候,会提示我们已经被policy拦截
如果此时配置了存储桶的oss:PutBucketPolicy,就可以更改Deny为Allow即可访问
随后使用PUT方法上传
修改策略导致网站瘫痪
还是当策略可写的时候,除了上面的将可原本不可访问的数据设置为可访问从而获得敏感数据外,如果目标网站引用了某个存储桶上的资源文件,而且我们可以对该策略进行读写的话,也可以将原本可访问的资源权限设置为不可访问,这样就会使得该图片,js资源无法被加载到网站,导致网站瘫痪了。
实战案例
我在一次hvv中,就遇到了OSS公开访问并存在存储路径列出的漏洞,当时列出的文件特别多,浏览器都卡爆了,但是大部分都是非敏感的图片文件,其他文件不多,但是手动找也很费劲,于是为了找敏感信息,我就写了个脚本,访问并下载指定后缀的文件到本地,最终经过一顿乱翻,终于找到了xxxxxxx.txt文件,得到了一个系统的URL和SSO账号密码!而且这个系统是整个省的某个主系统,控制着该省每一个市的子系统,权限很高……进一步测试了下,没发现漏洞,系统的数据也不算敏感数据,于是就只拿了SSO权限分
这是当时的小脚本:
1 | import requests |
漏洞修复
未授权访问
- 描述:存储桶和对象的访问权限配置不当,导致未授权用户可以访问敏感数据。
- 修复与防御
- 确保存储桶和对象的权限配置正确,仅允许授权用户访问。
- 定期审查和更新存储桶策略和 ACL(访问控制列表)。
- 使用存储桶策略限制特定 IP 或者特定用户组的访问。
公开存储桶
描述:存储桶被错误配置为公开访问,任何人都可以读取存储桶中的内容。
修复与防御
确保存储桶默认设置为私有。
使用工具(如阿里云控制台或 CLI)检查和修复公开访问的存储桶:
1
aliyun oss set-bucket-acl --bucket-name <your-bucket-name> --acl private
CORS 漏洞
描述:跨域资源共享(CORS)配置不当,导致数据泄露或被恶意网站利用。
修复与防御
仅允许受信任的域名进行跨域访问。
定期审查和更新 CORS 配置。
示例 CORS 配置:
1
2
3
4
5
6
7
8
9[
{
"AllowedOrigin": ["https://trusted.com"],
"AllowedMethod": ["GET", "POST"],
"AllowedHeader": ["*"],
"ExposeHeader": ["ETag"],
"MaxAgeSeconds": 3000
}
]使用阿里云 CLI 设置 CORS 配置:
1
aliyun oss set-bucket-cors --bucket-name <your-bucket-name> --cors-configuration file://cors.json
存储桶劫持
- 描述:由于 CNAME 解析错误或存储桶名称被删除重建,导致存储桶被恶意用户接管。
- 修复与防御
- 删除存储桶时,确保相应的 CNAME 记录也被删除。
- 定期检查和更新 DNS 配置,确保其指向正确的存储桶。
- 启用域名绑定管理,防止未授权的域名绑定到存储桶。
总结
通过以下措施可以有效防御和修复 OSS 配置中的常见漏洞:
- 定期审查和更新存储桶策略和 ACL。
- 确保存储桶默认设置为私有,并检查公开访问的存储桶。
- 仅允许受信任的域名进行跨域访问,并定期审查 CORS 配置。
- 删除存储桶时,确保相应的 CNAME 记录也被删除,并启用域名绑定管理。
- 启用服务器端加密,确保数据在存储时被加密。
参考:https://cloudsec.huoxian.cn/docs/articles/aliyun/aliyun_oss