1、目錄 HYPERLINK l _bookmark0 前言 1 HYPERLINK l _bookmark1 一、數(shù)服帶的全挑戰(zhàn) 2 HYPERLINK l _bookmark2 二、b 用管務(wù)的據(jù)全 HYPERLINK l _bookmark3 三、象儲(chǔ)務(wù)問(wèn)略評(píng)機(jī)研究 HYPERLINK l _bookmark4 四beet訪(fǎng)問(wèn)制制與權(quán)法究 HYPERLINK l _bookmark5 五、內(nèi)個(gè)象儲(chǔ)防矩陣 HYPERLINK l _bookmark6 六、F漏帶的 HYPERLINK l _bookmark7 七-52漏為 s來(lái)安挑戰(zhàn) HYPERLINK l _bookmark8 八、服器防陣

2、 HYPERLINK l _bookmark9 九d險(xiǎn) HYPERLINK l _bookmark10 十云 IM原理風(fēng)及最實(shí)踐 前言云計(jì)算的出現(xiàn)徹底改變了IT產(chǎn)業(yè)和傳統(tǒng)企業(yè)的IT結(jié)構(gòu)各行各業(yè)正加速云步伐。從安全從業(yè)者視角來(lái)看，云就像一個(gè)極具誘惑力的“蜜罐，云上海量的數(shù)據(jù)和業(yè)務(wù)正吸引著攻擊者的視線(xiàn)。 近年來(lái)云上安全威脅呈現(xiàn)出三大趨勢(shì)首先在威脅主體上專(zhuān)業(yè)化的高持續(xù)性威脅（APT）組織層出不窮，當(dāng)前全球范圍內(nèi)具備國(guó)家級(jí)攻擊力量的黑組織就高達(dá)40多個(gè)其次在受攻擊目標(biāo)上國(guó)家關(guān)鍵基礎(chǔ)設(shè)施企業(yè)商業(yè)數(shù)據(jù)個(gè)人敏感信息等都成為攻擊標(biāo)的最后數(shù)實(shí)融合和數(shù)字化轉(zhuǎn)型的潮流致使云全面臨著資源和人力的巨大缺口。 云時(shí)代下各

3、種新技術(shù)不斷涌現(xiàn)使得云安全在攻擊面以及攻擊路徑上呈現(xiàn)出愈發(fā)復(fù)雜的狀態(tài)。當(dāng)前，云上安全攻防實(shí)力已成為企業(yè)價(jià)值的重要參數(shù)之一騰訊安全依托20余年網(wǎng)絡(luò)攻防實(shí)戰(zhàn)技術(shù)的沉淀從元數(shù)據(jù)服務(wù)對(duì)象存儲(chǔ)服務(wù)、 Kubelet訪(fǎng)問(wèn)控制機(jī)制安全漏洞等角度出發(fā)將實(shí)戰(zhàn)經(jīng)驗(yàn)匯編云上安全攻防實(shí)戰(zhàn)手冊(cè)，以期為行業(yè)帶來(lái)參考。1一、元一、元據(jù)服來(lái)的安挑戰(zhàn)在針對(duì)云上業(yè)務(wù)的的攻擊事件中很多攻擊者將攻擊脆弱的元數(shù)據(jù)服務(wù)作攻擊流程中重要的一個(gè)環(huán)節(jié)并最終造成了嚴(yán)重的危害。 以2019年的美國(guó)第一資本投資國(guó)際集（CapitalOne信息泄露事件舉例根據(jù)ACaseStudyoftheCapitalOneDataBreach報(bào)告指出，攻擊者利 C

4、apitalOne部署在AWS云上實(shí)例中的SSRF漏洞向元數(shù)據(jù)服務(wù)發(fā)送請(qǐng)求并獲取色的臨時(shí)憑證，在獲取角色臨時(shí)憑據(jù)后將該角色權(quán)限下的S3存儲(chǔ)桶中的數(shù)據(jù)制到攻擊者的本地機(jī)器上最終導(dǎo)致這一嚴(yán)重?cái)?shù)據(jù)泄露事件的產(chǎn)生這一事件響了北美超過(guò)1億人CapitalOne 的股價(jià)在宣布數(shù)據(jù)泄露后收盤(pán)下跌 5.9%接下來(lái)的兩周內(nèi)總共下跌了 15%。 Capital One信息泄露事件攻擊原理圖，可參見(jiàn)圖： 圖1- CaitaOne信露事攻原 0元數(shù)據(jù)服務(wù)以及角色介紹在介紹元數(shù)據(jù)服務(wù)帶來(lái)的安全挑戰(zhàn)之前，我們先來(lái)簡(jiǎn)單介紹一下元數(shù)據(jù)0元數(shù)據(jù)服務(wù)以及角色介紹元數(shù)據(jù)服務(wù)元數(shù)據(jù)即表示實(shí)例的相關(guān)數(shù)據(jù)，可以用來(lái)配置或管理正在運(yùn)行的實(shí)

5、例。用 戶(hù)可以通過(guò)元數(shù)據(jù)服務(wù)在運(yùn)行中的實(shí)例內(nèi)查看實(shí)例的元數(shù)據(jù)。以AWS舉例，可 以在實(shí)例內(nèi)部訪(fǎng)問(wèn)如下地址來(lái)查看所有類(lèi)別的實(shí)例元數(shù)據(jù)： HYPERLINK 54/latest/meta-data/ 54/latest/meta-data/ 54屬于鏈路本地地址（Link-localaddress，鏈路本地地址又稱(chēng)連結(jié)本地位址，是計(jì)算機(jī)網(wǎng)絡(luò)中一類(lèi)特殊的地址，它僅供于在網(wǎng)段，廣播域中的主機(jī)相互通信使用。這類(lèi)主機(jī)通常不需要外部互聯(lián)網(wǎng)服務(wù)，僅有機(jī)間相互通訊的需求。IPv4鏈路本地地址定義在/16地址塊。 而在具體的技術(shù)實(shí)現(xiàn)上，云廠商將元數(shù)據(jù)服務(wù)運(yùn)行在Hypervisor（虛擬管理程序）上。當(dāng)實(shí)例向元數(shù)據(jù)

6、服務(wù)發(fā)起請(qǐng)求時(shí)，該請(qǐng)求不會(huì)通過(guò)網(wǎng)絡(luò)傳輸，也永遠(yuǎn)不會(huì)離開(kāi)這一臺(tái)計(jì)算機(jī)?；谶@個(gè)原理，元數(shù)據(jù)服務(wù)只能從實(shí)例內(nèi)部訪(fǎng)問(wèn)。 可以PING云廠商所提供的元數(shù)據(jù)服務(wù)域名，以查看其IP地址 圖1- 從上圖可見(jiàn)，元數(shù)據(jù)服務(wù)屬于鏈路本地地址。從設(shè)計(jì)上來(lái)看，元數(shù)據(jù)服看起來(lái)很安全，那為什么說(shuō)元數(shù)據(jù)服務(wù)脆弱呢？ 由于元數(shù)據(jù)服務(wù)部署在鏈路本地地址上，云廠商并沒(méi)有進(jìn)一步設(shè)置安全施來(lái)檢測(cè)或阻止由實(shí)例內(nèi)部發(fā)出的惡意的對(duì)元數(shù)據(jù)服務(wù)的未授權(quán)訪(fǎng)問(wèn)。攻擊可以通過(guò)實(shí)例上應(yīng)用的SSRF漏洞對(duì)實(shí)例的元數(shù)據(jù)服務(wù)進(jìn)行訪(fǎng)問(wèn)。 因此，如果實(shí)例中應(yīng)用中存在SSRF漏洞，那么元數(shù)據(jù)服務(wù)將會(huì)完全暴露攻擊者面前。 在實(shí)例元數(shù)據(jù)服務(wù)提供的眾多數(shù)據(jù)中，有一項(xiàng)數(shù)

7、據(jù)特別受到攻擊者的青睞那就是角色的臨時(shí)訪(fǎng)問(wèn)憑據(jù)。這將是攻擊者由SSRF漏洞到獲取實(shí)例控制權(quán)限的橋梁。 訪(fǎng)問(wèn)管理角色既然攻擊涉及到訪(fǎng)問(wèn)管理角色的臨時(shí)憑據(jù)，我們首先看下訪(fǎng)問(wèn)管理角色是 什么：訪(fǎng)問(wèn)管理的角色是擁有一組權(quán)限的虛擬身份，用于對(duì)角色載體授予云中 服務(wù)、操作和資源的訪(fǎng)問(wèn)權(quán)限。用戶(hù)可以將角色關(guān)聯(lián)到云服務(wù)器實(shí)例。為實(shí)綁定角色后，將具備以下功能及優(yōu)勢(shì)：可使用 STS 臨時(shí)密鑰訪(fǎng)問(wèn)云上其他服務(wù) 可為不同的實(shí)例賦予包含不同授權(quán)策略的角色使實(shí)例對(duì)不同的云資源具不同的訪(fǎng)問(wèn)權(quán)限，實(shí)現(xiàn)更精細(xì)粒度的權(quán)限控制 無(wú)需自行在實(shí)例中保存 SecretKey通過(guò)修改角色的授權(quán)即可變更權(quán)限捷地維護(hù)實(shí)例所擁有的訪(fǎng)問(wèn)權(quán)限 具體

8、的操作流程如下： 圖-302針對(duì)元數(shù)據(jù)服的攻擊在將角色成功綁定實(shí)例后，用戶(hù)可以在實(shí)例上訪(fǎng)問(wèn)元數(shù)據(jù)服務(wù)來(lái)查詢(xún)角色的臨時(shí)憑據(jù)，并使用獲得的臨時(shí)憑據(jù)操作該角色權(quán)限下的云服務(wù)API02針對(duì)元數(shù)據(jù)服的攻擊接下來(lái)我們將介紹下針對(duì)元數(shù)據(jù)服務(wù)的一些常見(jiàn)的攻擊模式。攻擊者可以首先通過(guò)目標(biāo)實(shí)例上的SSRF漏洞獲取與實(shí)例綁定的角色名（rolename攻擊者可以構(gòu)造訪(fǎng)問(wèn)元數(shù)據(jù)接口的payload，并通過(guò)存在SSRF漏洞的參數(shù)傳遞： http:/x.x.x.x HYPERLINK 54/latest/meta-data/ /?url=http:/169.25 HYPERLINK 54/latest/meta-data/

9、 4.169.254/latest/meta HYPERLINK 54/latest/meta-data/ -data/ iam/info在獲取到角色名稱(chēng)后攻擊者可以繼續(xù)通過(guò)SSRF漏洞獲取角色的臨時(shí)憑證http:/x.x HYPERLINK 54/latest/metadata .x.x/url=http:/169 HYPERLINK 54/latest/metadata .254.169.254/late HYPERLINK 54/latest/metadata st/metadata /iam/security-credentials/ 獲取角色臨時(shí)憑據(jù)的案例可參見(jiàn)下圖: 圖1- 從上圖

10、可見(jiàn)，攻擊者可以獲取角色的TmpSecretID以及TmpSecretKey 在攻擊者成功獲取角色的臨時(shí)憑據(jù)后，將會(huì)檢查獲取到的角色臨時(shí)憑的權(quán)限策略。有的時(shí)候，可以通過(guò)獲取到的角色名稱(chēng)，來(lái)猜測(cè)該角色的權(quán)策略例如角色名為T(mén)KE_XXX則這個(gè)角色很大可能是擁有操作TKE容器服務(wù)的權(quán)限。 此外，如果獲取的臨時(shí)密鑰擁有查詢(xún)?cè)L問(wèn)管理接口的權(quán)限，攻擊者可通過(guò)訪(fǎng)“訪(fǎng)問(wèn)管理API來(lái)準(zhǔn)確獲取的角色權(quán)限策略可以通過(guò)如下幾種方式判斷獲取角色的權(quán)限策略： 1、通過(guò)使用臨時(shí)API憑據(jù)訪(fǎng)問(wèn)“獲取角色綁定的策略列表”API接口，見(jiàn)下圖： 圖1- 從上圖可見(jiàn)，攻擊者獲取到的與實(shí)例綁定的角色的臨時(shí)憑據(jù)權(quán)限策略 “Adminis

11、tratorAccess”,這個(gè)策略允許管理賬戶(hù)內(nèi)所有用戶(hù)及其權(quán)限、財(cái)務(wù)相關(guān)的信息、云服務(wù)資產(chǎn)。 2、通過(guò)使用臨時(shí)API憑據(jù)訪(fǎng)問(wèn)“獲取角色詳情”API接口，見(jiàn)下圖： 圖1- 通過(guò)查詢(xún)的返回結(jié)果可以見(jiàn)，角色的權(quán)限策略為AssumeRole。 在弄清楚竊取的憑據(jù)所擁有的權(quán)限后，攻擊者便可以通過(guò)憑據(jù)的權(quán)限制定后續(xù)的攻擊流程。但在開(kāi)始后續(xù)的攻擊階段之前，攻擊者會(huì)先判斷當(dāng)前權(quán) 限是否可以獲取目標(biāo)的數(shù)據(jù)資源。 在所有云資源中，攻擊者們往往對(duì)目標(biāo)的數(shù)據(jù)更加感興趣。如果攻擊獲取的密鑰擁有云數(shù)據(jù)庫(kù)服務(wù)或云存儲(chǔ)服務(wù)等服務(wù)的操作權(quán)限，攻擊者將嘗試竊取目標(biāo)數(shù)據(jù)。臨時(shí)憑據(jù)同樣也可以幫助攻擊者們?cè)谀繕?biāo)實(shí)例中執(zhí)行令并控制實(shí)

12、例權(quán)限。 與通過(guò)密鑰構(gòu)造請(qǐng)求這種方式發(fā)起攻擊相比，攻擊者們?cè)趯?shí)戰(zhàn)中更傾于使用云命令行工具來(lái)進(jìn)行攻擊。 云服務(wù)廠商為用戶(hù)提供了相應(yīng)的云命令行工具以管理云服務(wù)，例如騰云提供的TCCLI工具、AWS的AWSCLI工具。攻擊者可以通過(guò)在云命令行工具中配置竊取到的API密鑰來(lái)對(duì)云資源進(jìn)行調(diào)用。與構(gòu)造請(qǐng)求訪(fǎng)問(wèn)云API接口這種方式相比，使用云命令行工具將會(huì)給攻擊者帶來(lái)更多便捷。 在使用云命令行工具之前應(yīng)先配置API密鑰以AWSCLI工具配置舉例，可以將： 圖1- 攻擊者將竊取來(lái)的 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、 AWS_SESSION_TOKEN 配置完成后

13、，可以使用云命令行工具在目標(biāo)實(shí)例上執(zhí)行命令。 在配置好密鑰后攻擊者可以嘗試使用如下圖命令通過(guò)AWSCLI在實(shí)例中運(yùn)行bash腳本以獲取實(shí)例控制權(quán)限 圖1- 借助通過(guò)元數(shù)據(jù)服務(wù)竊取到的憑據(jù)以及AWSCLI所提供的功能,攻擊者可以在實(shí)例中執(zhí)行反彈shell命令，由此進(jìn)入實(shí)例。 除此之外攻擊者還可以選擇修改userdata將反彈shell寫(xiě)入userdata中后將實(shí)例重啟，從而控制實(shí)例。 Userdata涉及到云廠商提供的一種功能，這項(xiàng)功能允許用戶(hù)自定義配置在實(shí)例啟動(dòng)時(shí)執(zhí)行的腳本的內(nèi)容。 通過(guò)這一功能攻擊者可以嘗試在實(shí)例的userdata中寫(xiě)入惡意代碼這些代碼將會(huì)在實(shí)例每次啟動(dòng)時(shí)自動(dòng)執(zhí)行。 以AWS

14、舉例，攻擊者可以將惡意代碼寫(xiě)入my_script.txt文件中，然后執(zhí)行如下指令將my_script.txt文件中內(nèi)容導(dǎo)入userdata中。 圖1- 、 、 圖1- 當(dāng)實(shí)例重啟時(shí)，userdata中的惡意代碼將會(huì)被執(zhí)行。 攻擊者除了可以使用臨時(shí)憑據(jù)獲取實(shí)例的控制權(quán)限，通過(guò)元數(shù)據(jù)服務(wù)竊 取到的擁有一定權(quán)限的角色臨時(shí)憑據(jù)在持久化階段也發(fā)揮著作用。攻擊者嘗 試使用通過(guò)元數(shù)據(jù)服務(wù)獲取的臨時(shí)憑據(jù)進(jìn)行持久化操作，確保能夠持續(xù)擁有訪(fǎng)問(wèn)權(quán)限，以防被發(fā)現(xiàn)后強(qiáng)行終止攻擊行為。 使用臨時(shí)憑據(jù)進(jìn)行持久化的方式有很多，比如說(shuō)在上文中所提及的在 userdata中寫(xiě)入惡意代碼這項(xiàng)攻擊技術(shù)，也是可以運(yùn)用在持久化階段：通過(guò)

15、在實(shí)例的userdata中寫(xiě)入惡意代碼這些代碼將會(huì)在實(shí)例每次啟動(dòng)時(shí)自動(dòng)執(zhí)行。這將很好的完成持久化操作而不易被發(fā)現(xiàn)。 除此之外攻擊者還可以嘗試在賬戶(hù)中創(chuàng)建一個(gè)新的用戶(hù)以進(jìn)行持久化，以AWSCLI舉例，攻擊者可以通過(guò)awsiam create-user -user-name Bob 為賬戶(hù)新建一個(gè)名為 圖1- 隨后使用awsiamcreate-access-key-user-nameBob指令為 圖1- 雖然這個(gè)方法操作簡(jiǎn)單且有效，但是賬戶(hù)里突然新增的用戶(hù)及其容易察覺(jué)，因此并不是一個(gè)特別有效的持久化方式。 此外，攻擊者還會(huì)使用一種常見(jiàn)的持久化手法，那就是給現(xiàn)有的用戶(hù)配額外的密鑰。以針對(duì)AWS的攻擊

16、來(lái)說(shuō)，攻擊者可以使用aws_pwn這款工具來(lái)完成這項(xiàng)攻擊，aws_pwn地址如下： /dagrz/aws_pwn aws_pwn提供了多項(xiàng)技術(shù)以供攻擊者可以完成針對(duì)aw的持久化攻擊，關(guān)于aws_pwn所提供的持久化功能可見(jiàn)下圖： 通過(guò)元數(shù)據(jù)服務(wù)竊取也可以被攻擊者應(yīng)用于橫向移動(dòng)操作。攻擊者可通過(guò)元數(shù)據(jù)服務(wù)竊取角色的臨時(shí)憑據(jù)橫向移動(dòng)到角色對(duì)應(yīng)權(quán)限的資源上。此之外，攻擊者會(huì)在所控制的實(shí)例上尋找配置文件，并通過(guò)配置文件中的置項(xiàng)中獲取其他資源的訪(fǎng)問(wèn)方式以及訪(fǎng)問(wèn)憑據(jù)。 攻擊者在橫向移動(dòng)的過(guò)程中，獲取到可以操作云數(shù)據(jù)庫(kù)或存儲(chǔ)服務(wù)必權(quán)限的密鑰或是登錄憑據(jù)后，攻擊者就可以訪(fǎng)問(wèn)這些服務(wù)并嘗試將其中的戶(hù)數(shù)據(jù)復(fù)制到攻

17、擊者的本地機(jī)器上。 以AWSCLI為例，攻擊者可以通過(guò)如下命令將s3存儲(chǔ)桶中的內(nèi)容同步到本地 圖1- 元數(shù)據(jù)安全性改進(jìn)仍然以上文提及的CapitalOne銀行數(shù)據(jù)泄露事件舉例攻擊者使用獲取 到的角色臨時(shí)憑據(jù)多次執(zhí)“awss3ls命令獲取CapitalOne 賬戶(hù)的存 儲(chǔ)桶的完整列表；接著攻擊者使用 sync命令將近30 GB 的Capital One用 戶(hù)數(shù)據(jù)復(fù)制到了攻擊者本地?？偟膩?lái)說(shuō)，元數(shù)據(jù)服務(wù)為云上安全帶來(lái)了極大 的安全挑戰(zhàn)攻擊者在通過(guò)SSRF等漏洞獲取到實(shí)例綁定的角色的臨時(shí)憑據(jù)后，將會(huì)將其應(yīng)用于云上攻擊的各個(gè)階段。通過(guò)破壞用戶(hù)系統(tǒng)，濫用用戶(hù)資源、 加密用戶(hù)資源并進(jìn)行勒索等手段影響用戶(hù)環(huán)

18、境正常使用元數(shù)據(jù)安全性改進(jìn)以AWS為例AWS為了解決元數(shù)據(jù)服務(wù)在SSRF 攻擊面前暴露出的安全性問(wèn)題，引入IMDSv2來(lái)改善其總體安全情況。 在 IMDSv2 中，如果用戶(hù)想訪(fǎng)問(wèn)元數(shù)據(jù)服務(wù)，首先需要在實(shí)例內(nèi)部向 IMDSv2發(fā)送一個(gè)HTTPPUT請(qǐng)求來(lái)啟動(dòng)會(huì)話(huà)，示例如下： 圖1- X-aws-ec2-metadata-token-ttl-seconds用于指定生存時(shí)（TTL（以秒為單位），上文中生成的token有效期為6小時(shí)（21600秒），在IMDSv2中21600秒是允許的最大TTL值。此請(qǐng)求將會(huì)返回一個(gè)token，后續(xù)訪(fǎng)問(wèn)元數(shù)據(jù)服務(wù)，需要在HTTPheader中攜帶此token，見(jiàn)如下請(qǐng)

19、求： 圖1- 完整流程如下： TOKEN=curl-X PUT HYPERLINK 54/latest/api/token 54/latest/api/token -HX- aws-ec2-metadata-token-ttl-seconds: 21600 HYPERLINK 54/latest/meta-data/profile curlhttp:/169.254. HYPERLINK 54/latest/meta-data/profile 169.254/latest/meta HYPERLINK 54/latest/meta-data/profile -data/profile -H“X

20、-aws-ec2- metadata-token: $TOKEN” 圖1- 可見(jiàn)，在采用IMDSv2時(shí)，即使實(shí)例中應(yīng)用存在SSRF漏洞，攻擊者也無(wú)法輕易的利用 SSRF漏洞向元數(shù)據(jù)服務(wù)發(fā)出PUT請(qǐng)求來(lái)獲取 token，在沒(méi)有 token的情況下攻擊者并不能訪(fǎng)問(wèn)元數(shù)據(jù)服務(wù)也就無(wú)法獲取角色的臨時(shí)憑據(jù)進(jìn)行后續(xù)的攻擊行為。 除了使用PUT啟動(dòng)請(qǐng)求這項(xiàng)安全策略之外，IMDSv2還引入了如下兩個(gè)機(jī)制保證元數(shù)據(jù)服務(wù)的安全： 不允許X-Forwarded-For標(biāo)頭：如果攻擊者通過(guò)反向代理的方式的確以繞過(guò)PUT限制，但是，通過(guò)代理傳遞的請(qǐng)求將包含“ X-Forwarded-For”頭。這樣的請(qǐng)求被IMDSv2

21、拒絕，并且不發(fā)行令牌。 IP數(shù)據(jù)包TTL設(shè)置為“ 1”：TTL指定數(shù)據(jù)包被路由器丟棄之前允許通 過(guò)的最大網(wǎng)段數(shù)量是IP數(shù)據(jù)包在網(wǎng)絡(luò)中可以轉(zhuǎn)發(fā)的最大跳數(shù)(躍點(diǎn)數(shù)),將其設(shè)置為1可確保包含密令牌的HTTP響應(yīng)會(huì)在實(shí)例外部傳播。即使攻擊者夠繞過(guò)所有其他保護(hù)措施這也將確保令牌不會(huì)在實(shí)例外部傳播并且一旦數(shù)包離開(kāi)實(shí)例，數(shù)據(jù)包將被丟棄。 4元數(shù)據(jù)服務(wù)更多安全隱患值得注意的是，AWS 認(rèn)為現(xiàn)有的實(shí)例元數(shù)據(jù)服務(wù)（IMDSv1）是完全安全的因此將繼續(xù)支持它如果不執(zhí)行任何操作則IMDSv1和IMDSv2都可用于EC2實(shí)例。這就是說(shuō)，在不主動(dòng)禁用IMDSv14元數(shù)據(jù)服務(wù)更多安全隱患IMDSv2方案的確可以有效的保護(hù)存

22、在SSRF漏洞的實(shí)例，使其元數(shù)據(jù)不被攻擊者訪(fǎng)問(wèn)。但是這項(xiàng)技術(shù)可以完美的保護(hù)元數(shù)據(jù)、保護(hù)租戶(hù)的云業(yè)務(wù)全嗎？答案是不能。 設(shè)想一下：當(dāng)攻擊者通過(guò)其他漏洞（例如RCE漏洞）獲取實(shí)例的控制權(quán)之后，IMDSv2的安全機(jī)制將變得形同虛設(shè)。攻擊者可以在實(shí)例上發(fā)送PUT請(qǐng)求獲取token隨后利用獲得的token獲取角色臨時(shí)憑據(jù)最后利用角色臨時(shí)憑據(jù)訪(fǎng)問(wèn)角色綁定的一切云業(yè)務(wù)，具 圖1- 總之，當(dāng)攻擊者通過(guò)RCE漏洞獲取實(shí)例控制權(quán)后，可以通過(guò)元數(shù)據(jù)服務(wù)獲取到的臨時(shí)憑據(jù)進(jìn)行橫向移動(dòng)。鑒于云廠商產(chǎn)品API功能的強(qiáng)大性，在獲 取角色臨時(shí)憑據(jù)后，可能造成及其嚴(yán)重的影響。 值得注意的是，如果在云平臺(tái)控制臺(tái)中執(zhí)行一些高危行為，

23、平臺(tái)默認(rèn)會(huì)需要進(jìn)行手機(jī)驗(yàn)證。但通過(guò)使用臨時(shí)憑據(jù)調(diào)用發(fā)送請(qǐng)求調(diào)用API接口，并不需要手機(jī)驗(yàn)證碼，可以繞過(guò)這項(xiàng)安全檢測(cè)。 參考文獻(xiàn)1./cn/blogs/china/talking-about-the-metadata- protection-on-2.the-instance-from-the-data-leakage-of-capital-one/ /shurmajee/aws-enhances-metadata-service-security- with-imdsv2-b5d4b238454b /smadnick/www/wp/2020-07.pdf 5./dagrz/aws_pwn /z

24、h_cn/cli/latest/userguide/cli-services-s3- commands.html#using-s3-commands-managing-objects-sync /zh_cn/IAM/latest/UserGuide/id_users_create.ht ml /cloud-security/aws-security- vulnerabilities-perspective/ 二、二、eb用托服務(wù)中元數(shù)全隱患Web應(yīng)用托管服務(wù)是一種常見(jiàn)的平臺(tái)即服務(wù)產(chǎn)（PaaS可以用來(lái)運(yùn)行并管理Web類(lèi)移動(dòng)類(lèi)和API類(lèi)應(yīng)用程序Web應(yīng)用托管服務(wù)的出現(xiàn)有效地避免了應(yīng)用開(kāi)發(fā)過(guò)程中繁瑣

25、的服務(wù)器搭建及運(yùn)維，使開(kāi)發(fā)者可以專(zhuān)注于業(yè)邏輯的實(shí)現(xiàn)。在無(wú)需管理底層基礎(chǔ)設(shè)施的情況下，即可簡(jiǎn)單、有效并且靈地對(duì)應(yīng)用進(jìn)行部署、伸縮、調(diào)整和監(jiān)控。 Web 應(yīng)用托管服務(wù)作為一種云上服務(wù)，其中也會(huì)應(yīng)用到的元數(shù)據(jù)服務(wù)行實(shí)例元數(shù)據(jù)查詢(xún)，因此不得不考慮元數(shù)據(jù)服務(wù)安全對(duì)Web應(yīng)用托管服務(wù)安全性的影響。 通過(guò)“淺談云上攻防”系列文章淺談云上攻防元數(shù)據(jù)服務(wù)帶來(lái)的安 0.b 應(yīng)用托管服務(wù)中的元數(shù)據(jù)安全隱全挑戰(zhàn)一文的介紹，元數(shù)據(jù)服務(wù)為云上業(yè)務(wù)帶來(lái)的安全挑戰(zhàn)想必讀者們經(jīng)有一個(gè)深入的了解。Web 應(yīng)用托管服務(wù)中同樣存在著元數(shù)據(jù)服務(wù)帶來(lái)的全挑戰(zhàn)，本文將擴(kuò)展探討元數(shù)據(jù)服務(wù)與0.b 應(yīng)用托管服務(wù)中的元數(shù)據(jù)安全隱在 Web 應(yīng)用

26、托管服務(wù)中的元數(shù)據(jù)安全隱患章節(jié)中，我們將以 AWS 下 ElasticBeanstalk服務(wù)進(jìn)行舉例以此介紹一下攻擊者如何攻擊Web應(yīng)用托管服務(wù)并利用元數(shù)據(jù)服務(wù)獲取信息發(fā)起后續(xù)攻擊，最終對(duì)用戶(hù)資產(chǎn)造成危害。 AWS Elastic Beanstalk 是 AWS 提供的平臺(tái)即服務(wù) (PaaS) 產(chǎn)品，用于部署和擴(kuò)展為各種環(huán)（如 Java.NETPHPNode.jsPythonRuby 和 Go）開(kāi)發(fā)的 Web 應(yīng)用程。Elastic Beanstalk 會(huì)構(gòu)建選定的受支持的平臺(tái)版本，并預(yù)置一個(gè)或多個(gè)AWS資源（如 Amazon EC2 實(shí)例）來(lái)運(yùn)行應(yīng)用程序。Elastic Beanstalk

27、的工作流程如下： 圖2- 在使用ElasticBeanstalk 部署Web 應(yīng)用程序時(shí)用戶(hù)可以通過(guò)上傳應(yīng)用程序代碼的zip 或 war 文件來(lái)配置新應(yīng)用程序環(huán)境，見(jiàn)下圖： 圖2- 在進(jìn)行新應(yīng)用程序環(huán)境配置時(shí)，Elastic Beanstalk 服務(wù)將會(huì)進(jìn)行云服務(wù)器實(shí)例創(chuàng)建、安全組配置等操作。 與此同時(shí)， ElasticBeanstalk也將創(chuàng)建一個(gè)名為 elasticbeanstalk- region-account-id 的 AmazonS3 存儲(chǔ)桶這個(gè)存儲(chǔ)桶在后續(xù)的攻擊環(huán)節(jié)中比較重要因此先簡(jiǎn)單介紹一下ElasticBeanstalk服務(wù)使用此存儲(chǔ)桶存儲(chǔ)用戶(hù)上傳的zip與war 文件中的源

28、代碼、應(yīng)用程序正常運(yùn)行所需的對(duì)象、日志、臨時(shí)配置文件等。 elasticbeanstalk-region-account-id中存儲(chǔ)的對(duì)象列表以及其 圖2- ElasticBeanstalk服務(wù)不會(huì)為其創(chuàng)建的 AmazonS3 存儲(chǔ)桶啟用默認(rèn)加密這意味著在默認(rèn)情況下對(duì)象以未加密形式存儲(chǔ)在存儲(chǔ)桶（并且只有授權(quán)用戶(hù)可以訪(fǎng)問(wèn)）。 在了解Elastic Beanstalk的使用之后，我們重點(diǎn)來(lái)看一下元數(shù)據(jù)服務(wù)與Elastic Beanstalk服務(wù)組合下的攻擊模式。 當(dāng)云服務(wù)器實(shí)例中存在SSRFXXERCE等漏洞時(shí)攻擊者可以利用這些漏洞，訪(fǎng)問(wèn)云服務(wù)器實(shí)例上的元數(shù)據(jù)服務(wù)，通過(guò)元數(shù)據(jù)服務(wù)查詢(xún)與云服務(wù)實(shí)例綁

29、定的角色以及其臨時(shí)憑據(jù)獲取，在竊取到角色的臨時(shí)憑據(jù)后，并根竊取的角色臨時(shí)憑據(jù)相應(yīng)的權(quán)限策略，危害用戶(hù)對(duì)應(yīng)的云上資源。 而在Elastic Beanstalk 服務(wù)中也同樣存在著這種攻擊模式，Elastic Beanstalk 服務(wù)創(chuàng)建名為aws-elasticbeanstalk-ec2-role的角色，并將其與云服務(wù)器實(shí)例綁定。 我們關(guān)注一下aws-elasticbeanstalk-ec2-role角色的權(quán)限策略從AWS官網(wǎng)可知，Elastic Beanstalk服務(wù)為aws-elasticbeanstalk-ec2-role角色提供了三種權(quán)限策略用于 Web 服務(wù)器層的權(quán)限策略用于工作程序?qū)?/p>

30、的權(quán)限策略；擁有多容器 Docker 環(huán)境所需的附加權(quán)限策略，在使用控制臺(tái)或 EB CLI 創(chuàng)建環(huán)境時(shí)，Elastic Beanstalk 會(huì)將所有這些策略分配給 aws- elasticbeanstalk-ec2-role角色，接下來(lái)分別看一下這三個(gè)權(quán)限策略。 AWSElasticBeanstalkWebTier 授予應(yīng)用程序?qū)⑷罩旧蟼鞯?Amazon 圖2- AWSElasticBeanstalkWorkerTier 授予日志上傳、調(diào)試、指標(biāo)發(fā)布和工作程序?qū)嵗蝿?wù)（包括隊(duì)列管理、定期任務(wù)）的權(quán)限，見(jiàn)下圖： 圖2- AWSElasticBeanstalkMulticontainerDocke

31、r 向 Amazon Elastic 圖2- 從上述策略來(lái)看，aws-elasticbeanstalk-ec2-role 角色擁有對(duì)“elasticbeanstalk-”開(kāi)頭的S3 存儲(chǔ)桶的讀取 圖2- 通過(guò)權(quán)限策略規(guī)則可知此權(quán)限策略包含上文介紹的elasticbeanstalk- region-account-id存儲(chǔ)桶的操作權(quán)限。 elasticbeanstalk-region-account-id 存儲(chǔ)桶命名也是有一定規(guī)律的： elasticbeanstalk-region-account-id存儲(chǔ)桶名由“elasticbeanstalk”字符串資源region值以及account-id

32、值組成其中elasticbeanstalk字段是固定的，而region與account-id值分別如下： l region 是資源所在的區(qū)域（例如，us-west-2） account-id 是Amazon賬戶(hù) ID不包含連字（例如123456789012 通過(guò)存儲(chǔ)桶命名規(guī)則的特征，在攻擊中可以通過(guò)目標(biāo)的信息構(gòu)建出elasticbeanstalk-region-account-id存儲(chǔ)桶的名字。 接下來(lái)介紹一下 Elastic Beanstalk 中元數(shù)據(jù)安全隱患：用戶(hù)在使用 Elastic Beanstalk中部署Web應(yīng)用程序時(shí)，如果用戶(hù)的Web應(yīng)用程序源代碼中存在SSRFXXERCE等漏

33、洞攻擊者可以利用這些漏洞訪(fǎng)問(wèn)元數(shù)據(jù)服務(wù)接口并獲取account-idRegion以及aws-elasticbeanstalk-ec2-role角色的臨時(shí)憑據(jù)，并通過(guò)獲取到的信息對(duì) S3 存儲(chǔ)桶發(fā)起攻擊，account-id、Region以及aws-elasticbeanstalk-ec2-role角色的臨時(shí)憑據(jù)獲取方式如下 以ElasticBeanstalk中部署Web應(yīng)用程序中存在SSRF漏洞為例攻擊者可以通過(guò)發(fā)送如下請(qǐng)求以獲取account-id、Region： https:/x.x.x.x/ssr HYPERLINK 54/latest/dyn f.php?url=http:/16 HY

34、PERLINK 54/latest/dyn 54/latest/dynamic/instance-identity/document從響應(yīng)數(shù)據(jù)中AccountidRegion字段獲取account-idRegion值攻擊者可以以此構(gòu)造出目標(biāo)elasticbeanstalk- region-account-id存儲(chǔ)桶名稱(chēng)。 攻擊者可以發(fā)送如下請(qǐng)求以獲取aws-elasticbeanstalk-ec2-role角色的臨時(shí)憑據(jù)： https:/x.x.x.x/ssr HYPERLINK 54/latest/met f.php?url=http:/16 HYPERLINK 54/latest/met

35、54/latest/met a-data/iam/security-credentials/ AWS-elasticbeanstalk-EC2-role響應(yīng)數(shù)據(jù)中獲取 aws-elasticbeanstalk-ec2-role 角色的臨時(shí)憑據(jù)：AccessKeyId、SecretAccessKey、Token三個(gè)字段值。 隨后，攻擊者使用獲取到的aws-elasticbeanstalk-ec2-role角色的臨時(shí)憑據(jù)訪(fǎng)問(wèn)云API接口并操作elasticbeanstalk-region-account-id存儲(chǔ)桶。 上述攻擊模式的攻擊流程圖如下： 圖2- elasticbeanstalk-reg

36、ion-account-id存儲(chǔ)桶對(duì)ElasticBeanstalk服務(wù)至關(guān)重要在攻擊者獲取elasticbeanstalk-region-account-id存儲(chǔ)桶的操作權(quán)限之后，可以進(jìn)行如下的攻擊行為，對(duì)用戶(hù)資產(chǎn)進(jìn)行破壞。 獲取用戶(hù)源代碼 在獲取elasticbeanstalk-region-account-id存儲(chǔ)桶的控制權(quán)后攻擊者可以遞歸下載資源來(lái)獲取用戶(hù)Web應(yīng)用源代碼以及日志文件，具體操作如下：aws s3 cp s3:/ elasticbeanstalk-region-account-id/ /攻擊者本地目錄 recursive。 攻擊者可以通過(guò)在AWS命令行工具中配置獲取到的臨

37、時(shí)憑據(jù)，并通過(guò)如上指令遞歸下載用戶(hù) elasticbeanstalk-region-account-id 存儲(chǔ)桶中的信息，并將其保存到本地。 獲取實(shí)例控制權(quán) 除了竊取用戶(hù)Web應(yīng)用源代碼、日志文件以外，攻擊者還可以通過(guò)獲取的角色臨時(shí)憑據(jù)向 elasticbeanstalk-region-account-id 存儲(chǔ)桶寫(xiě)入Webshell從而獲取實(shí)例的控制權(quán)。 攻擊者編寫(xiě)webshell文件并將其打包為zip文件通過(guò)在AWS命令行工具中配置獲取到的臨時(shí)憑據(jù)并執(zhí)行如下指令將webshell文件上傳到存儲(chǔ)桶中： aws s3 cp webshell.zip s3:/ elasticbeanstalk-

38、region- account-id/ 當(dāng)用戶(hù)使用AWSCodePipeline等持續(xù)集成與持續(xù)交付服務(wù)時(shí)由于上傳 webshell操作導(dǎo)致代碼更改，存儲(chǔ)桶中的代碼將會(huì)自動(dòng)在用戶(hù)實(shí)例上更新部署從而將攻擊者上傳的webshell部署至實(shí)例上攻擊者可以訪(fǎng)問(wèn)webshell路徑進(jìn)而使用webshell對(duì)實(shí)例進(jìn)行權(quán)限控制。 002更多安全隱患除了上文章節(jié)中介紹的安全隱患，Web應(yīng)用托管服務(wù)中生成的錯(cuò)誤的角 色權(quán)限配置，將為Web應(yīng)用托管服務(wù)帶來(lái)更多、更嚴(yán)重的元數(shù)據(jù)安全隱患。 從上文章節(jié)來(lái)看，Elastic Beanstalk 服務(wù)為 aws-elasticbeanstalk-ec2-role角色配置了

39、較為合理的權(quán)限策略，使得即使Web應(yīng)用托管服務(wù)中托管的用戶(hù)應(yīng)用中存在漏洞時(shí)，攻擊者在訪(fǎng)問(wèn)實(shí)例元數(shù)據(jù)服務(wù)獲取 aws- elasticbeanstalk-ec2-role角色的臨時(shí)憑據(jù)后也僅僅有權(quán)限操作Elastic Beanstalk服務(wù)生成的elasticbeanstalk-region-account-id S3存儲(chǔ)桶，并非用戶(hù)的所有存儲(chǔ)桶資源。這樣一來(lái)，漏洞所帶來(lái)的危害并不會(huì)直接擴(kuò)散到用戶(hù)的其他資源上。 但是，一旦云廠商所提供的Web應(yīng)用托管服務(wù)中自動(dòng)生成并綁定在實(shí)例上的角色權(quán)限過(guò)高，當(dāng)用戶(hù)使用的云托管服務(wù)中存在漏洞致使云托管服務(wù)自動(dòng)生成的角色憑據(jù)泄露后危害將從云托管業(yè)務(wù)直接擴(kuò)散到用戶(hù)的

40、其他業(yè)務(wù)，攻擊者將會(huì)利用獲取的高權(quán)限臨時(shí)憑據(jù)進(jìn)行橫向移動(dòng)。 通過(guò)臨時(shí)憑據(jù)，攻擊者可以從Web應(yīng)用托管服務(wù)中逃逸出來(lái)，橫向移動(dòng)到用戶(hù)的其他業(yè)務(wù)上，對(duì)用戶(hù)賬戶(hù)內(nèi)眾多其他資產(chǎn)進(jìn)行破壞 圖2- 由于攻擊者使用Web應(yīng)用托管服務(wù)生成的合法的角色身份，攻擊行為難以被發(fā)覺(jué)，對(duì)用戶(hù)安全造成極大的危害。 針對(duì)于這種情況，首先可以通過(guò)加強(qiáng)元數(shù)據(jù)服務(wù)的安全性進(jìn)行緩解，止攻擊者通過(guò) SSRF 等漏洞直接訪(fǎng)問(wèn)實(shí)例元數(shù)據(jù)服務(wù)并獲取與之綁定的角的臨時(shí)憑據(jù)。 此外，可以通過(guò)限制Web應(yīng)用托管服務(wù)中綁定到實(shí)例上的角色的權(quán)限策略進(jìn)行進(jìn)一步的安全加強(qiáng)。在授予角色權(quán)限策略時(shí)，遵循最小權(quán)限原則。 最小權(quán)限原則是一項(xiàng)標(biāo)準(zhǔn)的安全原則。即僅

41、授予執(zhí)行任務(wù)所需的最小限不要授予更多無(wú)關(guān)權(quán)限例如一個(gè)角色僅是存儲(chǔ)桶服務(wù)的使用者那么不需要將其他服務(wù)的資源訪(fǎng)問(wèn)權(quán)限（如數(shù)據(jù)庫(kù)讀寫(xiě)權(quán)限）授予給該角色。 參考文獻(xiàn) 1./zh_cn/elasticbeanstalk/latest/dg/ia- instanceprofile.html 2./exploiting-ssrf-in-aws-elastic-beanstalk/ 3./zh_cn/elasticbeanstalk/latest/dg/co4.cepts- roles-instance.html /2019/03/10/escalating-ssrf-to-rce/ 6./s/Y9CBYJ_

42、3c2UI54Du6bneZA 三、對(duì)三、對(duì)存儲(chǔ)訪(fǎng)問(wèn)策評(píng)估研究近些年來(lái)越來(lái)越多的IT產(chǎn)業(yè)正在向云原生的開(kāi)發(fā)和部署模式轉(zhuǎn)變這些模式的轉(zhuǎn)變也帶來(lái)了一些全新的安全挑戰(zhàn)。 對(duì)象存儲(chǔ)作為云原生的一項(xiàng)重要功能，同樣面臨著一些列安全挑戰(zhàn)。在對(duì)象存儲(chǔ)所導(dǎo)致的安全問(wèn)題中，絕大部分是由于用戶(hù)使用此功能時(shí)錯(cuò)誤配置導(dǎo)致的。據(jù)統(tǒng)計(jì)，由于缺乏經(jīng)驗(yàn)或人為錯(cuò)誤導(dǎo)致的存儲(chǔ)桶錯(cuò)誤配置所成的安全問(wèn)題占所有云安全漏洞的16%。 以2017美國(guó)國(guó)防部承包商數(shù)據(jù)泄露為例此次數(shù)據(jù)泄露事件是由于Booz AllenHamilton公（提供情報(bào)與防御顧問(wèn)服務(wù)在使用亞馬遜S3服務(wù)器存儲(chǔ)政府的敏感數(shù)據(jù)時(shí)，使用了錯(cuò)誤的配置，從而導(dǎo)致了政府保密信息可

43、被公開(kāi)訪(fǎng)問(wèn)。經(jīng)安全研究人員發(fā)現(xiàn)，公開(kāi)訪(fǎng)問(wèn)的S3存儲(chǔ)桶中包含47個(gè)文件和文件夾，其中三個(gè)文件可供下載，其中包含了大量“絕密”(TOP SECRET)以及 “外籍禁閱”(NOFORN)文件。 與此相似的案例有很多，例如Verizon數(shù)據(jù)泄露事件、道瓊斯客戶(hù)數(shù)據(jù)泄露事件。如何正確的使用以及配置存儲(chǔ)桶，成為了云上安全的一個(gè)重要節(jié)。 存儲(chǔ)桶的訪(fǎng)問(wèn)控制包含多個(gè)級(jí)別，而每個(gè)級(jí)別都有其獨(dú)特的錯(cuò)誤配置風(fēng)險(xiǎn)在本文中我們將深入探討什么是存儲(chǔ)桶什么是存儲(chǔ)桶ACL什么是存儲(chǔ)桶Policy以及平臺(tái)是如何處理訪(fǎng)問(wèn)權(quán)限并對(duì)錯(cuò)誤配置存儲(chǔ)桶權(quán)限導(dǎo)致的安全問(wèn)題進(jìn)行闡述。通過(guò)本文的閱讀，可以很好的幫助理解存儲(chǔ)桶的鑒權(quán)方式以及鑒權(quán)流程

44、避免在開(kāi)發(fā)過(guò)程中產(chǎn)生由存儲(chǔ)桶錯(cuò)誤配置導(dǎo)致的安全問(wèn)題 首先，我們來(lái)看簡(jiǎn)單的對(duì)對(duì)象存儲(chǔ)的概念進(jìn)行了解。 00.對(duì)象存儲(chǔ)對(duì)象存儲(chǔ)是一種存儲(chǔ)海量文件的分布式存儲(chǔ)服務(wù)用戶(hù)可通過(guò)網(wǎng)絡(luò)隨時(shí)存和查看數(shù)據(jù)對(duì)象存儲(chǔ)使所有用戶(hù)都能使用具備高擴(kuò)展性低成本可靠和安的數(shù)據(jù)存儲(chǔ)服務(wù)。 對(duì)象存儲(chǔ)可以通過(guò)控制臺(tái)、API、SDK 和工具等多樣化方式簡(jiǎn)單、快速地接入，實(shí)現(xiàn)了海量數(shù)據(jù)存儲(chǔ)和管理。通過(guò)對(duì)象存儲(chǔ)可以進(jìn)行任意格式文件的上傳下載和管理。 02存儲(chǔ)桶訪(fǎng)問(wèn)權(quán)（A）在了解對(duì)象存儲(chǔ)之后我們來(lái)梳理下02存儲(chǔ)桶訪(fǎng)問(wèn)權(quán)（A）訪(fǎng)問(wèn)控制列表（ACL）使用 XML 語(yǔ)言描述，是與資源關(guān)聯(lián)的一個(gè)指定被授 權(quán)者和授予權(quán)限的列表每個(gè)存儲(chǔ)桶和對(duì)象都有與

45、之關(guān)聯(lián)的 ACL支持向匿名戶(hù)或其他主賬號(hào)授予基本的讀寫(xiě)權(quán)限。ACL 表3- ACL屬 從控制臺(tái)上來(lái)看，存儲(chǔ)桶訪(fǎng)問(wèn)權(quán)限分為公共權(quán)限與用戶(hù)權(quán)限，見(jiàn)下圖： 圖3- 儲(chǔ)訪(fǎng)權(quán)置 從上圖的選項(xiàng)來(lái)看，公共權(quán)限和用戶(hù)權(quán)限配置共同組成了存儲(chǔ)桶訪(fǎng)問(wèn)限公共權(quán)限包括私有讀寫(xiě)公有讀私有寫(xiě)和公有讀寫(xiě)這幾個(gè)選項(xiàng)可以選擇，且為單選： 圖3- 共限 用戶(hù)權(quán)限可以通過(guò)添加用戶(hù)進(jìn)行配置,通過(guò)填寫(xiě)賬號(hào)ID并為其配置數(shù)據(jù)讀取、數(shù)據(jù)寫(xiě)入、權(quán)限讀取、權(quán)限寫(xiě)入以及完全控制五個(gè)選項(xiàng)。 圖3- 戶(hù)限 存儲(chǔ)桶訪(fǎng)問(wèn)權(quán) 公共 用戶(hù)權(quán)權(quán)限 存儲(chǔ)桶訪(fǎng)問(wèn)權(quán) 公共 用戶(hù)權(quán)權(quán)限 私有讀寫(xiě) 公有讀私有寫(xiě) 公有讀寫(xiě) 數(shù)據(jù)讀取 數(shù)據(jù)寫(xiě)入 權(quán)限讀取 權(quán)限寫(xiě)入 完全控制

46、 表3- 儲(chǔ)訪(fǎng)權(quán) 但是公共權(quán)限與用戶(hù)權(quán)限有什么區(qū)別與關(guān)聯(lián)呢？二者又是如何作用于訪(fǎng)問(wèn)控制列（ACL呢？這些問(wèn)題單從控制臺(tái)上功能上來(lái)看是并不能完全理解的，我們需要通過(guò)修改控制臺(tái)中不同的公共權(quán)限與用戶(hù)權(quán)限組合對(duì)比ACL中內(nèi)容的變化來(lái)分析控制臺(tái)上這些配置項(xiàng)的真實(shí)作用。 首先我們通過(guò)在控制臺(tái)中勾選的選項(xiàng)來(lái)測(cè)試一下公共權(quán)限是如何作用于ACL的。 . 公共權(quán)限公共權(quán)限包括：私有讀寫(xiě)、公有讀私有寫(xiě)和公有讀寫(xiě)，我們將依次測(cè)一下在控制臺(tái)中勾選后ACL中實(shí)際的配置情況。 私有讀寫(xiě)只有該存儲(chǔ)桶的創(chuàng)建者及有授權(quán)的賬號(hào)才對(duì)該存儲(chǔ)桶中的對(duì)象有讀寫(xiě)權(quán)限，其他任何人對(duì)該存儲(chǔ)桶中的對(duì)象都沒(méi)有讀寫(xiě)權(quán)限。存儲(chǔ)桶訪(fǎng)問(wèn)權(quán)限默認(rèn) 為私有讀

47、寫(xiě)。 我們將公共權(quán)限設(shè)置為私有讀寫(xiě)，見(jiàn)下圖： 圖 3- 置儲(chǔ)私寫(xiě)訪(fǎng)權(quán) 通過(guò)訪(fǎng)問(wèn)API接口，獲取此時(shí)存儲(chǔ)桶AC 圖3- 如上所示ACL 描述了存儲(chǔ)桶擁有者(Owner)（用戶(hù) UIN10001xxx,且此用戶(hù)擁有存儲(chǔ)桶的完全控制權(quán)限（FULL_CONTROL）。 值得注意的是，此處XML中權(quán)限配置，并不是因?yàn)槲覀児催x了公共權(quán)限配置中的私有讀寫(xiě)而來(lái)，而是控制臺(tái)中用戶(hù)權(quán)限里默認(rèn)配置中當(dāng)前賬號(hào)的限策略，見(jiàn)下圖紅框 圖3- 認(rèn)置當(dāng)號(hào)權(quán)策 因此，在公共權(quán)限里勾選私有讀寫(xiě)，相當(dāng)于在ACL中不額外寫(xiě)入任何配 置內(nèi)容。 公有讀私有寫(xiě)任何人（包括匿名訪(fǎng)問(wèn)者）都對(duì)該存儲(chǔ)桶中的對(duì)象有讀權(quán)限，但只有儲(chǔ)桶創(chuàng)建者 及有授權(quán)

48、的賬號(hào)才對(duì)該存儲(chǔ)桶中的對(duì)象有寫(xiě)權(quán)限。 我們將公共權(quán)限設(shè)置為公有讀私有寫(xiě)，見(jiàn)下圖 圖3- 置儲(chǔ)公私有訪(fǎng)權(quán) 通過(guò)訪(fǎng)問(wèn)API接口， 圖3- 從XML內(nèi)容可見(jiàn)通過(guò)勾選公有讀私有寫(xiě)ACL中新增了如下配置條目 圖3- 條配置授予了AllUsers用戶(hù)組的READ的權(quán)限，按權(quán)限分類(lèi)來(lái)說(shuō)，屬于 “匿名用戶(hù)公有讀”權(quán)限，示意圖如下 公有讀寫(xiě)圖3-0 有私寫(xiě)限配示 任何人（包括匿名訪(fǎng)問(wèn)者）都對(duì)該存儲(chǔ)桶中的對(duì)象有讀權(quán)限和寫(xiě)權(quán)限 圖3-1 置儲(chǔ)公讀寫(xiě)問(wèn) 圖3- 如上所示，通過(guò)勾選公有讀寫(xiě)，ACL中新增 圖3- 與上文的公有讀私有寫(xiě)權(quán)限相比，新增了AllUsers用戶(hù)組WRITE權(quán)限即“匿名用戶(hù)公有讀寫(xiě)”權(quán)限，示意圖如

49、下： 圖3-4 有寫(xiě)限置示 從上述實(shí)驗(yàn)結(jié)果來(lái)看：公共權(quán)限配置的選項(xiàng)“私有讀寫(xiě)“”公有讀私有寫(xiě) “和公有讀寫(xiě)”本質(zhì)上是在ACL中添加AllUsers用戶(hù)組的READ與WRITE權(quán)限公共權(quán)限配置選項(xiàng)的總結(jié)如下： 私有讀寫(xiě)：不在ACL中添加任何額外的權(quán)限配置條目 公有讀私有寫(xiě)：在ACL中添加AllUsers用戶(hù)組READ權(quán)限項(xiàng) 公有讀寫(xiě)在ACL中添加AllUsers用戶(hù)組READ權(quán)限項(xiàng)AllUsers用組WRITE權(quán)限項(xiàng) 在分析完公共權(quán)限之后，我們來(lái)分析一下用戶(hù)權(quán)限。 . 用戶(hù)權(quán)限用戶(hù)權(quán)限和公共權(quán)限有什么區(qū)別呢？其實(shí)都是修改ACL策略，沒(méi)有本質(zhì)的區(qū)別只是公共權(quán)限在勾選時(shí)生成ACL中ALLUSers的

50、三個(gè)權(quán)限而通過(guò)用戶(hù)權(quán)限配置的在ACL中精準(zhǔn)到用戶(hù)并且權(quán)限策略也擴(kuò)充為5個(gè)可選項(xiàng)。 圖3-5 戶(hù)限置選 我們先保持公共權(quán)限的默認(rèn)設(shè)置私有讀寫(xiě)，并在控制臺(tái)編輯用戶(hù)權(quán)限添加一個(gè)ID為123456的賬號(hào)。 數(shù)據(jù)讀取數(shù)據(jù)寫(xiě)入我們?yōu)榇速~號(hào)設(shè)置數(shù)據(jù)讀取、數(shù)據(jù)寫(xiě)入的權(quán)限，見(jiàn)下圖： 圖3-6 置戶(hù)據(jù)取寫(xiě)權(quán) 通過(guò)訪(fǎng)問(wèn)API接口，獲取此時(shí)存儲(chǔ)桶ACL。 圖3- 從XML內(nèi)容可見(jiàn)，在控制臺(tái)新增一個(gè)擁有數(shù)據(jù)讀取、數(shù)據(jù)寫(xiě)入權(quán)限的賬號(hào)后， ACL中新增了如下配置： 圖3- ACL中增加了一個(gè)uin為123456的用戶(hù)的READ與WRITE權(quán)限示意圖如下： 權(quán)限讀取權(quán)限寫(xiě)入圖3-9 據(jù)取入限配示 接下來(lái)我們保持公共權(quán)限為默認(rèn)

51、的私有讀寫(xiě)不變，并在用戶(hù)權(quán)限處添一個(gè)ID為123456的賬號(hào)，我們?yōu)榇速~號(hào)設(shè)置權(quán)限讀取、權(quán)限寫(xiě)入的權(quán)限，見(jiàn)下圖： 圖3-0 置戶(hù)限取寫(xiě)權(quán) 通過(guò)訪(fǎng)問(wèn)API接口，獲取此時(shí)存儲(chǔ)桶 圖3- 如上所示，在控制臺(tái)新增一個(gè)擁有權(quán)限讀取、權(quán)限寫(xiě)入的賬號(hào)后， ACL 圖3- ACL中增加了一個(gè)uin為123456的用戶(hù)的READ_ACP與WRITE_ACP權(quán)限,此時(shí)123456用戶(hù)可以對(duì)ACL進(jìn)行讀取以及更新操作，示意圖如下： 圖3-3 限取入限配示 公有讀寫(xiě)數(shù)據(jù)讀取數(shù)據(jù)寫(xiě)入 在這環(huán)節(jié)中，我們將實(shí)驗(yàn)一下公共權(quán)限與用戶(hù)權(quán)限的關(guān)系，我們將公權(quán)限設(shè)置為公有讀寫(xiě)，并在用戶(hù)權(quán)限處添加一個(gè)ID為123456的賬號(hào)，我們?yōu)榇?/p>

52、賬號(hào)設(shè)置權(quán)限讀取、權(quán)限寫(xiě)入的權(quán)限 圖3-4 置有據(jù)讀權(quán) 通過(guò)訪(fǎng)問(wèn)API接口，獲取此時(shí)存儲(chǔ)桶ACL 圖3- 通過(guò)對(duì)比公共權(quán)限章節(jié)中公有讀寫(xiě)與用戶(hù)權(quán)限章節(jié)中數(shù)據(jù)讀取-數(shù)據(jù)寫(xiě)入部分的內(nèi)容可以發(fā)現(xiàn), 在控制臺(tái)中配置的公共權(quán)限與用戶(hù)權(quán)限是各自作用于ACL中，在ACL中并不互相影響，配置的公有讀寫(xiě)將會(huì)在ACL中添加一個(gè) AllUsers用戶(hù)組的WRITE與READ權(quán)限，而用戶(hù)權(quán)限中添加的123456賬號(hào)的數(shù)據(jù)讀取數(shù)據(jù)寫(xiě)入將在 ACL中加入了一個(gè)123456賬號(hào)的READ與WRITE權(quán)限。 但是細(xì)心的讀者可能會(huì)發(fā)現(xiàn)一個(gè)有意思的問(wèn)題在配置用戶(hù)權(quán)限時(shí)ACL中默認(rèn)的Owner的FULL_CONTROL權(quán)限不見(jiàn)了

53、消失的Onr權(quán)限 對(duì)比一下公共權(quán)限章節(jié)中私有讀寫(xiě)部 圖3-6 有限同用戶(hù)限時(shí)ACL差性 雖然我們僅僅是在用戶(hù)權(quán)限處增加了一個(gè)新用戶(hù)，并沒(méi)有刪除也沒(méi)有法刪除控制臺(tái)中默認(rèn)的主賬號(hào)的完全控制權(quán)，但是ACL中默認(rèn)的擁有完全控制權(quán)的主賬號(hào)條目不見(jiàn)了，見(jiàn)上圖紅框處。 這樣會(huì)不會(huì)導(dǎo)致主賬號(hào)失去了存儲(chǔ)桶的控制權(quán)呢？經(jīng)過(guò)測(cè)試發(fā)現(xiàn)，主號(hào)依然擁有存儲(chǔ)桶的完全控制權(quán)，這是問(wèn)什么呢？ 通過(guò)查閱官方文檔，我們發(fā)現(xiàn)了答案： 圖3- 5. 儲(chǔ)策uetP5. 儲(chǔ)策uetPl） 在分析完ACL之后我們來(lái)看看Policy存儲(chǔ)桶策（BucketPolicy）使用 JSON 語(yǔ)言描述支持向匿名身份或任何 CAM 賬戶(hù)授予對(duì)存儲(chǔ)桶存儲(chǔ)桶

54、操作、對(duì)象或?qū)ο蟛僮鞯臋?quán)限，在對(duì)象存儲(chǔ)中存儲(chǔ)桶策略可以用于管理存儲(chǔ)桶內(nèi)的幾乎所有操作。Policy屬性見(jiàn)下圖： 表3- BuketPolcy性 我們可以通過(guò)在控制臺(tái)中添加策略的方式來(lái)設(shè)置Policy權(quán)限。 圖3-8 過(guò)制添加olic 圖3-9 加策 通過(guò)訪(fǎng)問(wèn)API接口，獲取權(quán)限策略。 圖3- 可以發(fā)現(xiàn)Policy中以共有四個(gè)主要的屬性ActionEffectPrincipal Resource分別對(duì)應(yīng)了控制臺(tái)中填寫(xiě)的操作效力用戶(hù)資源路徑與ACL僅可以配置的用戶(hù)與權(quán)限選項(xiàng)相比，控制的顆粒更細(xì)。 接下來(lái)，我們添加一個(gè)允許賬號(hào) ID 為 123456 的賬號(hào)對(duì) aclxxx/policy_test路

55、徑的讀操作。 圖3-1 置號(hào)定源操權(quán) 圖3- 在這個(gè)Policy中，我們可以看到更細(xì)膩的Action與Resource配置。 . 象問(wèn)權(quán)限在對(duì)象存儲(chǔ)中，每一個(gè)對(duì)象同樣存在著可配置的訪(fǎng)問(wèn)權(quán)限，默認(rèn)繼承存桶的ACL。 圖3-3 象問(wèn)限制臺(tái) 我們將此對(duì)象設(shè)置為公有讀私有寫(xiě)權(quán)限，見(jiàn)下圖： 圖3-4 置象有私有權(quán) 通過(guò)查詢(xún)GetObjectAcl API接口，獲取其ACL。 圖3- 從ACL可見(jiàn)與存儲(chǔ)桶的ACL配置項(xiàng)完全一樣只不過(guò)這里的ACL作用于標(biāo)對(duì)象而存儲(chǔ)桶ACL作用于存儲(chǔ)桶。 . 訪(fǎng)問(wèn)策略評(píng)估機(jī)制但是對(duì)象存儲(chǔ)是如何通過(guò)ACL與. 訪(fǎng)問(wèn)策略評(píng)估機(jī)制在開(kāi)始介紹對(duì)象存儲(chǔ)訪(fǎng)問(wèn)策略評(píng)估流程之前我們先介紹一下

56、幾個(gè)流程中及到的重要概念：顯示拒絕、顯示允許、隱式拒絕以及三者之間的聯(lián)系： 顯式拒絕：在用戶(hù)策略、用戶(hù)組策略、存儲(chǔ)桶 Policy 中針對(duì)特定用有明確的 Deny 策略。 顯式允許：在用戶(hù)策略、用戶(hù)組策略、存儲(chǔ)桶 Policy、存儲(chǔ)桶 ACL 通過(guò)grant-*明確指定特定用戶(hù)針對(duì)特定用戶(hù)有明確的 Allow 策略。 隱式拒絕在默認(rèn)情況（未經(jīng)配置的情況下所有請(qǐng)求都被隱式拒絕（deny。 顯示拒絕、顯式允許、隱式拒絕之間的關(guān)系如下： 如果在用戶(hù)組策略、用戶(hù)策略、存儲(chǔ)桶策略或者存儲(chǔ)桶/對(duì)象訪(fǎng)問(wèn)控制列表中存在顯式允許時(shí)，將覆蓋此默認(rèn)值。任何策略中的顯式拒絕將覆蓋任何允許 在計(jì)算訪(fǎng)問(wèn)策略時(shí)應(yīng)取基于身份

57、的策（用戶(hù)組策略用戶(hù)策略和基于 資源的策略（存儲(chǔ)桶策略或者存儲(chǔ)桶/對(duì)象訪(fǎng)問(wèn)控制列表）中策略條目的并集根據(jù)顯示拒絕、顯式允許、隱式拒絕之間的關(guān)系計(jì)算出此時(shí)的權(quán)限策略。 圖3-5 儲(chǔ)鑒流 0808. 訪(fǎng)錯(cuò)誤配置導(dǎo)致安全問(wèn)題錯(cuò)誤使用公有讀寫(xiě)權(quán)限 在所有錯(cuò)誤配置導(dǎo)致的存儲(chǔ)桶安全問(wèn)題中最常見(jiàn)的一種便是錯(cuò)誤的使用公有讀寫(xiě)權(quán)限導(dǎo)致的安全問(wèn)題。 圖3-6 置儲(chǔ)公讀寫(xiě)問(wèn) 通過(guò)上文的分析可知公有讀權(quán)限可以通過(guò)匿名身份直接讀取用戶(hù)存儲(chǔ)桶中 的數(shù)據(jù)，存在著嚴(yán)重的安全隱患。 但是有些用戶(hù)為了避免使用繁雜且細(xì)粒度的權(quán)限配置會(huì)錯(cuò)誤的將其存儲(chǔ)設(shè)置為公有讀寫(xiě)這將導(dǎo)致了其存儲(chǔ)桶中的內(nèi)容被攻擊者竊取與篡改正如本前言中所描述的201

58、7美國(guó)國(guó)防部承包商數(shù)據(jù)泄露案例。即便是美國(guó)國(guó)防部承商，在使用存儲(chǔ)桶進(jìn)行對(duì)象存儲(chǔ)時(shí)，也會(huì)犯下這樣的常見(jiàn)錯(cuò)誤。 因此，為了保障存儲(chǔ)桶安全，建議用戶(hù)為存儲(chǔ)桶配置私有讀寫(xiě)權(quán)限。 存儲(chǔ)桶、對(duì)象訪(fǎng)問(wèn)權(quán)限差異性問(wèn)題存儲(chǔ)桶權(quán)限與對(duì)象權(quán)限的差異性往往會(huì)為對(duì)象資源來(lái)安全性問(wèn)題在實(shí)際操作中，為了存儲(chǔ)桶的安全起見(jiàn)，存儲(chǔ)桶的公共權(quán)限往往會(huì)被設(shè)置為私有讀寫(xiě)這也是存儲(chǔ)桶的默認(rèn)公共權(quán)限配置，見(jiàn)下圖： 圖3-7 置儲(chǔ)私讀寫(xiě) 存儲(chǔ)桶的私有權(quán)限表明只有該存儲(chǔ)桶的創(chuàng)建者及有授權(quán)的賬號(hào)才對(duì)該存桶中的對(duì)象有讀寫(xiě)權(quán)限，其他任何人對(duì)該存儲(chǔ)桶中的對(duì)象都沒(méi)有讀寫(xiě)權(quán)限。 但是將存儲(chǔ)桶的公共權(quán)限設(shè)置為私有讀寫(xiě)可以完全保護(hù)存儲(chǔ)桶中的中的對(duì)象資源不被讀

59、取嗎? 在我們測(cè)試的這個(gè)存儲(chǔ)桶中，并未設(shè)置Policy策略，并且存在著一個(gè)名為p2.png的對(duì)象。 圖3-8 p.png對(duì) 而從上文可知，存儲(chǔ)桶中的對(duì)象也有著其對(duì)應(yīng)的對(duì)象權(quán)限。 在這里我們將對(duì)象p2.png的ACL權(quán)限設(shè)置為公有讀私有寫(xiě)，見(jiàn)下圖： 圖3-9 p.png對(duì)配公有私 通過(guò)訪(fǎng)問(wèn)p2.png資源url可以發(fā)現(xiàn)，此時(shí)p2.png對(duì)象可以被訪(fǎng)問(wèn)，見(jiàn)圖： 圖3-0 功問(wèn)p.pg對(duì) 測(cè)試表明當(dāng)存儲(chǔ)桶公共權(quán)限設(shè)置為私有讀寫(xiě)時(shí)當(dāng)存儲(chǔ)桶中的對(duì)象公共限為公有讀私有寫(xiě)時(shí)，此對(duì)象依然是可以被讀取的。 實(shí)際原理很簡(jiǎn)單，我們?yōu)閷?duì)象p2.png設(shè)置公有讀私有寫(xiě)ACL策，此對(duì)象資源p2.png的ACL如下： 圖3

60、- 根據(jù)上文訪(fǎng)問(wèn)策略評(píng)估機(jī)制一章可知對(duì)象p2.png設(shè)置了AllUsers用戶(hù)組 的顯性允許READ權(quán)限因此當(dāng)匿名用戶(hù)訪(fǎng)問(wèn)p2.png時(shí)即使存儲(chǔ)桶設(shè)置了私有讀寫(xiě)權(quán)限，依然可以訪(fǎng)問(wèn)此對(duì)象，原理圖見(jiàn)下圖： 圖3-2 問(wèn)p.pg鑒權(quán) 因此單單依靠存儲(chǔ)桶的訪(fǎng)問(wèn)權(quán)限并不能保護(hù)其中資源的未授權(quán)訪(fǎng)問(wèn)情00. 錯(cuò)誤授予的操作 AL權(quán)限在Policy權(quán)限設(shè)置中如果授權(quán)用戶(hù)操作存儲(chǔ)桶以及對(duì)象ACL的權(quán)（GET、 圖3-3 予戶(hù)作AL權(quán) 即使Policy中沒(méi)有授權(quán)該用戶(hù)讀取存儲(chǔ)桶、寫(xiě)入存儲(chǔ)桶、讀取對(duì)象、寫(xiě)入 對(duì)象的權(quán)限這個(gè)操作依然是及其危險(xiǎn)的因?yàn)樵撚脩?hù)可以通過(guò)修改存儲(chǔ)桶以及對(duì)象的ACL進(jìn)行越權(quán)。 我們?cè)赾oscmd