【云安全】騰訊云COS對象存儲攻防

01 Bucket 公開訪問

騰訊云存儲桶的訪問權限默認為私有讀寫權限,且存儲桶名稱會帶上一串時間戳：

賬戶中的訪問策略包括用戶組策略、用戶策略、存儲桶訪問控制列表（ACL）和存儲桶策略（Policy）等不同的策略類型。 

當騰訊云 COS 收到請求時，首先會確認請求者身份，并驗證請求者是否擁有相關權限。驗證的過程包括檢查用戶策略、存儲桶訪問策略和基于資源的訪問控制列表，對請求進行鑒權。

--摘自騰訊云官方文檔

上圖我們僅配置了存儲桶訪問權限，于是因為設置了私有讀寫，無權訪問該文件，Message 為 “Access Denied.”

02 Bucket Object 遍歷

如果策略中允許了Object的List操作，則在目標資源范圍下，會將所有的Bucket Object顯示出來，這時，Key值可以理解為文件的目錄，通過拼接可獲取對應的文件：

有趣的是，在騰訊云的訪問策略體系中，如果存儲桶訪問權限為私有讀寫，且 Policy 權限為匿名訪問，那么 Policy 權限的優先級高于存儲桶訪問權限。

如果控制臺配置了Policy權限，默認是對所有用戶生效，并且允許所有操作，這時即使存儲桶訪問權限配置為私有讀寫，匿名用戶也可通過遍歷Bucket Object，獲取對應的文件。

03 Bucket 爆破

當訪問的存儲桶不存在時，Message 為 “NoSuchBucket”，通過響應包返回內容的對比，可以篩選出已存在的存儲桶域名。

04 Bucket 接管

由于Bucket 接管是由于管理人員未刪除指向該服務的DNS記錄，攻擊者創建同名Bucket進而讓受害域名解析所造成的，關鍵在于攻擊者是否可創建同名Bucket，騰訊云有特定的存儲桶命名格式，即-+cos.ap-nanjing.myqcloud.com：

而appid是在控制臺用時間戳隨機生成的，因此無法創建同名Bucket，故不存在Bucket 接管問題：

05 任意文件上傳與覆蓋

由于Bucket不支持重復命名，所以當匿名用戶擁有寫入權限時，可通過任意文件上傳對原有文件進行覆蓋，通過PUT請求可上傳和覆蓋任意文件。

06 用戶身份憑證（簽名）泄露

通過 RESTful API 對對象存儲（Cloud Object Storage，COS）可以發起 HTTP 匿名請求或 HTTP 簽名請求。匿名請求一般用于需要公開訪問的場景，例如托管靜態網站；此外，絕大部分場景都需要通過簽名請求完成。

簽名請求相比匿名請求，多攜帶了一個簽名值，簽名是基于密鑰（SecretId/SecretKey）和請求信息加密生成的字符串。SDK 會自動計算簽名，您只需要在初始化用戶信息時設置好密鑰，無需關心簽名的計算；對于通過 RESTful API 發起的請求，需要按照簽名算法計算簽名并添加到請求中。--摘自官方文檔

代表騰訊云用戶簽名的參數為：SecretId/SecretKey，在開發過程中可能有如下幾處操作失誤會導致SecretId/SecretKey泄露，獲取到SecretId/SecretKey相當于擁有了對應用戶的權限，從而操控Bucket。

Github中配置文件中泄露憑證

小程序\APP反編譯源碼中泄露憑證

錯誤使用SDK泄露憑證

常見場景：代碼調試時不時從服務器端獲取簽名字符串，而是從客戶端獲取硬編碼的簽名字符串。

官方SDK使用文檔：

https://cloud.tencent.com/document/product/436/8095

第三方組件配置不當導致泄露憑證

常見場景：/actuator/heapdump堆轉儲文件泄露SecretId/SecretKey

07 Bucket ACL 可讀/寫

列出Bucket Object提示無權訪問：

查看Bucket的ACL配置，發現有http://cam.qcloud.com/groups/global/AllUsers下有FULL_CONTROL權限

GET /?acl HTTP/1.1Host: .cos..myqcloud.comDate: GMT DateAuthorization: Auth String

官方文檔中有對ACL權限配置參數的說明：https://cloud.tencent.com/document/product/436/30752#.E6.93.8D.E4.BD.9C-permission

FULL_CONTROL代表匿名用戶有完全控制權限，于是在通過PUT ACL寫入策略，將存儲桶的訪問權限配置為公有讀寫：