前言
如今越来越多的中小型公司选择使用云平台，诸如:阿里云、腾讯云、Amazon、Azure。使用云平台大大降低了企业的资源成本，另一方面随着公用云的普及，也存在着一些风险，当然不是由于云平台本身的安全性欠缺，而是由于使用者在调用API时没有注意安全性而导致的。最常见的问题就是AccessKey泄漏、配置不当。
正文
AccessKey（即访问密钥）是云平台用户在通过API访问云资源时用来确认用户身份的凭证，以确保访问者具有相关权限。AccessKey由云平台提供商（如亚马逊AWS、阿里云等）颁发给云主机的所有者，一般由AccessKeyID（访问密钥ID）和Secret Access Key（私有访问密钥）构成。
主账户/根用户的AccessKey具有主账户的完全权限，因此云厂商不建议直接使用主账户/根用户的AccessKey进行API调用，阿里云会建议你使用RAM子账户进行API的调用，当然这个账户是有相应权限限制的，而腾讯云cos服务除了可以生成子账户外还采用了一个CAM模型，用于生成 COS 的临时密钥。临时密钥有生效时间，作用与阿里oss的RAM子账号类似。
通过临时密钥方式，则可以方便、有效地解决权限控制问题。因为固定密钥计算签名方式不能有效地控制权限，同时把永久密钥放到客户端代码中有极大的泄露风险。从阿里oss AccessKey泄露问题便可看出，下面会讲到这个问题。
OSS AccessKey泄露
对象存储（Object Storage Service，简称OSS），是阿里云对外提供的海量、安全和高可靠的云存储服务。
通过上面描述我们知道AccessKey如果泄露就会导致用户账户被控制，常见的泄露方式有以下几种：
● APK反编译后的配置文件。
● GITHUB关键字、JS文件、FOFA等。
● 低权限的WEBSHELL查看网站的配置文件
拿到AccessKey后的利用方式
● 第三方平台，如：行云管家
● OSS Browser
● OSSUTIL
● API Explorer
OSS Browser、OSSUTIL是官方阿里云官方提供的工具只能对于OSS进行操作，API调试或者第三方平台可以直接操作ECS，甚至重置服务器。
这里演示一下OSS Browser（https://github.com/aliyun/oss-browser/blob/master/all-releases.md）对OSS的操作
阿里云 access key ID 和 access key secret 是访问阿里云API的唯一凭证。Access key ID 是类似身份的标识，而 access key secret 的作用是签名你的访问参数，以防被篡改。Access key secret 类似你的登录密码。
登陆后便可访问文件服务，并对文件进行操作
通过行云管家这样的第三方平台，我们可以进一步进行操作。同样的我们需要access key ID 和 access key secret 。
通过行云管家，不仅可以访问OSS服务，还可以直接重置服务器密码，接管服务器。
参考案例(http://r3start.net/index.php/2019/09/16/580）
COS服务 临时密钥泄露
对象存储（Cloud Object Storage，COS）是腾讯云提供的一种存储海量文件的分布式存储服务，用户可通过网络随时存储和查看数据。跟阿里云一样腾讯云的主机也有主账户和子账户之分，子账号是由主账号创建的实体，有确定的身份 ID 和身份凭证，拥有登录腾讯云控制台的权限。子账号默认不拥有资源，必须由所属主账号进行授权。与阿里云不同的是，腾讯云引入了临时密钥。
临时密钥（临时访问凭证） 是通过 CAM 云 API 提供的接口，获取到权限受限的密钥。主要是为了解决固定密钥计算签名方式不能有效地控制权限，同时把永久密钥放到客户端代码中有极大的泄露风险的问题。
腾讯云获取临时密钥的过程如下：
在这里，第四步下发临时密钥，返回的字段主要包含以下三个字段：
●TmpSecretId
●TmpSecretKey
●Token
然后利用这三个字段计算签名，获得签名后，客户端发送携带签名的请求给COS服务器，对Bucket 进行操作。
其中要是想对指定的Bucket 进行操作，我们还需要知道对应的Bucket 名称，以及所属地域Region 。
cosplay!
这里使用GEEKPWN云安全比赛的一道题作为例子来讲一下腾讯云临时密钥的利用。
题目打开是一个上传页面
这里我们随便选择一个文件上传，然后使用burp捕获一下数据包
这里发现了一个GetTempKey接口，其返回了临时密钥的相关信息
这里主要关心TmpSecretId、TmpSecretKey、Token这三个字段，因为这三个字段是计算签名的必要条件。腾讯云公布的有专门计算签名的工具。
更多关于计算签名的细节参考
官方文档(https://cloud.tencent.com/document/product/436/7778）。
这道题我们选择更简便的方式，官方还提供了COS 请求工具，
使用说明（https://cloud.tencent.com/document/product/436/30996）。
想对指定的Bucket 进行操作，我们还需要知道对应的Bucket 名称，以及所属地域Region。通过查看页面源码发现泄露了对应的Bucket 名称以及Region。
有了这些条件后我们就可以访问cos的资源了。选择使用临时密钥进行访问。x-cos-security-token的值为返回字段中Token的值。
找了一个flag.txt,查看flag.txt的内容。参数key为其所在key标签的值，类似于目录。
成功拿到flag。
通过这道题我们可以发现临时密钥的权限比较小，获取难度较大。同时临时密钥存在生效时间，默认为1800s。所以，相对于固定密钥也更为安全可靠。
其它
上面讨论的是国内的厂商，当然国外的云厂商，如Amazon的AWS，也存在很多安全问题，例如S3存储桶配置不当，泄露AccessKey后，可对S3存储桶进行增删操作，这里的S3类似于OSS、Elastic Beanstalk中利用SSRF访问元数据，获取AccessKey等一些敏感信息等等。
AWS AccessKey的获取手段：
●Github关键词查找，accessKeyId、secretAccessKey、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY。
●通过网站目录或者泄漏出来的源代码或者DEBUG信息。
●SSRF读取元数据。
●前端页源代码。
AWS常见的漏洞类型：
●AmazonS3 Bucket允许任意文件上传和读取
●AmazonS3 bucket允许匿名访问
●AmazonS3 bucket允许列出文件
●AmazonS3 bucket允许盲上传
●AmazonS3 bucket允许任意读取/写入对象
●AmazonS3 bucket显示ACP/ACL
推荐几个hackerone报告
Legal Robot：错误配置导致的信息泄露（https://hackerone.com/reports/189023）
Zomato：错误配置导致的非法改动文件（https://hackerone.com/reports/229690）
Reverb.com:错误配置导致的任意文件上传（https://hackerone.com/reports/172549）
Ruby:错误配置导致的任意文件删除（https://hackerone.com/reports/209223）
Twitter:错误配置导致的文件读取，写入，删除（https://hackerone.com/reports/129381）
从上面的报告便可以看出大多数云漏洞的产生是由于客户配置错误，凭证管理不当泄漏，而不是云提供商方面的漏洞。
最后
如今越来越多的企业选择"上云"，这一点从日常的漏洞挖掘测试中便可见一斑。但是企业选择云服务的同时却没有按按照厂商的最佳实践方案进行操作，从而就会产生诸多问题，严重者甚至会丧失云服务器的操作权限。再次印证了人才是安全中最大的漏洞。因此，在云时代，云安全的建设不可或缺。另一方面，云厂商是否也要考虑更安全可靠的接口认证，把安全操作更多的留给自己，临时密钥就是一个不错的引入。
实验推荐--web敏感信息泄漏
