前言
如今越來越多的中小型公司選擇使用云平臺(tái)，諸如:阿里云、騰訊云、Amazon、Azure。使用云平臺(tái)大大降低了企業(yè)的資源成本，另一方面隨著公用云的普及，也存在著一些風(fēng)險(xiǎn)，當(dāng)然不是由于云平臺(tái)本身的安全性欠缺，而是由于使用者在調(diào)用API時(shí)沒有注意安全性而導(dǎo)致的。最常見的問題就是AccessKey泄漏、配置不當(dāng)。
正文
AccessKey（即訪問密鑰）是云平臺(tái)用戶在通過API訪問云資源時(shí)用來確認(rèn)用戶身份的憑證，以確保訪問者具有相關(guān)權(quán)限。AccessKey由云平臺(tái)提供商（如亞馬遜AWS、阿里云等）頒發(fā)給云主機(jī)的所有者，一般由AccessKeyID（訪問密鑰ID）和Secret Access Key（私有訪問密鑰）構(gòu)成。
主賬戶/根用戶的AccessKey具有主賬戶的完全權(quán)限，因此云廠商不建議直接使用主賬戶/根用戶的AccessKey進(jìn)行API調(diào)用，阿里云會(huì)建議你使用RAM子賬戶進(jìn)行API的調(diào)用，當(dāng)然這個(gè)賬戶是有相應(yīng)權(quán)限限制的，而騰訊云cos服務(wù)除了可以生成子賬戶外還采用了一個(gè)CAM模型，用于生成 COS 的臨時(shí)密鑰。臨時(shí)密鑰有生效時(shí)間，作用與阿里oss的RAM子賬號類似。
通過臨時(shí)密鑰方式，則可以方便、有效地解決權(quán)限控制問題。因?yàn)楣潭荑€計(jì)算簽名方式不能有效地控制權(quán)限，同時(shí)把永久密鑰放到客戶端代碼中有極大的泄露風(fēng)險(xiǎn)。從阿里oss AccessKey泄露問題便可看出，下面會(huì)講到這個(gè)問題。
OSS AccessKey泄露
對象存儲(chǔ)（Object Storage Service，簡稱OSS），是阿里云對外提供的海量、安全和高可靠的云存儲(chǔ)服務(wù)。
通過上面描述我們知道AccessKey如果泄露就會(huì)導(dǎo)致用戶賬戶被控制，常見的泄露方式有以下幾種：
- APK反編譯后的配置文件。
- GITHUB關(guān)鍵字、JS文件、FOFA等。
- 低權(quán)限的WEBSHELL查看網(wǎng)站的配置文件
拿到AccessKey后的利用方式
- 第三方平臺(tái)，如：行云管家
- OSS Browser
- OSSUTIL
- API Explorer
OSS Browser、OSSUTIL是官方阿里云官方提供的工具只能對于OSS進(jìn)行操作，API調(diào)試或者第三方平臺(tái)可以直接操作ECS，甚至重置服務(wù)器。
這里演示一下OSS Browser（https://github.com/aliyun/oss-browser/blob/master/all-releases.md）對OSS的操作
阿里云 access key ID 和 access key secret 是訪問阿里云API的唯一憑證。Access key ID 是類似身份的標(biāo)識(shí)，而 access key secret 的作用是簽名你的訪問參數(shù)，以防被篡改。Access key secret 類似你的登錄密碼。
登陸后便可訪問文件服務(wù)，并對文件進(jìn)行操作
通過行云管家這樣的第三方平臺(tái)，我們可以進(jìn)一步進(jìn)行操作。同樣的我們需要access key ID 和 access key secret 。
通過行云管家，不僅可以訪問OSS服務(wù)，還可以直接重置服務(wù)器密碼，接管服務(wù)器。
- 參考案例(http://r3start.net/index.php/2019/09/16/580）
COS服務(wù) 臨時(shí)密鑰泄露
對象存儲(chǔ)（Cloud Object Storage，COS）是騰訊云提供的一種存儲(chǔ)海量文件的分布式存儲(chǔ)服務(wù)，用戶可通過網(wǎng)絡(luò)隨時(shí)存儲(chǔ)和查看數(shù)據(jù)。跟阿里云一樣騰訊云的主機(jī)也有主賬戶和子賬戶之分，子賬號是由主賬號創(chuàng)建的實(shí)體，有確定的身份 ID 和身份憑證，擁有登錄騰訊云控制臺(tái)的權(quán)限。子賬號默認(rèn)不擁有資源，必須由所屬主賬號進(jìn)行授權(quán)。與阿里云不同的是，騰訊云引入了臨時(shí)密鑰。
臨時(shí)密鑰（臨時(shí)訪問憑證） 是通過 CAM 云 API 提供的接口，獲取到權(quán)限受限的密鑰。主要是為了解決固定密鑰計(jì)算簽名方式不能有效地控制權(quán)限，同時(shí)把永久密鑰放到客戶端代碼中有極大的泄露風(fēng)險(xiǎn)的問題。
騰訊云獲取臨時(shí)密鑰的過程如下：
在這里，第四步下發(fā)臨時(shí)密鑰，返回的字段主要包含以下三個(gè)字段：
- TmpSecretId
- TmpSecretKey
- Token
然后利用這三個(gè)字段計(jì)算簽名，獲得簽名后，客戶端發(fā)送攜帶簽名的請求給COS服務(wù)器，對Bucket 進(jìn)行操作。
其中要是想對指定的Bucket 進(jìn)行操作，我們還需要知道對應(yīng)的Bucket 名稱，以及所屬地域Region 。
cosplay!
這里使用GEEKPWN云安全比賽的一道題作為例子來講一下騰訊云臨時(shí)密鑰的利用。
題目打開是一個(gè)上傳頁面
這里我們隨便選擇一個(gè)文件上傳，然后使用burp捕獲一下數(shù)據(jù)包
這里發(fā)現(xiàn)了一個(gè)GetTempKey接口，其返回了臨時(shí)密鑰的相關(guān)信息
這里主要關(guān)心TmpSecretId、TmpSecretKey、Token這三個(gè)字段，因?yàn)檫@三個(gè)字段是計(jì)算簽名的必要條件。騰訊云公布的有專門計(jì)算簽名的工具。
更多關(guān)于計(jì)算簽名的細(xì)節(jié)參考官方文檔(https://cloud.tencent.com/document/product/436/7778）。
這道題我們選擇更簡便的方式，官方還提供了COS 請求工具，使用說明（https://cloud.tencent.com/document/product/436/30996）。
想對指定的Bucket 進(jìn)行操作，我們還需要知道對應(yīng)的Bucket 名稱，以及所屬地域Region。通過查看頁面源碼發(fā)現(xiàn)泄露了對應(yīng)的Bucket 名稱以及Region。
有了這些條件后我們就可以訪問cos的資源了。選擇使用臨時(shí)密鑰進(jìn)行訪問。x-cos-security-token的值為返回字段中Token的值。
找了一個(gè)flag.txt,查看flag.txt的內(nèi)容。參數(shù)key為其所在key標(biāo)簽的值，類似于目錄。
成功拿到flag。
通過這道題我們可以發(fā)現(xiàn)臨時(shí)密鑰的權(quán)限比較小，獲取難度較大。同時(shí)臨時(shí)密鑰存在生效時(shí)間，默認(rèn)為1800s。所以，相對于固定密鑰也更為安全可靠。
其它
上面討論的是國內(nèi)的廠商，當(dāng)然國外的云廠商，如Amazon的AWS，也存在很多安全問題，例如S3存儲(chǔ)桶配置不當(dāng)，泄露AccessKey后，可對S3存儲(chǔ)桶進(jìn)行增刪操作，這里的S3類似于OSS、Elastic Beanstalk中利用SSRF訪問元數(shù)據(jù)，獲取AccessKey等一些敏感信息等等。
AWS AccessKey的獲取手段：
- Github關(guān)鍵詞查找，accessKeyId、secretAccessKey、AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY。
- 通過網(wǎng)站目錄或者泄漏出來的源代碼或者DEBUG信息。
- SSRF讀取元數(shù)據(jù)。
- 前端頁源代碼。
AWS常見的漏洞類型：
- AmazonS3 Bucket允許任意文件上傳和讀取
- AmazonS3 bucket允許匿名訪問
- AmazonS3 bucket允許列出文件
- AmazonS3 bucket允許盲上傳
- AmazonS3 bucket允許任意讀取/寫入對象
- AmazonS3 bucket顯示ACP/ACL
推薦幾個(gè)hackerone報(bào)告
Legal Robot：錯(cuò)誤配置導(dǎo)致的信息泄露（https://hackerone.com/reports/189023）
Zomato：錯(cuò)誤配置導(dǎo)致的非法改動(dòng)文件（https://hackerone.com/reports/229690）
Reverb.com:錯(cuò)誤配置導(dǎo)致的任意文件上傳（https://hackerone.com/reports/172549）
Ruby:錯(cuò)誤配置導(dǎo)致的任意文件刪除（https://hackerone.com/reports/209223）
Twitter:錯(cuò)誤配置導(dǎo)致的文件讀取，寫入，刪除（https://hackerone.com/reports/129381）
從上面的報(bào)告便可以看出大多數(shù)云漏洞的產(chǎn)生是由于客戶配置錯(cuò)誤，憑證管理不當(dāng)泄漏，而不是云提供商方面的漏洞。
最后
如今越來越多的企業(yè)選擇"上云"，這一點(diǎn)從日常的漏洞挖掘測試中便可見一斑。但是企業(yè)選擇云服務(wù)的同時(shí)卻沒有按按照廠商的最佳實(shí)踐方案進(jìn)行操作，從而就會(huì)產(chǎn)生諸多問題，嚴(yán)重者甚至?xí)适г品?wù)器的操作權(quán)限。再次印證了人才是安全中最大的漏洞。因此，在云時(shí)代，云安全的建設(shè)不可或缺。另一方面，云廠商是否也要考慮更安全可靠的接口認(rèn)證，把安全操作更多的留給自己，臨時(shí)密鑰就是一個(gè)不錯(cuò)的引入。
實(shí)驗(yàn)推薦
- web敏感信息泄漏
- https://www.hetianlab.com/expc.do?ec=ECID25ad-863a-454c-87b6-e2b09b1f764f
聲明：筆者初衷用于分享與普及網(wǎng)絡(luò)知識(shí)，若讀者因此作出任何危害網(wǎng)絡(luò)安全行為后果自負(fù)，與合天智匯及原作者無關(guān)！
