前言
如今越來越多的中小型公司選擇使用云平臺，諸如:阿里云、騰訊云、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敏感信息泄漏
- https://www.hetianlab.com/expc.do?ec=ECID25ad-863a-454c-87b6-e2b09b1f764f
聲明：筆者初衷用于分享與普及網絡知識，若讀者因此作出任何危害網絡安全行為后果自負，與合天智匯及原作者無關！
