一、Bucket 策略可寫
如果Bucket不當配置了 PutBucketPolicy 權限，攻擊者可以通過上傳新的Bucket策略覆蓋舊策略，從而實現Bucket提權。
此時無法訪問資源，也無法列對象，
攻擊者可使用PUT方法，覆蓋Bucket的策略，
此時我們可以正常訪問Bucket的資源了，
參考鏈接：
https://zone.huoxian.cn/d/918-oss
二、Bucket ACL 可寫
在Policy權限設置中，如果授權用戶操作存儲桶以及對象ACL的權限（GET、PUT），即使Policy中沒有授權該用戶讀取存儲桶、寫入存儲桶、讀取對象、寫入對象的權限，這個操作依然是及其危險的，因爲該用戶可以通過修改存儲桶以及對象的ACL進行越權。
參考鏈接：
https://mp.weixin.qq.com/s/ncWGrMsIAvh9HEK1QC5IGQ
三、創建高權限角色
0x1：雲賬號角色的業務背景
在雲上，企業與企業之間的交互無法避免，許多雲服務商提出了企業與企業之間部分資源共享的解決方案，具體流程是一家企業創建一個角色並給予特定的策略指向另一家企業，並授權賬號內特定的資源給這個角色。
站在攻擊者的視角來說，當我們擁有一家企業的憑證，該憑證可以創建角色並授權資源時，我們便可以利用該業務去創建一個相對隱蔽的角色，去通過使用自己的賬號跨賬號切換角色獲取該企業的所有資源。而這恰好對應了雲安全攻防矩陣中持久化和權限提升模塊。
在現階段常規憑證利用中攻擊者往往會創建一個可以登錄雲服務控制檯的子賬號進行持久化和權限提升，許多防禦者會注意新建子賬號用戶，該方式隱蔽性較差，容易被發現。使用創建角色跨賬號進行資源授權的這種方法可以做到一定的隱蔽性而且不會添加新賬戶。
0x2：阿里雲可信Ram角色
可信實體爲阿里雲賬號的RAM角色(注意:可信賬號不能爲ram子賬號)。該RAM角色主要用於解決跨賬號訪問和臨時授權問題，扮演角色的RAM用戶可以是自己的阿里雲賬號，也可以是其他阿里雲賬號，意思是可以把ram實體當作跨賬號管理資源授權的一個媒介。
可信ram角色跨賬號資源授權與常見創建ram子賬號區別：
- 1、隱藏性更高，可自定義角色名和描述詞，無法在用戶列表查詢。
- 2、可拓展性更高。
可信賬號前提：
- 1、該AK/SK或者子賬號擁有ram權限。
- 2、需要另一個不同企業的aliyun賬號。
下面進行一個簡單的Demo演示，
- 1、添加可信ram角色
- 2、指向其他雲賬號(賬號名爲企業別名)
- 3、爲角色授權
授權所有權限給指向其他企業的可信ram
- 4、登錄另一個企業賬號點擊切換身份
- 5、角色切換至Ram可信角色
- 6、接管了所有資源
參考鏈接：
https://wiki.teamssix.com/CloudService/IAM/ https://mp.weixin.qq.com/s/2yaQ_W5K7BfmycMO2UcXJg