2022云安全攻防手冊(cè)

云安全攻防手冊(cè)2022目 錄前 言 1一、數(shù)服帶的全挑戰(zhàn) 2二、用管務(wù)的元據(jù)全13三、象儲(chǔ)務(wù)問(wèn)略評(píng)機(jī)研究 23四Kubelet訪問(wèn)制制與權(quán)法究 48五、內(nèi)個(gè)象儲(chǔ)防矩陣 60六、漏帶的68七CVE-2020-8562漏為k8s來(lái)安挑戰(zhàn) 86八、服器防陣 94九Etcd險(xiǎn)106十云IAM原理風(fēng)及最實(shí)踐 11511前 言ITIT持續(xù)性威脅（APT）40全面臨著資源和人力的巨大缺口。20PAGEPAGE100一、元數(shù)據(jù)服務(wù)帶來(lái)的安全挑戰(zhàn)一、元數(shù)據(jù)服務(wù)帶來(lái)的安全挑戰(zhàn)攻擊流程中重要的一個(gè)環(huán)節(jié)并最終造成了嚴(yán)重的危害。2019（CapitalOne根據(jù)《ACaseStudyoftheCapitalOneDataBreachCapitalOneAWSSSRFS31CapitalOne的股價(jià)在宣布數(shù)據(jù)泄露后收盤下跌接下來(lái)的兩周內(nèi)總共下跌了15%。CapitalOne信息泄露事件攻擊原理圖，可參見(jiàn)圖：圖1-1CapitalOne信息泄露事件攻擊原理圖01．元數(shù)據(jù)服務(wù)以及角色介紹在介紹元數(shù)據(jù)服務(wù)帶來(lái)的安全挑戰(zhàn)之前，我們先來(lái)簡(jiǎn)單介紹一下元數(shù)據(jù)服務(wù)以及角色的概念。01．元數(shù)據(jù)服務(wù)以及角色介紹元數(shù)據(jù)服務(wù)元數(shù)據(jù)即表示實(shí)例的相關(guān)數(shù)據(jù)，可以用來(lái)配置或管理正在運(yùn)行的實(shí)例。用戶可以通過(guò)元數(shù)據(jù)服務(wù)在運(yùn)行中的實(shí)例內(nèi)查看實(shí)例的元數(shù)據(jù)。以AWS舉例，可以在實(shí)例內(nèi)部訪問(wèn)如下地址來(lái)查看所有類別的實(shí)例元數(shù)據(jù)：54/latest/meta-data/54（Link-localaddress，鏈路本地地機(jī)間相互通訊的需求。IPv4/16Hypervisor（管理程序）上。當(dāng)實(shí)例向元數(shù)據(jù)服務(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)部訪問(wèn)?？梢訮ING云廠商所提供的元數(shù)據(jù)服務(wù)域名，以查看其IP地址圖1-2從上圖可見(jiàn)，元數(shù)據(jù)服務(wù)屬于鏈路本地地址。從設(shè)計(jì)上來(lái)看，元數(shù)據(jù)服務(wù)看起來(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)訪問(wèn)。攻擊者可以通過(guò)實(shí)例上應(yīng)用的SSRF漏洞對(duì)實(shí)例的元數(shù)據(jù)服務(wù)進(jìn)行訪問(wèn)。SSRF攻擊者面前。在實(shí)例元數(shù)據(jù)服務(wù)提供的眾多數(shù)據(jù)中，有一項(xiàng)數(shù)據(jù)特別受到攻擊者的青睞，那就是角色的臨時(shí)訪問(wèn)憑據(jù)。這將是攻擊者由SSRF漏洞到獲取實(shí)例控制權(quán)限的橋梁。訪問(wèn)管理角色既然攻擊涉及到訪問(wèn)管理角色的臨時(shí)憑據(jù)，我們首先看下訪問(wèn)管理角色是什么：訪問(wèn)管理的角色是擁有一組權(quán)限的虛擬身份，用于對(duì)角色載體授予云中服務(wù)、操作和資源的訪問(wèn)權(quán)限。用戶可以將角色關(guān)聯(lián)到云服務(wù)器實(shí)例。為實(shí)例綁定角色后，將具備以下功能及優(yōu)勢(shì)：可使用STS臨時(shí)密鑰訪問(wèn)云上其他服務(wù)不同的訪問(wèn)權(quán)限，實(shí)現(xiàn)更精細(xì)粒度的權(quán)限控制無(wú)需自行在實(shí)例中保存捷地維護(hù)實(shí)例所擁有的訪問(wèn)權(quán)限具體的操作流程如下：圖1-302．針對(duì)元數(shù)據(jù)服務(wù)的攻擊在將角色成功綁定實(shí)例后，用戶可以在實(shí)例上訪問(wèn)元數(shù)據(jù)服務(wù)來(lái)查詢此角色的臨時(shí)憑據(jù)，并使用獲得的臨時(shí)憑據(jù)操作該角色權(quán)限下的云服務(wù)API接口。02．針對(duì)元數(shù)據(jù)服務(wù)的攻擊接下來(lái)我們將介紹下針對(duì)元數(shù)據(jù)服務(wù)的一些常見(jiàn)的攻擊模式。攻擊者可以首先通過(guò)目標(biāo)實(shí)例上的SSRF攻擊者可以構(gòu)造訪問(wèn)元數(shù)據(jù)接口的payloadSSRF漏洞的參數(shù)傳遞：http://x.x.x.x/?url=http://169.254.169.254/latest/meta-data/iam/info，在獲取到角色名稱后，攻擊者可以繼續(xù)通過(guò)SSRF漏洞獲取角色的臨時(shí)憑證：http://x.x.x.x/url=http://169.254.169.254/latest/metadata/iam/security-credentials/<rolename>獲取角色臨時(shí)憑據(jù)的案例可參見(jiàn)下圖:圖1-4從上圖可見(jiàn)，攻擊者可以獲取角色的TmpSecretIDTmpSecretKey在攻擊者成功獲取角色的臨時(shí)憑據(jù)后，將會(huì)檢查獲取到的角色臨時(shí)憑據(jù)的權(quán)限策略。有的時(shí)候，可以通過(guò)獲取到的角色名稱，來(lái)猜測(cè)該角色的權(quán)限策略，例如角色名為：TKE_XXX，則這個(gè)角色很大可能是擁有操作TKE容器服務(wù)的權(quán)限。此外，如果獲取的臨時(shí)密鑰擁有查詢?cè)L問(wèn)管理接口的權(quán)限，攻擊者可以通過(guò)訪問(wèn)“訪問(wèn)管理”API來(lái)準(zhǔn)確獲取的角色權(quán)限策略。可以通過(guò)如下幾種方式判斷獲取角色的權(quán)限策略：1、通過(guò)使用臨時(shí)API憑據(jù)訪問(wèn)“獲取角色綁定的策略列表”API接口，見(jiàn)下圖：圖1-5從上圖可見(jiàn)，攻擊者獲取到的與實(shí)例綁定的角色的臨時(shí)憑據(jù)權(quán)限策略是“AdministratorAccess”,這個(gè)策略允許管理賬戶內(nèi)所有用戶及其權(quán)限、財(cái)務(wù)相關(guān)的信息、云服務(wù)資產(chǎn)。2、通過(guò)使用臨時(shí)API憑據(jù)訪問(wèn)“獲取角色詳情”API接口，見(jiàn)下圖：圖1-6通過(guò)查詢的返回結(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)限，攻擊者將會(huì)嘗試竊取目標(biāo)數(shù)據(jù)。臨時(shí)憑據(jù)同樣也可以幫助攻擊者們?cè)谀繕?biāo)實(shí)例中執(zhí)行指令并控制實(shí)例權(quán)限。與通過(guò)密鑰構(gòu)造請(qǐng)求這種方式發(fā)起攻擊相比，攻擊者們?cè)趯?shí)戰(zhàn)中更傾向于使用云命令行工具來(lái)進(jìn)行攻擊。云服務(wù)廠商為用戶提供了相應(yīng)的云命令行工具以管理云服務(wù)，例如騰訊云提供的TCCLI工具、AWS的AWSCLI工具。攻擊者可以通過(guò)在云命令行工具中配置竊取到的API密鑰來(lái)對(duì)云資源進(jìn)行調(diào)用。與構(gòu)造請(qǐng)求訪問(wèn)云API接口這種方式相比，使用云命令行工具將會(huì)給攻擊者帶來(lái)更多便捷。APIAWSCLI可以將：圖1-7攻擊者將竊取來(lái)的AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEYAWS_SESSION_TOKEN配置完成后，可以使用云命令行工具在目標(biāo)實(shí)例上執(zhí)行命令。圖1-8借助通過(guò)元數(shù)據(jù)服務(wù)竊取到的憑據(jù)以及AWSCLI所提供的功能,攻擊者可以在實(shí)例中執(zhí)行反彈shell命令，由此進(jìn)入實(shí)例。userdatashelluserdata中后將實(shí)例重啟，從而控制實(shí)例。Userdata涉及到云廠商提供的一種功能，這項(xiàng)功能允許用戶自定義配置在實(shí)例啟動(dòng)時(shí)執(zhí)行的腳本的內(nèi)容。通過(guò)這一功能，攻擊者可以嘗試在實(shí)例的userdata中寫入惡意代碼，這些代碼將會(huì)在實(shí)例每次啟動(dòng)時(shí)自動(dòng)執(zhí)行。以AWS舉例，攻擊者可以將惡意代碼寫入my_script.txt文件中，然后執(zhí)行如下指令將my_script.txt文件中內(nèi)容導(dǎo)入userdata中。、、圖1-10當(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ù)擁有訪問(wèn)權(quán)限，以防被發(fā)現(xiàn)后強(qiáng)行終止攻擊行為。使用臨時(shí)憑據(jù)進(jìn)行持久化的方式有很多，比如說(shuō)在上文中所提及的在userdata中寫入惡意代碼這項(xiàng)攻擊技術(shù)，也是可以運(yùn)用在持久化階段：通過(guò)userdata行。這將很好的完成持久化操作而不易被發(fā)現(xiàn)。圖1-11圖1-12雖然這個(gè)方法操作簡(jiǎn)單且有效，但是賬戶里突然新增的用戶及其容易被察覺(jué)，因此并不是一個(gè)特別有效的持久化方式。此外，攻擊者還會(huì)使用一種常見(jiàn)的持久化手法，那就是給現(xiàn)有的用戶分配額外的密鑰。以針對(duì)AWS的攻擊來(lái)說(shuō)，攻擊者可以使用aws_pwn這款工具來(lái)完成這項(xiàng)攻擊，aws_pwn地址如下：/dagrz/aws_pwnaws_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)中獲取其他資源的訪問(wèn)方式以及訪問(wèn)憑據(jù)。攻擊者在橫向移動(dòng)的過(guò)程中，獲取到可以操作云數(shù)據(jù)庫(kù)或存儲(chǔ)服務(wù)必要權(quán)限的密鑰或是登錄憑據(jù)后，攻擊者就可以訪問(wèn)這些服務(wù)并嘗試將其中的用戶數(shù)據(jù)復(fù)制到攻擊者的本地機(jī)器上。圖1-1403．元數(shù)據(jù)安全性改進(jìn)仍然以上文提及的CapitalOne銀行數(shù)據(jù)泄露事件舉例，攻擊者使用獲取到的角色臨時(shí)憑據(jù)，多次執(zhí)行“awss3ls”命令，獲取CapitalOne賬戶的存儲(chǔ)桶的完整列表；接著攻擊者使用sync命令將近30GB的CapitalOne用戶數(shù)據(jù)復(fù)制到了攻擊者本地。總的來(lái)說(shuō)，元數(shù)據(jù)服務(wù)為云上安全帶來(lái)了極大的安全挑戰(zhàn)，攻擊者在通過(guò)SSRF等漏洞獲取到實(shí)例綁定的角色的臨時(shí)憑據(jù)后，將會(huì)將其應(yīng)用于云上攻擊的各個(gè)階段。通過(guò)破壞用戶系統(tǒng)，濫用用戶資源、加密用戶資源并進(jìn)行勒索等手段影響用戶環(huán)境正常使用。03．元數(shù)據(jù)安全性改進(jìn)以AWS為例，AWS為了解決元數(shù)據(jù)服務(wù)在SSRF攻擊面前暴露出的安全性問(wèn)題，引入IMDSv2來(lái)改善其總體安全情況。在IMDSv2中，如果用戶想訪問(wèn)元數(shù)據(jù)服務(wù)，首先需要在實(shí)例內(nèi)部向圖1-15X-aws-ec2-metadata-token-ttl-seconds（TTL（以秒為單位），上文中生成的token6（21600），IMDSv221600TTL值。此請(qǐng)求將會(huì)返回一個(gè)token，后續(xù)訪問(wèn)元數(shù)據(jù)服務(wù)，需要在HTTPheadertoken，見(jiàn)如下請(qǐng)求：圖1-16完整流程如下：TOKEN=`curl-XPUT"54/latest/api/token"-H"X-aws-ec2-metadata-token-ttl-seconds:21600"curlhttp://169.254.169.254/latest/meta-data/profile-H“X-aws-ec2-metadata-token:$TOKEN”圖1-17可見(jiàn)，在采用IMDSv2SSRF漏洞，攻擊者也無(wú)法輕易的利用SSRF漏洞向元數(shù)據(jù)服務(wù)發(fā)出PUT請(qǐng)求來(lái)獲取token，在沒(méi)有token除了使用PUT啟動(dòng)請(qǐng)求這項(xiàng)安全策略之外，IMDSv2還引入了如下兩個(gè)機(jī)制保證元數(shù)據(jù)服務(wù)的安全：X-Forwarded-ForPUTX-Forwarded-For”IMDSv2IPTTL1”：TTLIP1HTTP包離開(kāi)實(shí)例，數(shù)據(jù)包將被丟棄。04．元數(shù)據(jù)服務(wù)更多安全隱患值得注意的是，AWS認(rèn)為現(xiàn)有的實(shí)例元數(shù)據(jù)服務(wù)（IMDSv1）IMDSv1IMDSv2EC2IMDSv104．元數(shù)據(jù)服務(wù)更多安全隱患IMDSv2方案的確可以有效的保護(hù)存在SSRF漏洞的實(shí)例，使其元數(shù)據(jù)不被攻擊者訪問(wèn)。但是這項(xiàng)技術(shù)可以完美的保護(hù)元數(shù)據(jù)、保護(hù)租戶的云業(yè)務(wù)安全嗎？答案是不能。圖1-18總之，當(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í)行一些高危行為，平臺(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.pdf5./dagrz/aws_pwn/zh_cn/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-sync/zh_cn/IAM/latest/UserGuide/id_users_create.html/cloud-security/aws-security-vulnerabilities-perspective/二、Web應(yīng)用托管服務(wù)中的元數(shù)據(jù)安全隱患二、Web應(yīng)用托管服務(wù)中的元數(shù)據(jù)安全隱患Web應(yīng)用托管服務(wù)是一種常見(jiàn)的平臺(tái)即服務(wù)產(chǎn)品可以用來(lái)運(yùn)行WebAPIWeb避免了應(yīng)用開(kāi)發(fā)過(guò)程中繁瑣的服務(wù)器搭建及運(yùn)維，使開(kāi)發(fā)者可以專注于業(yè)務(wù)邏輯的實(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ù)進(jìn)行實(shí)例元數(shù)據(jù)查詢，因此不得不考慮元數(shù)據(jù)服務(wù)安全對(duì)Web應(yīng)用托管服務(wù)安全性的影響。通過(guò)“淺談云上攻防”系列文章《淺談云上攻防—元數(shù)據(jù)服務(wù)帶來(lái)的安01. 01. 在Web應(yīng)用托管服務(wù)中的元數(shù)據(jù)安全隱患章節(jié)中，我們將以AWS下的ElasticBeanstalkWebAWSElasticBeanstalk是AWS提供的平臺(tái)即服務(wù)(PaaS)產(chǎn)品，用于（如Java.NETPHPNode.jsPythonRuby和Go）開(kāi)發(fā)的Web應(yīng)用程序。ElasticBeanstalk會(huì)構(gòu)建選定的受支持的平臺(tái)版本，AWS（如AmazonEC2實(shí)例）來(lái)運(yùn)行應(yīng)用程序。ElasticBeanstalk的工作流程如下：圖2-1在使用ElasticBeanstalk部署Web應(yīng)用程序時(shí)，用戶可以通過(guò)上傳應(yīng)用程序代碼的zip或war文件來(lái)配置新應(yīng)用程序環(huán)境，見(jiàn)下圖：圖2-2在進(jìn)行新應(yīng)用程序環(huán)境配置時(shí)，ElasticBeanstalk服務(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ǔ)用戶上傳的zip與war文件中的源代碼、應(yīng)用程序正常運(yùn)行所需的對(duì)象、日志、臨時(shí)配置文件等。圖2-3ElasticBeanstalk服務(wù)不會(huì)為其創(chuàng)建的AmazonS3存儲(chǔ)桶啟用默認(rèn)加（并且只有授權(quán)用戶可以訪問(wèn)）。ElasticBeanstalk的使用之后，我們重點(diǎn)來(lái)看一下元數(shù)據(jù)服務(wù)ElasticBeanstalk服務(wù)組合下的攻擊模式。當(dāng)云服務(wù)器實(shí)例中存在SSRF、XXE、RCE等漏洞時(shí)，攻擊者可以利用這些漏洞，訪問(wèn)云服務(wù)器實(shí)例上的元數(shù)據(jù)服務(wù)，通過(guò)元數(shù)據(jù)服務(wù)查詢與云服務(wù)器實(shí)例綁定的角色以及其臨時(shí)憑據(jù)獲取，在竊取到角色的臨時(shí)憑據(jù)后，并根據(jù)竊取的角色臨時(shí)憑據(jù)相應(yīng)的權(quán)限策略，危害用戶對(duì)應(yīng)的云上資源。ElasticBeanstalk服務(wù)中也同樣存在著這種攻擊模式，ElasticBeanstalk服務(wù)創(chuàng)建名為aws-elasticbeanstalk-ec2-role的角色，并將其與云服務(wù)器實(shí)例綁定。aws-elasticbeanstalk-ec2-roleAWS官網(wǎng)可知，ElasticBeanstalkaws-elasticbeanstalk-ec2-role色提供了三種權(quán)限策略：用于Web服務(wù)器層的權(quán)限策略；用于工作程序?qū)拥臋?quán)限策略；擁有多容器Docker環(huán)境所需的附加權(quán)限策略，在使用控制臺(tái)或EBCLI創(chuàng)建環(huán)境時(shí)，ElasticBeanstalk會(huì)將所有這些策略分配給aws-elasticbeanstalk-ec2-role角色，接下來(lái)分別看一下這三個(gè)權(quán)限策略。圖2-4AWSElasticBeanstalkWorkerTier–授予日志上傳、調(diào)試、指標(biāo)發(fā)布和工作程序?qū)嵗蝿?wù)（包括隊(duì)列管理、定期任務(wù)）的權(quán)限，見(jiàn)下圖：圖2-5圖2-6圖2-7通過(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值組成，其中elasticbeanstalk字段是固定的，而region與account-id值分別如下：lregion是資源所在的區(qū)域（例如，us-west-2）account-idAmazonID（123456789012通過(guò)存儲(chǔ)桶命名規(guī)則的特征，在攻擊中可以通過(guò)目標(biāo)的信息構(gòu)建出elasticbeanstalk-region-account-id存儲(chǔ)桶的名字。接下來(lái)介紹一下ElasticBeanstalk中元數(shù)據(jù)安全隱患：用戶在使用ElasticBeanstalkWebWeb應(yīng)用程序源代SSRFXXERCEaccount-idRegionaws-elasticbeanstalk-ec2-role色的臨時(shí)憑據(jù)，并通過(guò)獲取到的信息對(duì)S3存儲(chǔ)桶發(fā)起攻擊，account-id、Regionaws-elasticbeanstalk-ec2-roleElasticBeanstalkWebSSRF者可以通過(guò)發(fā)送如下請(qǐng)求以獲取account-id、Region：https://x.x.x.x/ssrf.php?url=http://1654/latest/dynamic/instance-identity/documentAccountidRegionaccount-idRegionelasticbeanstalk-region-account-id存儲(chǔ)桶名稱。攻擊者可以發(fā)送如下請(qǐng)求以獲取aws-elasticbeanstalk-ec2-role角色的臨時(shí)憑據(jù)：https://x.x.x.x/ssrf.php?url=http://1654/latest/meta-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ù)，訪問(wèn)云API接口并操作elasticbeanstalk-region-account-id存儲(chǔ)桶。上述攻擊模式的攻擊流程圖如下：圖2-8elasticbeanstalk-region-account-id存儲(chǔ)桶對(duì)ElasticBeanstalk服務(wù)至關(guān)重要，在攻擊者獲取elasticbeanstalk-region-account-id存儲(chǔ)桶的操作權(quán)限之后，可以進(jìn)行如下的攻擊行為，對(duì)用戶資產(chǎn)進(jìn)行破壞。獲取用戶源代碼elasticbeanstalk-region-account-idWeb應(yīng)用源代碼以及日志文件，具體操作如awss3cps3://elasticbeanstalk-region-account-id//者本地目錄–recursive。攻擊者可以通過(guò)在AWS命令行工具中配置獲取到的臨時(shí)憑據(jù)，并通過(guò)如上指令遞歸下載用戶elasticbeanstalk-region-account-id存儲(chǔ)桶中的信息，并將其保存到本地。獲取實(shí)例控制權(quán)除了竊取用戶Web應(yīng)用源代碼、日志文件以外，攻擊者還可以通過(guò)獲取的角色臨時(shí)憑據(jù)向elasticbeanstalk-region-account-id存儲(chǔ)桶寫入Webshell從而獲取實(shí)例的控制權(quán)。webshellzipAWSwebshell文件上傳到存儲(chǔ)桶中：awss3cpwebshell.zips3://elasticbeanstalk-region-account-id/當(dāng)用戶使用AWSCodePipeline等持續(xù)集成與持續(xù)交付服務(wù)時(shí)，由于上傳webshell操作導(dǎo)致代碼更改，存儲(chǔ)桶中的代碼將會(huì)自動(dòng)在用戶實(shí)例上更新部署，從而將攻擊者上傳的webshell部署至實(shí)例上，攻擊者可以訪問(wèn)webshell路徑進(jìn)而使用webshell對(duì)實(shí)例進(jìn)行權(quán)限控制。02．更多安全隱患02．更多安全隱患除了上文章節(jié)中介紹的安全隱患，Web應(yīng)用托管服務(wù)中生成的錯(cuò)誤的角色權(quán)限配置，將為Web應(yīng)用托管服務(wù)帶來(lái)更多、更嚴(yán)重的元數(shù)據(jù)安全隱患。從上文章節(jié)來(lái)看，ElasticBeanstalk服務(wù)為aws-elasticbeanstalk-ec2-roleWeb應(yīng)用托管服務(wù)中托管的用戶應(yīng)用中存在漏洞時(shí)，攻擊者在訪問(wèn)實(shí)例元數(shù)據(jù)服務(wù)獲取aws-elasticbeanstalk-ec2-roleElasticBeanstalkelasticbeanstalk-region-account-idS3存儲(chǔ)桶，并非用戶的所有存儲(chǔ)桶資源。這樣一來(lái)，漏洞所帶來(lái)的危害并不會(huì)直接擴(kuò)散到用戶的其他資源上。但是，一旦云廠商所提供的Web應(yīng)用托管服務(wù)中自動(dòng)生成并綁定在實(shí)例上的角色權(quán)限過(guò)高，當(dāng)用戶使用的云托管服務(wù)中存在漏洞致使云托管服務(wù)自動(dòng)生成的角色憑據(jù)泄露后，危害將從云托管業(yè)務(wù)直接擴(kuò)散到用戶的其他業(yè)務(wù)，攻擊者將會(huì)利用獲取的高權(quán)限臨時(shí)憑據(jù)進(jìn)行橫向移動(dòng)。圖2-9由于攻擊者使用Web應(yīng)用托管服務(wù)生成的合法的角色身份，攻擊行為難以被發(fā)覺(jué)，對(duì)用戶安全造成極大的危害。針對(duì)于這種情況，首先可以通過(guò)加強(qiáng)元數(shù)據(jù)服務(wù)的安全性進(jìn)行緩解，防止攻擊者通過(guò)SSRF等漏洞直接訪問(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)的安全原則。即僅授予執(zhí)行任務(wù)所需的最小權(quán)（如數(shù)據(jù)庫(kù)讀寫權(quán)限）授予給該角色。參考文獻(xiàn)/zh_cn/elasticbeanstalk/latest/dg/iam-instanceprofile.html/exploiting-ssrf-in-aws-elastic-beanstalk/3./zh_cn/elasticbeanstalk/latest/dg/con4.cepts-roles-instance.html/2019/03/10/escalating-ssrf-to-rce/6./s/Y9CBYJ_3c2UI54Du6bneZA三、對(duì)象存儲(chǔ)服務(wù)訪問(wèn)策略評(píng)估機(jī)制研究三、對(duì)象存儲(chǔ)服務(wù)訪問(wèn)策略評(píng)估機(jī)制研究近些年來(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)題中，絕大部分是由于用戶使用此功能時(shí)錯(cuò)誤的配置導(dǎo)致的。據(jù)統(tǒng)計(jì)，由于缺乏經(jīng)驗(yàn)或人為錯(cuò)誤導(dǎo)致的存儲(chǔ)桶錯(cuò)誤配置所造成的安全問(wèn)題占所有云安全漏洞的16%。2017BoozAllenHamilton（提供情報(bào)與防御顧問(wèn)服務(wù)S3儲(chǔ)政府的敏感數(shù)據(jù)時(shí)，使用了錯(cuò)誤的配置，從而導(dǎo)致了政府保密信息可被公開(kāi)訪問(wèn)。經(jīng)安全研究人員發(fā)現(xiàn)，公開(kāi)訪問(wèn)的S347個(gè)文件和文件夾，其中三個(gè)文件可供下載，其中包含了大量“絕密”(TOPSECRET)以及“外籍禁閱”(NOFORN)文件。與此相似的案例有很多，例如Verizon數(shù)據(jù)泄露事件、道瓊斯客戶數(shù)據(jù)泄露事件。如何正確的使用以及配置存儲(chǔ)桶，成為了云上安全的一個(gè)重要環(huán)節(jié)。存儲(chǔ)桶的訪問(wèn)控制包含多個(gè)級(jí)別，而每個(gè)級(jí)別都有其獨(dú)特的錯(cuò)誤配置風(fēng)險(xiǎn)。在本文中，我們將深入探討什么是存儲(chǔ)桶、什么是存儲(chǔ)桶ACL、什么是存儲(chǔ)桶Policy以及平臺(tái)是如何處理訪問(wèn)權(quán)限，并對(duì)錯(cuò)誤配置存儲(chǔ)桶權(quán)限導(dǎo)致的安全問(wèn)題進(jìn)行闡述。通過(guò)本文的閱讀，可以很好的幫助理解存儲(chǔ)桶的鑒權(quán)方式以及鑒權(quán)流程，避免在開(kāi)發(fā)過(guò)程中產(chǎn)生由存儲(chǔ)桶錯(cuò)誤配置導(dǎo)致的安全問(wèn)題。首先，我們來(lái)看簡(jiǎn)單的對(duì)對(duì)象存儲(chǔ)的概念進(jìn)行了解。01. 對(duì)象存儲(chǔ)01. 對(duì)象存儲(chǔ)的數(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ǔ)桶訪問(wèn)權(quán)限（ACL）ACLPolicy鑒權(quán)流程以及使用過(guò)程中容易產(chǎn)生的配置錯(cuò)誤。02．存儲(chǔ)桶訪問(wèn)權(quán)限（ACL）訪問(wèn)控制列表（ACL）使用XML語(yǔ)言描述，是與資源關(guān)聯(lián)的一個(gè)指定被授表3-1ACL屬性表從控制臺(tái)上來(lái)看，存儲(chǔ)桶訪問(wèn)權(quán)限分為公共權(quán)限與用戶權(quán)限，見(jiàn)下圖：圖3-1存儲(chǔ)桶訪問(wèn)權(quán)限配置項(xiàng)從上圖的選項(xiàng)來(lái)看，公共權(quán)限和用戶權(quán)限配置共同組成了存儲(chǔ)桶訪問(wèn)權(quán)圖3-2公共權(quán)限選項(xiàng)用戶權(quán)限可以通過(guò)添加用戶進(jìn)行配置,通過(guò)填寫賬號(hào)ID并為其配置數(shù)據(jù)讀取、數(shù)據(jù)寫入、權(quán)限讀取、權(quán)限寫入以及完全控制五個(gè)選項(xiàng)。存儲(chǔ)桶訪問(wèn)權(quán)存儲(chǔ)桶訪問(wèn)權(quán)公共權(quán)限用戶權(quán)權(quán)限私有讀寫√公有讀私有寫√公有讀寫√數(shù)據(jù)讀取√數(shù)據(jù)寫入√權(quán)限讀取√權(quán)限寫入√完全控制√表3-2存儲(chǔ)桶訪問(wèn)權(quán)限但是公共權(quán)限與用戶權(quán)限有什么區(qū)別與關(guān)聯(lián)呢？二者又是如何作用于訪問(wèn)ACL首先我們通過(guò)在控制臺(tái)中勾選的選項(xiàng)來(lái)測(cè)試一下公共權(quán)限是如何作用于ACL的。03.公共權(quán)限03.公共權(quán)限公共權(quán)限包括：私有讀寫、公有讀私有寫和公有讀寫，我們將依次測(cè)試一下在控制臺(tái)中勾選后ACL中實(shí)際的配置情況。私有讀寫只有該存儲(chǔ)桶的創(chuàng)建者及有授權(quán)的賬號(hào)才對(duì)該存儲(chǔ)桶中的對(duì)象有讀寫權(quán)限，其他任何人對(duì)該存儲(chǔ)桶中的對(duì)象都沒(méi)有讀寫權(quán)限。存儲(chǔ)桶訪問(wèn)權(quán)限默認(rèn)為私有讀寫。我們將公共權(quán)限設(shè)置為私有讀寫，見(jiàn)下圖：圖3-4設(shè)置存儲(chǔ)桶私有讀寫訪問(wèn)權(quán)限圖3-5如上所示，ACL描述了存儲(chǔ)桶擁有者(Owner)為（用戶UIN：10001xxx）,且此用戶擁有存儲(chǔ)桶的完全控制權(quán)限（FULL_CONTROL）。圖3-6默認(rèn)配置的當(dāng)前賬號(hào)權(quán)限策略因此，在公共權(quán)限里勾選私有讀寫，相當(dāng)于在ACL中不額外寫入任何配置內(nèi)容。公有讀私有寫任何人（包括匿名訪問(wèn)者）都對(duì)該存儲(chǔ)桶中的對(duì)象有讀權(quán)限，但只有存儲(chǔ)桶創(chuàng)建者及有授權(quán)的賬號(hào)才對(duì)該存儲(chǔ)桶中的對(duì)象有寫權(quán)限。圖3-7配置存儲(chǔ)桶公有讀私有寫訪問(wèn)權(quán)限圖3-8圖3-9公有讀寫

圖3-10公有讀私有寫權(quán)限配置示意圖圖3-11配置存儲(chǔ)桶公有讀寫訪問(wèn)權(quán)限圖3-12圖3-13AllUsersWRITE即“匿名用戶公有讀寫”權(quán)限，示意圖如下：圖3-14公有讀寫權(quán)限配置示意圖ACLAllUsersREADWRITE公共權(quán)限配置選項(xiàng)的總結(jié)如下：ACLACLAllUsersREADACLAllUsersREADAllUsersWRITE在分析完公共權(quán)限之后，我們來(lái)分析一下用戶權(quán)限。04.用戶權(quán)限04.用戶權(quán)限用戶權(quán)限和公共權(quán)限有什么區(qū)別呢？其實(shí)都是修改ACL策略，沒(méi)有本質(zhì)ACLALLUSers的三個(gè)權(quán)限，而通過(guò)ACL5圖3-15用戶權(quán)限配置可選項(xiàng)我們先保持公共權(quán)限的默認(rèn)設(shè)置——私有讀寫，并在控制臺(tái)編輯用戶權(quán)限，添加一個(gè)ID為123456的賬號(hào)。數(shù)據(jù)讀取-數(shù)據(jù)寫入我們?yōu)榇速~號(hào)設(shè)置數(shù)據(jù)讀取、數(shù)據(jù)寫入的權(quán)限，見(jiàn)下圖：圖3-16配置用戶數(shù)據(jù)讀取寫入權(quán)限通過(guò)訪問(wèn)API接口，獲取此時(shí)存儲(chǔ)桶ACL。圖3-17從XML內(nèi)容可見(jiàn)，在控制臺(tái)新增一個(gè)擁有數(shù)據(jù)讀取、數(shù)據(jù)寫入權(quán)限的賬號(hào)后，ACL中新增了如下配置：圖3-18ACL中增加了一個(gè)uin為123456的用戶的READ與WRITE權(quán)限，示意圖如下：權(quán)限讀取-權(quán)限寫入

圖3-19數(shù)據(jù)讀取寫入權(quán)限配置示意圖接下來(lái)我們保持公共權(quán)限為默認(rèn)的私有讀寫不變，并在用戶權(quán)限處添加一個(gè)ID為123456的賬號(hào)，我們?yōu)榇速~號(hào)設(shè)置權(quán)限讀取、權(quán)限寫入的權(quán)限，見(jiàn)下圖：圖3-20配置用戶權(quán)限讀取寫入權(quán)限圖3-21如上所示，在控制臺(tái)新增一個(gè)擁有權(quán)限讀取、權(quán)限寫入的賬號(hào)后，ACL圖3-22ACLuin123456READ_ACPWRITE_ACP123456ACL進(jìn)行讀取以及更新操作，示意圖如下：圖3-23權(quán)限讀取寫入權(quán)限配置示意圖公有讀寫-數(shù)據(jù)讀取-數(shù)據(jù)寫入圖3-24配置公有讀寫-數(shù)據(jù)讀寫權(quán)限通過(guò)訪問(wèn)API接口，獲取此時(shí)存儲(chǔ)桶ACL圖3-25通過(guò)對(duì)比公共權(quán)限章節(jié)中公有讀寫與用戶權(quán)限章節(jié)中數(shù)據(jù)讀取-數(shù)據(jù)寫入部分的內(nèi)容可以發(fā)現(xiàn),在控制臺(tái)中配置的公共權(quán)限與用戶權(quán)限是各自作用ACLACLACLAllUsersWRITEREAD123456數(shù)據(jù)讀取、數(shù)據(jù)寫入將在ACL123456READWRITE限。但是細(xì)心的讀者可能會(huì)發(fā)現(xiàn)一個(gè)有意思的問(wèn)題，在配置用戶權(quán)限時(shí)，ACL中默認(rèn)的Owner的FULL_CONTROL權(quán)限不見(jiàn)了消失的Owner權(quán)限圖3-26公有權(quán)限相同、用戶權(quán)限不同時(shí)ACL差異性雖然我們僅僅是在用戶權(quán)限處增加了一個(gè)新用戶，并沒(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)什么呢？圖3-2705.存儲(chǔ)桶策略（BucketPolicy）資源的擁有者，即Owner始終對(duì)資源具備完全控制權(quán)，無(wú)論ACL中是否存在此項(xiàng)。05.存儲(chǔ)桶策略（BucketPolicy）表3-3BucketPolicy屬性表我們可以通過(guò)在控制臺(tái)中添加策略的方式來(lái)設(shè)置Policy權(quán)限。圖3-28通過(guò)控制臺(tái)添加Policy圖3-29添加新策略API接口，獲取權(quán)限策略。3-30EffectPrincipalACL接下來(lái)，我們添加一個(gè)允許賬號(hào)ID為123456的賬號(hào)對(duì)aclxxx/policy_test圖3-31配置賬號(hào)指定資源操作權(quán)限圖3-32在這個(gè)Policy中，我們可以看到更細(xì)膩的Action與Resource配置。06.對(duì)象訪問(wèn)權(quán)限06.對(duì)象訪問(wèn)權(quán)限在對(duì)象存儲(chǔ)中，每一個(gè)對(duì)象同樣存在著可配置的訪問(wèn)權(quán)限，默認(rèn)繼承存儲(chǔ)桶的ACL。圖3-33對(duì)象訪問(wèn)權(quán)限控制臺(tái)界面我們將此對(duì)象設(shè)置為公有讀私有寫權(quán)限，見(jiàn)下圖：3-34通過(guò)查詢GetObjectAclAPI接口，獲取其ACL。圖3-34ACLACLACLACL07.訪問(wèn)策略評(píng)估機(jī)制ACLPolicy07.訪問(wèn)策略評(píng)估機(jī)制及到的重要概念：顯示拒絕、顯示允許、隱式拒絕以及三者之間的聯(lián)系：顯式拒絕：在用戶策略、用戶組策略、存儲(chǔ)桶Policy中針對(duì)特定用戶有明確的Deny策略。顯式允許：在用戶策略、用戶組策略、存儲(chǔ)桶Policy、存儲(chǔ)桶ACL中g(shù)rant-\*明確指定特定用戶針對(duì)特定用戶有明確的Allow策略。（未經(jīng)配置的情況下（deny。顯示拒絕、顯式允許、隱式拒絕之間的關(guān)系如下：如果在用戶組策略、用戶策略、存儲(chǔ)桶策略或者存儲(chǔ)桶/對(duì)象訪問(wèn)控制列表（和基于資源的策略（存儲(chǔ)桶策略或者存儲(chǔ)桶/對(duì)象訪問(wèn)控制列表）中策略條目的并集，根據(jù)顯示拒絕、顯式允許、隱式拒絕之間的關(guān)系計(jì)算出此時(shí)的權(quán)限策略。圖3-35存儲(chǔ)桶鑒權(quán)流程08.訪錯(cuò)誤配置導(dǎo)致的安全問(wèn)題08.訪錯(cuò)誤配置導(dǎo)致的安全問(wèn)題錯(cuò)誤使用公有讀寫權(quán)限公有讀寫權(quán)限導(dǎo)致的安全問(wèn)題。圖3-36配置存儲(chǔ)桶公有讀寫訪問(wèn)權(quán)限通過(guò)上文的分析可知，公有讀權(quán)限可以通過(guò)匿名身份直接讀取用戶存儲(chǔ)桶中的數(shù)據(jù)，存在著嚴(yán)重的安全隱患。2017商，在使用存儲(chǔ)桶進(jìn)行對(duì)象存儲(chǔ)時(shí)，也會(huì)犯下這樣的常見(jiàn)錯(cuò)誤。因此，為了保障存儲(chǔ)桶安全，建議用戶為存儲(chǔ)桶配置私有讀寫權(quán)限。存儲(chǔ)桶、對(duì)象訪問(wèn)權(quán)限差異性問(wèn)題這也是存儲(chǔ)桶的默認(rèn)公共權(quán)限配置，見(jiàn)下圖：圖3-37配置存儲(chǔ)桶私有讀寫權(quán)限桶中的對(duì)象有讀寫權(quán)限，其他任何人對(duì)該存儲(chǔ)桶中的對(duì)象都沒(méi)有讀寫權(quán)限。但是將存儲(chǔ)桶的公共權(quán)限設(shè)置為私有讀寫可以完全保護(hù)存儲(chǔ)桶中的中的對(duì)象資源不被讀取嗎?在我們測(cè)試的這個(gè)存儲(chǔ)桶中，并未設(shè)置Policy策略，并且存在著一個(gè)名為p2.png的對(duì)象。圖3-38p2.png對(duì)象而從上文可知，存儲(chǔ)桶中的對(duì)象也有著其對(duì)應(yīng)的對(duì)象權(quán)限。在這里我們將對(duì)象p2.png的ACL權(quán)限設(shè)置為公有讀私有寫，見(jiàn)下圖：圖3-39p2.png對(duì)象配置公有讀私有寫p2.pngurlp2.png圖：圖3-40成功訪問(wèn)p2.png對(duì)象限為公有讀私有寫時(shí)，此對(duì)象依然是可以被讀取的。p2.pngACLp2.pngACL圖3-41p2.pngAllUsersREADp2.png圖3-42訪問(wèn)p2.png時(shí)的鑒權(quán)流程因此，單單依靠存儲(chǔ)桶的訪問(wèn)權(quán)限，并不能保護(hù)其中資源的未授權(quán)訪問(wèn)情09.錯(cuò)誤授予的操作ACL權(quán)限09.錯(cuò)誤授予的操作ACL權(quán)限在PolicyACL（GET、圖3-43授予用戶操作ACL權(quán)限PolicyACLcoscmdcoscmdlist桶中內(nèi)容。圖3-43存儲(chǔ)桶l(fā)ist操作失敗p2.png圖3-44下載對(duì)象操作失敗圖3-45成功查看對(duì)象ACLACLp2.png圖3-46授予用戶p2.png讀權(quán)限圖3-47成功下載p2.png對(duì)象資源超范圍限定在使用存儲(chǔ)桶進(jìn)行對(duì)象讀取或?qū)懭氩僮鲿r(shí)，如果沒(méi)有合理的或者錯(cuò)誤的在Policy（resource用戶數(shù)據(jù)被惡意上傳覆蓋或被其他用戶下載等安全問(wèn)題。WebWeb/avatar/Policy/<APPID>:<BucketName-APPID>/avatar/*路徑。qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/*路徑中的所有資源的讀寫權(quán)限。圖3-48從流量中獲取臨時(shí)憑據(jù)在獲取了臨時(shí)密鑰之后，攻擊者憑借此憑據(jù)讀寫qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/*路徑中的任意對(duì)象。攻擊者圖3-49覆蓋其他用戶資源test.txt16.png讀取此目錄中其他用戶的文件。policyresource指定為qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/<Username>/*來(lái)滿足規(guī)范要求；此外，resource字段支持以數(shù)組的形式傳入多個(gè)值。因此，也可以顯式指定多個(gè)resource值來(lái)完全限定用戶有權(quán)限訪問(wèn)的最終資源路徑。寫在后面但是由于用戶使用對(duì)象存儲(chǔ)服務(wù)時(shí)安全意識(shí)不足或?qū)υL問(wèn)權(quán)限以及訪問(wèn)策ACL儲(chǔ)桶是否被侵害，確保云上資產(chǎn)的安全。參考文獻(xiàn)/2017/07/13/a-deep-dive-into-aws-s3-access-controls-taking-full-control-over-your-assets/2.https://blog.lightspin.io/how-to-access-aws-s3-buckets3.https://blog.lightspin.io/risks-of-misconfigured-s3-buckets4./document/product/436/402655./raw/document/intl/product/pdf/436_9511_zh.pdf四、Kubelet訪問(wèn)控制機(jī)制與提權(quán)方法研究四、Kubelet訪問(wèn)控制機(jī)制與提權(quán)方法研究本文翻譯整理自rhinokuberneteskubernetes集群中站穩(wěn)腳跟就會(huì)嘗試滲透集群涉及的所有容器，尤其是針對(duì)訪問(wèn)控制和隔離做的不夠好的集群受到的損害也會(huì)越大。例如由unit42研究人員檢測(cè)到的TeamTNT組織的惡意軟件SiloscapeAWS憑證或錯(cuò)誤配置從而獲得了kubelet訪問(wèn)權(quán)限后批量部署挖礦木馬或竊取關(guān)鍵信息如用戶名和密碼，組織機(jī)密和內(nèi)部文件，甚至控制集群中托管的整個(gè)數(shù)據(jù)庫(kù)從而發(fā)起勒索攻擊。根據(jù)微步在線的統(tǒng)計(jì)上一次遭受其攻擊的IP90%以上屬于中國(guó)，因此需要安全人員及時(shí)關(guān)注并提前規(guī)避風(fēng)險(xiǎn)。Siloscape4-1圖4-1Siloscape攻擊流程Kubernetes集群中所有的資源的訪問(wèn)和變更都是通過(guò)kubernetesAPIServerRESTAPI實(shí)現(xiàn)的，所以集群安全的關(guān)鍵點(diǎn)就在于如何識(shí)別并認(rèn)證客戶端身份并且對(duì)訪問(wèn)權(quán)限的鑒定，同時(shí)K8S還通過(guò)準(zhǔn)入控制的機(jī)制實(shí)現(xiàn)審計(jì)作用確保最后一道安全底線。除此之外K8S還配有一系列的安全機(jī)制（如SecretServiceAccount圖4-2KubernetesAPI請(qǐng)求圖4-3Kubectl操作0101 K8S認(rèn)證鑒權(quán)認(rèn)證階段（Authentication）表4-1認(rèn)證表X509kuberneteskubectl客戶端對(duì)應(yīng)的kube-config中經(jīng)常使用到的訪問(wèn)憑證，是一種比較安全的認(rèn)證方式。鑒權(quán)階段（Authorization）APIServer內(nèi)部通過(guò)用戶認(rèn)證后，就會(huì)執(zhí)行用戶鑒權(quán)流程，即通過(guò)API表4-2鑒權(quán)表其中Always策略要避免用于生產(chǎn)環(huán)境中，ABAC雖然功能強(qiáng)大但是難以理解且配置復(fù)雜逐漸被RBAC替代，如果RBAC無(wú)法滿足某些特定需求，可以自行編寫鑒權(quán)邏輯并通過(guò)Webhook方式注冊(cè)為kubernetes的授權(quán)服務(wù)，以實(shí)現(xiàn)更加復(fù)雜的授權(quán)規(guī)則。而Node鑒權(quán)策略主要是用于對(duì)kubelet發(fā)出的請(qǐng)求進(jìn)行訪問(wèn)控制，限制每個(gè)Node只訪問(wèn)它自身運(yùn)行的Pod及相關(guān)Service、Endpoints等信息。準(zhǔn)入控制（AdmissionControl）kubernetes30k8sk8slabel，一般運(yùn)行在驗(yàn)證型之前，混合型及兩者的結(jié)合。02. KubeletACAPIServeretcdAPIServer（02. Kubelet認(rèn)證Kubelet目前共有三種認(rèn)證方式:anonymous，這時(shí)可不配置客戶端證書(shū)authentication:anonymous:enabled:true2.webhook，這時(shí)可不配置客戶端證書(shū)authentication:webhook:enabled:trueTLSkubelet的HTTPS端點(diǎn)啟用X509客戶端證書(shū)認(rèn)證。authentication:anonymous:enabled:falsewebhook:enabled:falsex509:clientCAFile:xxxx然而在實(shí)際環(huán)境當(dāng)你想要通過(guò)kubectlkubelet時(shí)，無(wú)法傳bearertokens，所以無(wú)法使用webhookx509鑒權(quán)kubelet可配置兩種鑒權(quán)方式分別為AlwaysAllow和Webhook，默認(rèn)的及安全模式AlwaysAllow，允許所有請(qǐng)求。而Webhook的鑒權(quán)過(guò)程時(shí)委托給APIServer的，使用APIServer一樣的默認(rèn)鑒權(quán)模式即RBAC。通常在實(shí)際環(huán)境中需要我們通過(guò)TBAC戶組以及其相對(duì)應(yīng)的權(quán)限。并最終將用戶和角色綁定完成權(quán)限的配置。TLSbootstrappingTLS在實(shí)際實(shí)現(xiàn)的時(shí)候成本較高，尤其集群中眾多的kubelet都需要與kube-APIServerKubeletTLSBootstrapping就應(yīng)運(yùn)而生了。kubeletkube-APIServer之間的自動(dòng)認(rèn)APIServerK8sTLSbootstrappingkubeletAPIServerkubeletAPIServer提交自已的證書(shū)簽名請(qǐng)求文件（CSR），k8s-masterCSR發(fā)后，kubeletAPIServerAPIServer。具體如圖所示：圖4-4KubeletTLSbootstrapping工作流程03.Kubelet提權(quán)案例03.Kubelet提權(quán)案例攻擊路徑為了演示kubelet提權(quán)攻擊，下面會(huì)展示一個(gè)簡(jiǎn)單的攻擊場(chǎng)景，從獲取TLS引導(dǎo)憑據(jù)開(kāi)始，最終獲得集群中集群管理員的訪問(wèn)權(quán)限。圖4-5攻擊步驟KubeletAPIAPI更大的影響。1NodekubeletTLS圖4-62TLSkubernetes創(chuàng)建和檢索證書(shū)簽名請(qǐng)求的權(quán)限即引導(dǎo)憑據(jù)用來(lái)向控制端提交證書(shū)簽名請(qǐng)求（CSR）所以通常會(huì)看到找不到相關(guān)資源。4-7Kubec’llauthcan-i命令。3getcsrpod級(jí)別的數(shù)據(jù)。cfsslCSR，APIServerkube-controller-managerkubelet4-84-94、之后我們將批準(zhǔn)通過(guò)的證書(shū)保存，此時(shí)即可查看節(jié)點(diǎn)信息等相關(guān)內(nèi)容。4-115APIServer4-124-136pod4-144-154-164-177podAPIServerca.crttoken。圖4-18圖4-19圖4-20“cluster-admin4-214-22即其為最高權(quán)限的賬戶，至此我們可以執(zhí)行各種不同的攻擊。如從工作節(jié)點(diǎn)的實(shí)例竊取服務(wù)賬戶令牌訪問(wèn)云資源、列出配置、創(chuàng)建特權(quán)容器、后門容器等。04.緩解措施Kuberneteskubelet尤為重要，本案例通過(guò)泄露的憑據(jù)開(kāi)始，通過(guò)列出相關(guān)節(jié)點(diǎn)、實(shí)例生成和提交CSR充當(dāng)工作節(jié)點(diǎn)，并最終獲得集群管理員訪問(wèn)權(quán)限從而竊取TLSBootstrap04.緩解措施在實(shí)際生產(chǎn)環(huán)境中，一定要保護(hù)好kubelet憑證的數(shù)據(jù)避免類似的提權(quán)事件發(fā)生，同時(shí)還可以搭配以下幾點(diǎn)方式來(lái)加固k8s1、保護(hù)好元數(shù)據(jù)，元數(shù)據(jù)由于其敏感性務(wù)必在服務(wù)后臺(tái)加強(qiáng)對(duì)元數(shù)據(jù)讀取的管控，避免攻擊者通過(guò)元數(shù)據(jù)讀取到相關(guān)憑據(jù)信息，哪怕是低權(quán)限的憑據(jù)。2、通過(guò)更安全的網(wǎng)絡(luò)策略避免類似提權(quán)事件發(fā)生，默認(rèn)情況下拒絕所有出站通信，然后根據(jù)需要將出站流量列入白名單。在pod上應(yīng)用該網(wǎng)絡(luò)策略，因?yàn)樾枰L問(wèn)API服務(wù)器和元數(shù)據(jù)的是node而不是pod。3、啟用類似Istio這樣的服務(wù)網(wǎng)格并配置egressgateway，這將阻止部署在服務(wù)網(wǎng)格中的任何容器與任何未經(jīng)授權(quán)的主機(jī)進(jìn)行通信4、限制對(duì)主節(jié)點(diǎn)的網(wǎng)絡(luò)訪問(wèn)，如上案例基本都發(fā)生在集群，所以傳統(tǒng)的vpnk8s許多攻擊。參考文獻(xiàn)1.https://blogs.com/huanglingfa/p/13773234.html2./developer/article/15539473.https://kubernetes.io/zh/docs/reference/access-authn-authz/authentication//2018/01/07/kubernetes-tls-bootstrapping-note/五、國(guó)內(nèi)首個(gè)對(duì)象存儲(chǔ)攻防矩陣五、國(guó)內(nèi)首個(gè)對(duì)象存儲(chǔ)攻防矩陣IT2017“BoozAllenHamilton（提供情報(bào)與防御顧問(wèn)服務(wù)S347SECRET)“外籍禁閱”(NOFORN)01.對(duì)象存儲(chǔ)服務(wù)攻防矩陣概覽 01.對(duì)象存儲(chǔ)服務(wù)攻防矩陣概覽 2021926v1.0v1.0由云服務(wù)器、容器以及對(duì)象存儲(chǔ)服務(wù)攻防矩陣共同組成。本文將詳細(xì)介紹《云安全攻防矩陣v1.0》中關(guān)于對(duì)象存儲(chǔ)服務(wù)攻防矩陣部分內(nèi)容，以幫助開(kāi)發(fā)、運(yùn)維以及安全人員了解對(duì)象存儲(chǔ)服務(wù)的安全風(fēng)險(xiǎn)。02.初始訪問(wèn)02.初始訪問(wèn)云平臺(tái)主API密鑰泄露云平臺(tái)主API密鑰重要性等同于用戶的登錄密碼，其代表了賬號(hào)所有者的身份以及對(duì)應(yīng)的權(quán)限。APISecretIdSecretKeyAPIAPI進(jìn)而管理賬號(hào)下的資源。在一些攻擊場(chǎng)景中，由于開(kāi)發(fā)者不安全的開(kāi)發(fā)以及配置，或者一些針對(duì)設(shè)備的入侵事件，導(dǎo)致云平臺(tái)主API密鑰泄露，攻擊者可以通過(guò)竊取到的云平臺(tái)主API密鑰，冒用賬號(hào)所有者的身份入侵云平臺(tái)，非法操作對(duì)象存儲(chǔ)服務(wù)并篡改、竊取其中的數(shù)據(jù)。對(duì)象存儲(chǔ)SDK泄露云平臺(tái)所提供的對(duì)象存儲(chǔ)服務(wù)，除了擁有多種API接口外，還提供了豐富多樣的SDK供開(kāi)發(fā)者使用。在SDK初始化階段，開(kāi)發(fā)者需要在SDK中配置存儲(chǔ)桶名稱、路徑、地域等基本信息，并且需要配置云平臺(tái)的永久密鑰或臨時(shí)密鑰，這些信息將會(huì)被編寫在SDK代碼中以供應(yīng)用程序操作存儲(chǔ)桶。但是，如果這些承載著密鑰的代碼片段不慎泄露，比如開(kāi)發(fā)者誤將源碼上傳至公開(kāi)倉(cāng)庫(kù)或者應(yīng)用開(kāi)發(fā)商在為客戶提供的演示示例中未對(duì)自身SDK中憑據(jù)信息進(jìn)行刪除，這些場(chǎng)景將會(huì)導(dǎo)致對(duì)象存儲(chǔ)憑據(jù)泄露，進(jìn)而導(dǎo)致對(duì)象存儲(chǔ)服務(wù)遭受入侵，攻擊者通過(guò)冒用憑據(jù)所有者身份攻擊對(duì)象存儲(chǔ)服務(wù)。存儲(chǔ)桶工具配置文件泄露在對(duì)象存儲(chǔ)服務(wù)使用過(guò)程中，為了方便用戶操作存儲(chǔ)桶，官方以及開(kāi)源社區(qū)提供了大量的對(duì)象存儲(chǔ)客戶端工具以供用戶使用，在使用這些工具時(shí)，首先需要在工具的配置文件或配置項(xiàng)中填寫存儲(chǔ)服務(wù)相關(guān)信息以及用戶憑據(jù)，以便工具與存儲(chǔ)服務(wù)之間的交互。在某些攻擊場(chǎng)景下，例如開(kāi)發(fā)者個(gè)人PC受釣魚(yú)攻擊、開(kāi)發(fā)者對(duì)象存儲(chǔ)客戶端工具配置文件泄露等，這些編寫在存儲(chǔ)服務(wù)工具配置文件中的憑據(jù)以及存儲(chǔ)桶信息將會(huì)被泄露出來(lái)，攻擊者可以通過(guò)分析這些配置文件，從中獲取憑據(jù)，而在這些工具中配置的，往往又是用戶的云平臺(tái)主API密鑰，攻擊者通過(guò)這些信息可以控制對(duì)象存儲(chǔ)服務(wù)，在一些嚴(yán)重的場(chǎng)景，攻擊者甚至可以控制用戶的所有云上資產(chǎn)。前端直傳功能獲取憑據(jù)在一些對(duì)象存儲(chǔ)服務(wù)與Web開(kāi)發(fā)以及移動(dòng)開(kāi)發(fā)相結(jié)合的場(chǎng)景中，開(kāi)發(fā)者選擇使用前端直傳功能來(lái)操作對(duì)象存儲(chǔ)服務(wù)，前端直傳功能指的是利用iOS/Android/JavaScript等SDK通過(guò)前端直接向訪問(wèn)對(duì)象存儲(chǔ)服務(wù)。前端直傳功能，可以很好的節(jié)約后端服務(wù)器的帶寬與負(fù)載，但為了實(shí)現(xiàn)此功能，需要開(kāi)發(fā)者將憑據(jù)編寫在前端代碼中，雖然憑據(jù)存放于前端代碼中，可以被攻擊者輕易獲取，但這并不代表此功能不安全，在使用此功能時(shí)，只要遵守安全的開(kāi)發(fā)規(guī)范，則可以保證對(duì)象存儲(chǔ)服務(wù)的安全：正確的做法是使用臨時(shí)密鑰而非永久密鑰作為前端憑據(jù)，并且在生成臨時(shí)密鑰時(shí)按照最小權(quán)限原則進(jìn)行配置。但是實(shí)際應(yīng)用中，如果開(kāi)發(fā)人員并未遵循安全開(kāi)發(fā)原則，例如錯(cuò)誤的使用了永久密鑰，或?yàn)榕R時(shí)憑據(jù)配置了錯(cuò)誤的權(quán)限，這將導(dǎo)致攻擊者可以通過(guò)前端獲取的憑據(jù)訪問(wèn)對(duì)象存儲(chǔ)服務(wù)。攻擊者通過(guò)分析前端代碼，或者通過(guò)抓取流量的方式，獲得這些錯(cuò)誤配置生成的憑據(jù)，并以此發(fā)起攻擊。云平臺(tái)賬號(hào)非法登錄云平臺(tái)提供多種身份驗(yàn)證機(jī)制以供用戶登錄，包括手機(jī)驗(yàn)證、賬號(hào)密碼驗(yàn)證、郵箱驗(yàn)證等。在云平臺(tái)登錄環(huán)節(jié)，攻擊者通過(guò)多種手法進(jìn)行攻擊以獲使用用戶泄露賬號(hào)數(shù)據(jù)、騙取用戶登錄手機(jī)驗(yàn)證碼、盜取用戶登錄賬號(hào)等。攻擊者使用獲取到的賬號(hào)信息進(jìn)行非法登錄云平臺(tái)后，即可操作對(duì)象存儲(chǔ)服務(wù)。實(shí)例元數(shù)據(jù)服務(wù)未授權(quán)訪問(wèn)03.執(zhí)行云服務(wù)器實(shí)例元數(shù)據(jù)服務(wù)是一種提供查詢運(yùn)行中的實(shí)例內(nèi)元數(shù)據(jù)的服務(wù)，云服務(wù)器實(shí)例元數(shù)據(jù)服務(wù)運(yùn)行在鏈路本地地址上，當(dāng)實(shí)例向元數(shù)據(jù)服務(wù)發(fā)起請(qǐng)求時(shí)，該請(qǐng)求不會(huì)通過(guò)網(wǎng)絡(luò)傳輸，但是如果云服務(wù)器上的應(yīng)用存在RCE、SSRF等漏洞時(shí)，攻擊者可以通過(guò)漏洞訪問(wèn)實(shí)例元數(shù)據(jù)服務(wù)。通過(guò)云服務(wù)器實(shí)例元數(shù)據(jù)服務(wù)查詢，攻擊者除了可以獲取云服務(wù)器實(shí)例的一些屬性之外，更重要的是可以獲取與實(shí)例綁定的擁有操作對(duì)象存儲(chǔ)服務(wù)的角色，并通過(guò)此角色獲取對(duì)象存儲(chǔ)服務(wù)的控制權(quán)。03.執(zhí)行使用云API執(zhí)行命令攻擊者利用初始訪問(wèn)階段獲取到的擁有操作對(duì)象存儲(chǔ)服務(wù)的憑據(jù)后，可以通過(guò)向云平臺(tái)API接口發(fā)送HTTP/HTTPS請(qǐng)求，以實(shí)現(xiàn)與對(duì)象存儲(chǔ)后臺(tái)的交互操作。對(duì)象存儲(chǔ)服務(wù)提供了豐富的API接口以供用戶使用，攻擊者可以通過(guò)使用這些API接口并構(gòu)造相應(yīng)的參數(shù)，以此執(zhí)行對(duì)應(yīng)的對(duì)象存儲(chǔ)服務(wù)操作指令，例如下載存儲(chǔ)對(duì)象、刪除存儲(chǔ)對(duì)象以及更新存儲(chǔ)對(duì)象等。使用對(duì)象存儲(chǔ)工具執(zhí)行除了使用云API接口完成對(duì)象存儲(chǔ)服務(wù)的執(zhí)行命令操作之外，還可以選擇使用對(duì)象存儲(chǔ)工具來(lái)化簡(jiǎn)通過(guò)API接口使用對(duì)象存儲(chǔ)服務(wù)的操作。在配置完成存儲(chǔ)桶信息以及憑據(jù)后，攻擊者可以使用對(duì)象存儲(chǔ)工具執(zhí)行對(duì)象存儲(chǔ)服務(wù)相應(yīng)的操作名：通過(guò)執(zhí)行簡(jiǎn)單的命令行指令，以實(shí)現(xiàn)對(duì)存儲(chǔ)桶中對(duì)象的批量上傳、下載、刪除等操作。04.持久化04.持久化在存儲(chǔ)對(duì)象中植入后門針對(duì)對(duì)象存儲(chǔ)服務(wù)的持久化攻擊階段，主要依賴于業(yè)務(wù)中采用的代碼自動(dòng)化部署服務(wù)將植入后門的代碼自動(dòng)部署完成。在一些云上場(chǎng)景中，開(kāi)發(fā)者使用云托管業(yè)務(wù)來(lái)管理其Web應(yīng)用，云托管服務(wù)將使用者的業(yè)務(wù)代碼存儲(chǔ)于特定的存儲(chǔ)桶中，并采用代碼自動(dòng)化部署服務(wù)在代碼每次發(fā)生變更時(shí)都進(jìn)行構(gòu)建、測(cè)試和部署操作。05.權(quán)限提升在這些場(chǎng)景中，攻擊者可以在存儲(chǔ)桶中存儲(chǔ)的Web應(yīng)用代碼內(nèi)安插后門代碼或后門文件，并觸發(fā)代碼自動(dòng)化部署服務(wù)將后門部署至服務(wù)器以完成持久化操作。這些存儲(chǔ)著惡意后門將會(huì)持久的存在于Web應(yīng)用代碼中，當(dāng)服務(wù)器代碼遷移時(shí)，這些后門也將隨著遷移到新的服務(wù)器上部署。05.權(quán)限提升WrteAl對(duì)象存儲(chǔ)服務(wù)訪問(wèn)控制列表（ACL）是與資源關(guān)聯(lián)的一個(gè)指定被授權(quán)者和授予權(quán)限的列表，每個(gè)存儲(chǔ)桶和對(duì)象都有與之關(guān)聯(lián)的ACL。如果錯(cuò)誤的授權(quán)給一個(gè)子用戶操作存儲(chǔ)桶ACLACL的權(quán)限，即這并不表示此用戶不可以執(zhí)行上述操作，該用戶可以通過(guò)修改存儲(chǔ)桶以及對(duì)，將目標(biāo)對(duì)象設(shè)置為任意讀取權(quán)限，從而獲取了存儲(chǔ)桶以及存儲(chǔ)對(duì)象的操作權(quán)限。因此，賦予子用戶操作存儲(chǔ)桶ACLACL的權(quán)限，這個(gè)行為是及其危險(xiǎn)的。通過(guò)訪問(wèn)管理提權(quán)錯(cuò)誤的授予云平臺(tái)子賬號(hào)過(guò)高的權(quán)限，也可能會(huì)導(dǎo)致子賬號(hào)通過(guò)訪問(wèn)管理功能進(jìn)行提權(quán)操作。WriteAcl提權(quán)操作不同的是，由于錯(cuò)誤的授予云平臺(tái)子賬號(hào)過(guò)高的操作訪問(wèn)管理功能的權(quán)限，子賬號(hào)用戶可以通過(guò)訪問(wèn)管理功能自行授權(quán)策略，例如授權(quán)QcloudCOSFullAccess策略，此策略授予子賬號(hào)用戶對(duì)象存儲(chǔ)服務(wù)全讀寫訪問(wèn)權(quán)限，而非單純的修改存儲(chǔ)桶以及存儲(chǔ)對(duì)象的ACL。06.竊取憑證通過(guò)此攻擊手段，擁有操作對(duì)象存儲(chǔ)服務(wù)權(quán)限的子賬號(hào)，即使子賬號(hào)自身對(duì)目標(biāo)存儲(chǔ)桶、存儲(chǔ)對(duì)象無(wú)可讀可寫權(quán)限，子賬號(hào)可以通過(guò)在訪問(wèn)管理中修改其對(duì)象存儲(chǔ)服務(wù)的權(quán)限策略，越權(quán)操作存儲(chǔ)桶中資源。06.竊取憑證云服務(wù)憑證泄露在一些云上場(chǎng)景中，云服務(wù)會(huì)依托對(duì)象存儲(chǔ)服務(wù)存儲(chǔ)用戶Web應(yīng)用代碼，用以自動(dòng)化托管用戶的Web應(yīng)用程序。在這些場(chǎng)景中，用戶的Web應(yīng)用程序源碼將會(huì)存儲(chǔ)于存儲(chǔ)桶中，并且默認(rèn)以明文形式存儲(chǔ)，在泄露的Web應(yīng)用程序源碼中，往往存在著Web應(yīng)用開(kāi)發(fā)者用來(lái)調(diào)用其他云上服務(wù)的憑據(jù)，甚至存在云平臺(tái)主API密鑰，攻擊者可以通過(guò)分析泄露的Web應(yīng)用程序源碼來(lái)獲取這些憑據(jù)。用戶賬號(hào)數(shù)據(jù)泄露在一些場(chǎng)景中，開(kāi)發(fā)者使用對(duì)象存儲(chǔ)服務(wù)存儲(chǔ)其業(yè)務(wù)中的用戶數(shù)據(jù)，例如用戶的姓名、身份證號(hào)碼、電話等敏感數(shù)據(jù)，當(dāng)然也會(huì)包含用戶賬號(hào)密碼等憑據(jù)信息。07.橫向移動(dòng)攻擊者通過(guò)對(duì)存儲(chǔ)桶中用戶數(shù)據(jù)的提取與分析以竊取這些用戶的憑據(jù)數(shù)據(jù)，并通過(guò)獲取的信息進(jìn)行后續(xù)的攻擊。07.橫向移動(dòng)竊取云憑據(jù)橫向移動(dòng)通過(guò)存儲(chǔ)桶中Web應(yīng)用程序源代碼的分析，攻擊者可能會(huì)從Web應(yīng)用程序的配置文件中獲取的應(yīng)用開(kāi)發(fā)者用來(lái)調(diào)用其他云上服務(wù)的憑據(jù)。攻擊者利用獲取到的云憑據(jù)，橫向移動(dòng)到用戶的其他云上業(yè)務(wù)中。如果攻擊者獲取到的憑據(jù)為云平臺(tái)主API密鑰，攻擊者可以通過(guò)此密鑰橫向移動(dòng)到用戶的所有云上資產(chǎn)中。竊取用戶賬號(hào)攻擊其他應(yīng)用08.影響攻擊者通過(guò)從存儲(chǔ)桶中竊取的用戶賬號(hào)數(shù)據(jù)，用以橫向移動(dòng)至用戶的其他應(yīng)用中，包括用戶的非云上應(yīng)用。08.影響竊取存儲(chǔ)桶內(nèi)項(xiàng)目源碼當(dāng)開(kāi)發(fā)者使用對(duì)象存儲(chǔ)服務(wù)存儲(chǔ)項(xiàng)目源碼時(shí)，攻擊者可以通過(guò)執(zhí)行下載存儲(chǔ)桶中的存儲(chǔ)對(duì)象指令，獲取到存儲(chǔ)于存儲(chǔ)桶中的項(xiàng)目源碼，造成源碼泄露事件發(fā)生，通過(guò)對(duì)源碼的分析，攻擊者可以獲取更多的可利用信息。竊取存儲(chǔ)桶內(nèi)用戶數(shù)據(jù)當(dāng)用戶使用存儲(chǔ)服務(wù)存儲(chǔ)用戶數(shù)據(jù)時(shí)，攻擊者通過(guò)攻擊存儲(chǔ)服務(wù)，以竊等，當(dāng)用戶敏感信息泄露事件發(fā)生后，將會(huì)造成嚴(yán)重的影響。破壞存儲(chǔ)數(shù)據(jù)攻擊者在獲取存儲(chǔ)桶操作權(quán)限之后，可能試圖對(duì)存儲(chǔ)桶中存儲(chǔ)的數(shù)據(jù)進(jìn)行刪除或者覆蓋，以破壞用戶存儲(chǔ)的對(duì)象數(shù)據(jù)。篡改存儲(chǔ)數(shù)據(jù)除了破壞存儲(chǔ)服務(wù)中的用戶數(shù)據(jù)之外，攻擊者也可能會(huì)對(duì)存儲(chǔ)對(duì)象進(jìn)行篡改操作，通過(guò)篡改存儲(chǔ)桶中代碼、文本內(nèi)容、圖片等對(duì)象以達(dá)到攻擊效果。在一個(gè)常見(jiàn)的場(chǎng)景中，用戶使用對(duì)象存儲(chǔ)服務(wù)部署靜態(tài)網(wǎng)站，攻擊者通過(guò)篡改其中頁(yè)面內(nèi)的文本內(nèi)容以及圖片，對(duì)目標(biāo)站點(diǎn)造成不良的影響。植入后門攻擊者通過(guò)在對(duì)象存儲(chǔ)服務(wù)中存儲(chǔ)的Web應(yīng)用代碼中插入惡意代碼，或者在項(xiàng)目目錄中插入后門文件，當(dāng)這些植入后門的Web應(yīng)用代碼被部署至云服務(wù)器時(shí)，攻擊者可以利用這些后門發(fā)起進(jìn)一步的攻擊。當(dāng)用戶對(duì)存儲(chǔ)桶中的Web應(yīng)用代碼進(jìn)行遷移時(shí)，這些惡意代碼也將隨著業(yè)務(wù)代碼一同遷移。拒絕服務(wù)當(dāng)攻擊者擁有修改存儲(chǔ)桶以及其中對(duì)象Acl訪問(wèn)控制列表時(shí)，攻擊者可能會(huì)對(duì)存儲(chǔ)對(duì)象的Acl進(jìn)行修改，將一些本應(yīng)該公開(kāi)訪問(wèn)的存儲(chǔ)對(duì)象設(shè)置為私有讀寫，或者使一些本應(yīng)有權(quán)限訪問(wèn)的角色無(wú)權(quán)訪問(wèn)存儲(chǔ)對(duì)象。攻擊者可以通過(guò)此技術(shù)手段完成針對(duì)對(duì)象存儲(chǔ)服務(wù)的拒絕服務(wù)攻擊，從而影響目標(biāo)資源的可用性。寫在后面對(duì)象存儲(chǔ)服務(wù)作為一項(xiàng)重要的云上服務(wù)，承擔(dān)了存儲(chǔ)用戶數(shù)據(jù)的重要功能，深入了解對(duì)象存儲(chǔ)服務(wù)所面臨的風(fēng)險(xiǎn)點(diǎn)以及對(duì)應(yīng)的攻擊技術(shù)，可以有效的確保云上存儲(chǔ)服務(wù)安全性。v1.0以此制定監(jiān)測(cè)手段用以發(fā)現(xiàn)風(fēng)險(xiǎn)，詳見(jiàn)公眾號(hào)歷史文章：2021西部云安全峰會(huì)召開(kāi)亮相v1.0人工智能、云物聯(lián)網(wǎng)等云安全攻防矩陣。圖5-2六、SSRF漏洞帶來(lái)的新威脅六、SSRF漏洞帶來(lái)的新威脅在《淺談云上攻防——元數(shù)據(jù)服務(wù)帶來(lái)的安全挑戰(zhàn)》一文中，生動(dòng)形象的為我們講述了元數(shù)據(jù)服務(wù)所面臨的一系列安全問(wèn)題，而其中的問(wèn)題之一就SSRF2019年美國(guó)第一資本投資國(guó)際集團(tuán)（CapitalOneFinancialCorp.，下“CapitalOne）信息泄漏SSRF漏洞攻擊元數(shù)AKAKAK200臺(tái)服務(wù)器。具體攻擊路徑如圖所示：通過(guò)上述案例，我們可以看到在云場(chǎng)景中，由于云廠商提供云服務(wù)均使SSRF漏洞，此類邊界將不復(fù)存在，攻擊者可直接調(diào)用云廠商支持環(huán)境中的相應(yīng)接SSRFSSRF合所帶來(lái)的一些問(wèn)題以及SSRFSSRF的防護(hù)能力。01.SSRF漏洞對(duì)云環(huán)境帶來(lái)的影響01.SSRF漏洞對(duì)云環(huán)境帶來(lái)的影響SSRFSSRFSSRF(Server-SideRequestForgery：服務(wù)器端請(qǐng)求偽造)是一種由攻擊者構(gòu)造形成由服務(wù)端發(fā)起請(qǐng)求的一個(gè)安全漏洞。SSRF形成的原因大都是由于服務(wù)端提供了對(duì)外發(fā)起請(qǐng)求的功能且沒(méi)有對(duì)目標(biāo)地址做過(guò)濾與限制。SSRFSSRFSSRF。如圖ASSRFABB服務(wù)器發(fā)起攻擊。圖6-2SSRF原理在傳統(tǒng)環(huán)境中，SSRF漏洞的主要作用是幫助攻擊者突破網(wǎng)絡(luò)邊界，從而可以使攻擊者攻擊那些外網(wǎng)無(wú)法訪問(wèn)的內(nèi)部系統(tǒng)。而這些內(nèi)部系統(tǒng)往往都容易成為企業(yè)安全建設(shè)的盲區(qū)。從而導(dǎo)致企業(yè)內(nèi)網(wǎng)被攻破的概率增加。在傳統(tǒng)環(huán)境中，SSRF漏洞的危害基本可以分為以下四種：獲取敏感信息：攻擊者通過(guò)SSRF可以嘗試獲取一些存在敏感信息的系統(tǒng)文件或者網(wǎng)頁(yè)；內(nèi)網(wǎng)信息探測(cè)：攻擊者也可以通過(guò)SSRF去對(duì)內(nèi)網(wǎng)的主機(jī)和端口進(jìn)行IP服務(wù)；攻擊內(nèi)網(wǎng)應(yīng)用程序：根據(jù)獲取到的內(nèi)網(wǎng)服務(wù)的信息，攻擊者就可以有針對(duì)性的對(duì)內(nèi)網(wǎng)的web應(yīng)用，或者其他應(yīng)用程序進(jìn)行攻擊，如weblogic，redis，tomcatDOS如果有需要，攻擊者也可以利用SSRFDOS攻擊。在云環(huán)境中，SSRF漏洞除了傳統(tǒng)的攻擊內(nèi)網(wǎng)等攻擊方式外，也增加了一些云上特有的攻擊方式，這些攻擊方式一旦被攻擊者利用成功，往往都會(huì)對(duì)云上資產(chǎn)造成嚴(yán)重的危害。下面就將為大家一一介紹一下這些攻擊方式：攻擊元數(shù)據(jù)服務(wù)：在云環(huán)境中，元數(shù)據(jù)即表示實(shí)例的相關(guān)數(shù)據(jù)，可以用圖6-3元數(shù)據(jù)服務(wù)攻擊方式KubeletAPI：在云環(huán)境中，可通過(guò)KubeletAPIpodnode圖6-4針對(duì)KubeletAPI攻擊方式1近期我們也監(jiān)測(cè)到一個(gè)類似的案例，如下圖所示，測(cè)試人員通過(guò)發(fā)現(xiàn)的某個(gè)SSRF漏洞，通過(guò)訪問(wèn)集群中的KubeletAPI來(lái)執(zhí)行命令，從而獲取進(jìn)群內(nèi)容器的權(quán)限。圖6-5針對(duì)KubeletAPI攻擊方式2DockerRemoteAPI：DockerRemoteAPI是一個(gè)取代遠(yuǎn)程命令行界面（rcli）RESTAPI，默認(rèn)開(kāi)放端口為2375API如果存在未授權(quán)docker命令，獲取敏感信息，并獲取服root權(quán)限。因此為了安全考慮，一般不會(huì)在外網(wǎng)開(kāi)放，此時(shí)我們就SSRFDockerRemoteAPI。其過(guò)KubeletAPI越權(quán)攻擊云平臺(tái)內(nèi)其他組件或服務(wù)：由于云上各組件相互信任，當(dāng)云平臺(tái)SSRF漏洞時(shí)，就可通過(guò)此漏洞越權(quán)攻擊其他組件AAPI層會(huì)對(duì)請(qǐng)求進(jìn)行ASSRF漏洞，則可構(gòu)造請(qǐng)AABBAB圖6-6越權(quán)操作02.SSRF漏洞易出現(xiàn)的場(chǎng)景02.SSRF漏洞易出現(xiàn)的場(chǎng)景SSRFSSRF代理功能：webSSRF遠(yuǎn)程資源調(diào)用功能：SSRF。如weblogic的SSRF漏洞；文件上傳功能：type=url，type=filetype=url，然后將上傳內(nèi)容改為url，SSRF；數(shù)據(jù)庫(kù)內(nèi)置功能：mongodbcopyDatabaseIPSSRFapi：apiapi對(duì)象存儲(chǔ)功能：302cosSSR；03.SSRF漏洞防御繞過(guò)方法其他：htmlPDFSSRFPDFReacter03.SSRF漏洞防御繞過(guò)方法SSRFSSRF利用@符號(hào)繞過(guò)當(dāng)我們需要通過(guò)URL發(fā)送用戶名和密碼時(shí)，可以使用http://username:password@，此時(shí)@前的字符會(huì)被當(dāng)作用戶名密碼處理，@@//的檢測(cè)。利用進(jìn)制轉(zhuǎn)換繞過(guò)

圖6-7利用@符號(hào)繞過(guò)開(kāi)發(fā)人員在提取或者過(guò)濾域名或者IP時(shí)，未考慮到IP的進(jìn)制轉(zhuǎn)換的影IPIP人員會(huì)忽視這一點(diǎn)，因此有時(shí)，我們可以通過(guò)這一點(diǎn)去繞過(guò)防護(hù)。進(jìn)制轉(zhuǎn)換可以通過(guò)在線網(wǎng)站或者工具腳本完成，下面列舉常用十進(jìn)制和十六進(jìn)制的例子。十進(jìn)制/->http://2130706433/圖6-8利用十進(jìn)制繞過(guò)十六進(jìn)制：/->http://0x7F000001/圖6-9利用十六進(jìn)制繞過(guò)注意：160x，0利用30X跳轉(zhuǎn)繞過(guò)SSRF30X30X302python#!/usr/bin/envpython3importsysfromhttp.serverimportHTTPServer,BaseHTTPRequestHandleriflen(sys.argv)-1!=2:print("""Usage:{}<port_number><url>""".format(sys.argv[0]))sys.exit()classRedirect(BaseHTTPRequestHandler):defdo_GET(self):self.send_response(302)self.send_header('Location',sys.argv[2])self.end_headers()defsend_error(self,code,message=None):self.send_response(302)self.send_header('Location',sys.argv[2])self.end_headers()HTTPServer(("",int(sys.argv[1])),Redirect).serve_forever()使用方法：python302.pyport跳轉(zhuǎn)地址圖6-10302跳轉(zhuǎn)繞過(guò)利用短網(wǎng)址繞過(guò)

圖6-11302跳轉(zhuǎn)繞過(guò)SSRF302圖6-12利用短網(wǎng)址繞過(guò)圖6-13短網(wǎng)址繞過(guò)利用域名解析服務(wù)繞過(guò)圖6-14利用域名解析服務(wù)繞過(guò)利用添加端口的方式繞過(guò)IPIP->http://127.0.:80圖6-16利用添加端口的方式繞過(guò)利用將自己的域名解析到目標(biāo)內(nèi)網(wǎng)IP的方式繞過(guò)SSRFIPIPIP利用對(duì)象存儲(chǔ)回源功能繞過(guò)302本身的回源功能進(jìn)行繞過(guò)的方法。下面筆者會(huì)介紹如何去使用這種方法：新建一個(gè)存儲(chǔ)桶；圖6-18新建公有讀私有寫存儲(chǔ)桶圖6-19開(kāi)啟靜態(tài)網(wǎng)站圖6-20添加回源地址404/key，key為觸發(fā)的關(guān)鍵字，其他的默認(rèn)即可；圖6-21配置http狀態(tài)碼圖6-22配置回源地址（7）設(shè)置好之后，在可能存在ssrf的地方填上靜態(tài)網(wǎng)站的地址即可。DNS（DSRbidg）繞過(guò)SSRFDDNSDNSURL，URLURLhost；hostDNSIP；IPIPIPIPcurl在這個(gè)過(guò)程中，第一次去請(qǐng)求DNS服務(wù)進(jìn)行域名解析到第二次服務(wù)端去請(qǐng)求URLDNSURLDNSIPSSRFDNSRebinding具體原理如下：服務(wù)器端獲得URLD