当不知道 Bucket 名称的时候,可以通过爆破获得 Bucket 名称,这有些类似于目录爆破,只不过目录爆破一般通过状态码判断,而这个通过页面的内容判断。
当对于阿里云OSS 不存在有两种返回情况,分别是
当存储桶存在时,则会返回以下两种情况,
这样通过返回内容的不同,就可以进行 Bucket 名称爆破了,知道 Bucket 名称后,Key 的爆破也就很容易了。
参考链接:
https://zone.huoxian.cn/d/918-oss
如果设置了ListObject,这将会导致Bucket桶被遍历。
如果在配置存储桶时,管理员错误的将存储桶权限,配置为可写,这将会导致攻击者可上传任意文件到存储桶中,或覆盖已经存在的文件。
如果目标的对象存储支持 html 解析,那就可以利用任意文件上传进行 XSS 钓鱼、挂暗链、挂黑页、供应链投毒等操作。
需要注意的是,2018年8月13日之后开启的Bucket,直接使用OSS访问域名,从互联网访问OSS上的htm、 html、jsp、plg、htx 和stm类型文件时,都会被阿里云直接强制下载。想要访问自己的Buncket中的静态页面,则需要给这个Buncket配域名。
如果管理员通过域名解析并绑定了一个存储桶,但是管理员将存储桶删除后,没有将域名解析的CNAME删除,这时会访问旧域名就会出现报错,NoSuchBucket。
这个时候可以登录自己的阿里云账号,创建同样的名称即可成功接管了该存储桶。
在使用存储桶进行对象读取或写入操作时,如果没有合理的或者错误的在Policy中配置用户允许访问的资源路径(resource),则会出现越权访问,导致用户数据被恶意上传覆盖或被其他用户下载等安全问题。
在Web应用开发中,经常会发生此类问题。设想以下场景:在一个Web应用使用对象存储来存储用户头像,且通过前端直传的方式将用户上传的头像传至存储桶中,并希望在存储桶/avatar/路径中存储桶用户的头像,由于后端开发时为了方便而进行了不规范的存储桶Policy配置,在生成用户用以上传头像的临时密钥时直接将此临时密钥允许访问的 resource 指定为 qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/*路径。
这样以来,系统为每个用户所生成的用以上传以及浏览头像的临时密钥虽然不尽相同,但是这个临时密钥都拥有qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/*路径中的所有资源的读写权限。
这一错误的配置导致了很多严重的安全问题,由于在此场景下,Web应用程序使用前端直传的方式访问存储桶,因此后台生成的临时密钥将会发送给前台,任意用户通过网络抓包等手段获取到的临时凭据,可参见下图流量中响应包内容。
在获取了临时密钥之后,攻击者凭借此凭据读写qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/*路径中的任意对象。
攻击者可以通过此方式覆盖目录中其他用户资源,见下图:
上图攻击者通过test.txt文件覆盖了16.png。当然,攻击者也可以轻易的读取此目录中其他用户的文件。
针对此问题的修复方式如下:可以通过每个用户的用户标识来为每一个用户设置一个独用的路径,例如可以在为用户生成临时密钥时,将policy中resource 指定为 qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/<Username>/*来满足规范要求;此外,resource 字段支持以数组的形式传入多个值。因此,也可以显式指定多个 resource 值来完全限定用户有权限访问的最终资源路径。
参考链接:
https://mp.weixin.qq.com/s/ncWGrMsIAvh9HEK1QC5IGQ