云上安全攻防實(shí)戰(zhàn)手冊(cè)

目錄 來(lái)的安全挑戰(zhàn) 2Web中的元數(shù)據(jù)安全隱患 13三、對(duì)象存儲(chǔ)服務(wù)訪問(wèn)策略評(píng)估機(jī)制研究 23四、Kubelet訪問(wèn)控制機(jī)制與提權(quán)方法研究 48五、國(guó)內(nèi)首個(gè)對(duì)象存儲(chǔ)攻防矩陣 60六、SSRF漏洞帶來(lái)的新威脅 68CVE2020-8562漏洞為k8s帶來(lái)的安全挑戰(zhàn) 86八、云服務(wù)器攻防矩陣 94九、Etcd風(fēng)險(xiǎn)剖析 106 1前言。持續(xù)性威脅(APT)組織層出不窮，當(dāng)前全球范圍內(nèi)具備國(guó)家級(jí)攻擊力量的黑客2 一、元數(shù)據(jù)服務(wù)帶來(lái)的安全挑戰(zhàn)害。共下跌了15%。來(lái)的安全挑戰(zhàn)之前，我們先來(lái)簡(jiǎn)單介紹一下元數(shù)據(jù)服據(jù)服務(wù)數(shù)據(jù)，可以用來(lái)配置或管理正在運(yùn)行的實(shí)例。用3http254.169.254/latest/meta-data/54屬于鏈路本地地址(Link-localaddress)，鏈路本地地，是計(jì)算機(jī)網(wǎng)絡(luò)中一類(lèi)特殊的地址，它僅供于在網(wǎng)段，或通信使用。這類(lèi)主機(jī)通常不需要外部互聯(lián)網(wǎng)服務(wù)，僅有主管理程序)上。當(dāng)實(shí)例向元數(shù)據(jù)服務(wù)發(fā)起請(qǐng)求時(shí)，該請(qǐng)求不會(huì)通過(guò)網(wǎng)絡(luò)傳輸，于這個(gè)原理，元數(shù)據(jù)服務(wù)只能從實(shí)例內(nèi)部訪鏈路本地地址。從設(shè)計(jì)上來(lái)看，元數(shù)據(jù)服務(wù)例內(nèi)部發(fā)出的惡意的對(duì)元數(shù)據(jù)服務(wù)的未授權(quán)訪問(wèn)。攻擊者下訪問(wèn)管理角色是是擁有一組權(quán)限的虛擬身份，用于對(duì)角色載體授予云中4問(wèn)權(quán)限。用戶(hù)可以將角色關(guān)聯(lián)到云服務(wù)器實(shí)例。為實(shí)例可使用STS臨時(shí)密鑰訪問(wèn)云上其他服務(wù)度的權(quán)限控制擁有的訪問(wèn)權(quán)限具體的操作流程如下：在將角色成功綁定實(shí)例后，用戶(hù)可以在實(shí)例上訪問(wèn)元數(shù)據(jù)服務(wù)來(lái)查詢(xún)此角色的臨時(shí)憑據(jù)，并使用獲得的臨時(shí)憑據(jù)操作該角色權(quán)限下的云服務(wù)API接接下來(lái)我們將介紹下針對(duì)元數(shù)據(jù)服務(wù)的一些常見(jiàn)的攻擊模式。攻擊者可以首先通過(guò)目標(biāo)實(shí)例上的SSRF漏洞獲取與實(shí)例綁定的角色名稱(chēng)(rolename)。攻擊者可以構(gòu)造訪問(wèn)元數(shù)據(jù)接口的payload，并通過(guò)存在SSRF漏洞的參數(shù)傳遞：http://x.x.x.x/?url=54/latest/meta-data/iam/info，在獲取到角色名稱(chēng)后，攻擊者可以繼續(xù)通過(guò)SSRF漏洞獲取角色的臨時(shí)憑證：http://x.x.x.x/url=54/latest/metadata/iam/security-credentials/<rolename>獲取角色臨時(shí)憑據(jù)的案例可參見(jiàn)下圖:從上圖可見(jiàn)，攻擊者可以獲取角色的TmpSecretID以及TmpSecretKey。5在攻擊者成功獲取角色的臨時(shí)憑據(jù)后，將會(huì)檢查獲取到的角色臨時(shí)憑據(jù)的權(quán)限策略。有的時(shí)候，可以通過(guò)獲取到的角色名稱(chēng)，來(lái)猜測(cè)該角色的權(quán)限策略，例如角色名為：TKE_XXX，則這個(gè)角色很大可能是擁有操作TKE容器服此外，如果獲取的臨時(shí)密鑰擁有查詢(xún)?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)下圖：從上圖可見(jiàn)，攻擊者獲取到的與實(shí)例綁定的角色的臨時(shí)憑據(jù)權(quán)限策略是“AdministratorAccess”,這個(gè)策略允許管理賬戶(hù)內(nèi)所有用戶(hù)及其權(quán)限、財(cái)務(wù)相關(guān)的信息、云服務(wù)資產(chǎn)。2、通過(guò)使用臨時(shí)API憑據(jù)訪問(wèn)“獲取角色詳情”API接口，見(jiàn)下圖：通過(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)限，攻擊者將會(huì)嘗試竊取目標(biāo)數(shù)據(jù)。臨時(shí)憑據(jù)同樣也可以幫助攻擊者們?cè)谀繕?biāo)實(shí)例中執(zhí)行指令并控制實(shí)例權(quán)限。6與通過(guò)密鑰構(gòu)造請(qǐng)求這種方式發(fā)起攻擊相比，攻擊者們?cè)趯?shí)戰(zhàn)中更傾向于使用云命令行工具來(lái)進(jìn)行攻擊。云服務(wù)廠商為用戶(hù)提供了相應(yīng)的云命令行工具以管理云服務(wù)，例如騰訊中配置竊取到的API密鑰來(lái)對(duì)云資源進(jìn)行調(diào)用。與構(gòu)造請(qǐng)求訪問(wèn)云API接口這種方式相比，使用云命令行工具將會(huì)給攻擊者帶來(lái)更多便捷。AWSACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN配置完成后，可以使用云命令行工具在目標(biāo)實(shí)例上執(zhí)行在配置好密鑰后，攻擊者可以嘗試使用如下圖命令通過(guò)AWSCLI在實(shí)例中bash控制權(quán)限。借助通過(guò)元數(shù)據(jù)服務(wù)竊取到的憑據(jù)以及AWSCLI所提供的功能,攻擊者可以在實(shí)例中執(zhí)行反彈shell命令，由此進(jìn)入實(shí)例。7Userdata涉及到云廠商提供的一種功能，這項(xiàng)功能允許用戶(hù)自定義配置在實(shí)例啟動(dòng)時(shí)執(zhí)行的腳本的內(nèi)容。些代碼將會(huì)在實(shí)例每次啟動(dòng)時(shí)自動(dòng)執(zhí)行。以AWS舉例，攻擊者可以將惡意代碼寫(xiě)入my_script.txt文件中，然后執(zhí)行如下指令將my_script.txt文件中內(nèi)容導(dǎo)入userdata中。隨后，攻擊者通過(guò)如下命令重啟實(shí)例：userdata被執(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ě)入惡意代碼這項(xiàng)攻擊技術(shù)，也是可以運(yùn)用在持久化階段：通過(guò)在實(shí)例的userdata中寫(xiě)入惡意代碼，這些代碼將會(huì)在實(shí)例每次啟動(dòng)時(shí)自動(dòng)執(zhí)行。這將很好的完成持久化操作而不易被發(fā)現(xiàn)。8除此之外，攻擊者還可以嘗試在賬戶(hù)中創(chuàng)建一個(gè)新的用戶(hù)以進(jìn)行持久化，以AWSCLI舉例，攻擊者可以通過(guò)awsiamcreate-user--user-nameBob為Bob的用戶(hù)reateaccesskeyusernameBobBob創(chuàng)建憑據(jù)9雖然這個(gè)方法操作簡(jiǎn)單且有效，但是賬戶(hù)里突然新增的用戶(hù)及其容易被察覺(jué)，因此并不是一個(gè)特別有效的持久化方式。此外，攻擊者還會(huì)使用一種常見(jiàn)的持久化手法，那就是給現(xiàn)有的用戶(hù)分配額外的密鑰。以針對(duì)AWS的攻擊來(lái)說(shuō)，攻擊者可以使用aws_pwn這款工具/dagrz/aws_pwnawspwn者可以完成針對(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ù)并嘗試將其中的用戶(hù)數(shù)據(jù)復(fù)制到攻擊者的本地機(jī)器上。以AWSCLI為例，攻擊者可以通過(guò)如下命令將s3存儲(chǔ)桶中的內(nèi)容同步到地CapitalOne露事件舉例，攻擊者使用獲取到的角色臨時(shí)憑據(jù)，多次執(zhí)行“awss3ls”命令，獲取CapitalOne賬戶(hù)的存儲(chǔ)桶的完整列表；接著攻擊者使用sync命令將近30GB的CapitalOne用戶(hù)數(shù)據(jù)復(fù)制到了攻擊者本地?？偟膩?lái)說(shuō)，元數(shù)據(jù)服務(wù)為云上安全帶來(lái)了極大SSRF將會(huì)將其應(yīng)用于云上攻擊的各個(gè)階段。通過(guò)破壞用戶(hù)系統(tǒng)，濫用用戶(hù)資源、加密用戶(hù)資源并進(jìn)行勒索等手段影響用戶(hù)環(huán)境正常使用。F問(wèn)題，引入IMDSv2來(lái)改善其總體安全情況。在IMDSv2中，如果用戶(hù)想訪問(wèn)元數(shù)據(jù)服務(wù)，首先需要在實(shí)例內(nèi)部向X-aws-ec2-metadata-token-ttl-seconds用于指定生存時(shí)間(TTL)值(以秒為單位)，上文中生成的token有效期為6小時(shí)(21600秒)，在IMDSv2中21600秒是允許的最大TTL值。此請(qǐng)求將會(huì)返回一個(gè)token，后續(xù)訪問(wèn)元數(shù)據(jù)服務(wù)，需要在HTTPheader中攜帶此token，見(jiàn)如下請(qǐng)求：TOKEN=`curl-XPUT"54/latest/api/token"-H"X-aws-ec2-metadata-token-ttl-seconds:21600"curl54/latest/meta-data/profile-H“X-aws-ec2-metadata-token:$TOKEN”可見(jiàn)，在采用IMDSv2時(shí)，即使實(shí)例中應(yīng)用存在SSRF漏洞，攻擊者也無(wú)法輕易的利用SSRF漏洞向元數(shù)據(jù)服務(wù)發(fā)出PUT請(qǐng)求來(lái)獲取token，在沒(méi)有n據(jù)進(jìn)行后續(xù)的攻擊行為。除了使用PUT啟動(dòng)請(qǐng)求這項(xiàng)安全策略之外，IMDSv2還引入了如下兩個(gè)機(jī)制保證元數(shù)據(jù)服務(wù)的安全：值得注意的是，AWS認(rèn)為現(xiàn)有的實(shí)例元數(shù)據(jù)服務(wù)(IMDSv1)是完全安全的，IMDSv2方案的確可以有效的保護(hù)存在SSRF漏洞的實(shí)例，使其元數(shù)據(jù)不被攻擊者訪問(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)憑據(jù)訪問(wèn)角色綁定的一切云業(yè)務(wù)，具體流程見(jiàn)下圖：總之，當(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/3./@shurmajee/aws-enhances-metadata-service-security-with-imdsv2-b5d4b238454b4./smadnick/www/wp/2020-07.pdf5./dagrz/aws_pwn6./zh_cn/cli/latest/userguide/cli-services-s3-commands.html#using-s3-commands-managing-objects-sync7./zh_cn/IAM/latest/UserGuide/id_users_create.html8./cloud-security/aws-security-vulnerabilities-perspective/ Web應(yīng)用托管服務(wù)是一種常見(jiàn)的平臺(tái)即服務(wù)產(chǎn)品(PaaS)，可以用來(lái)運(yùn)行避免了應(yīng)用開(kāi)發(fā)過(guò)程中繁瑣的服務(wù)器搭建及運(yùn)維，使開(kāi)發(fā)者可以專(zhuān)注于業(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ù)查詢(xún)，因此不得不考慮元數(shù)據(jù)服務(wù)安全對(duì)Web應(yīng)用托管服務(wù)安全性的影響。通過(guò)“淺談云上攻防”系列文章《淺談云上攻防—元數(shù)據(jù)服務(wù)帶來(lái)的安全挑戰(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ù)與Web應(yīng)用托管服務(wù)這一組合存在的安在Web應(yīng)用托管服務(wù)中的元數(shù)據(jù)安全隱患章節(jié)中，我們將以AWS下的AWSElasticBeanstalk是AWS提供的平臺(tái)即服務(wù)(PaaS)產(chǎn)品，用于nstalk并預(yù)置一個(gè)或多個(gè)AWS資源(如AmazonEC2實(shí)例)來(lái)運(yùn)行應(yīng)用程序。ElasticElasticBeanstalkWeb用程序時(shí)，用戶(hù)可以通過(guò)上傳應(yīng)用程序代碼的zip或war文件來(lái)配置新應(yīng)用程序環(huán)境，見(jiàn)下圖：在進(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é)中用戶(hù)上傳的zip與war文件中的源代碼、應(yīng)用程序正常運(yùn)行所需的對(duì)象、日志、臨時(shí)配置文件等。elasticbeanstalk-region-account-id中存儲(chǔ)的對(duì)象列表以及其相關(guān)屬ElasticBeanstalk服務(wù)不會(huì)為其創(chuàng)建的AmazonS3存儲(chǔ)桶啟用默認(rèn)加密。這意味著，在默認(rèn)情況下，對(duì)象以未加密形式存儲(chǔ)在存儲(chǔ)桶中(并且只有授權(quán)用戶(hù)可以訪問(wèn))。在了解ElasticBeanstalk的使用之后，我們重點(diǎn)來(lái)看一下元數(shù)據(jù)服務(wù)與ElasticBeanstalk服務(wù)組合下的攻擊模式。SRFXXERCE漏洞，訪問(wèn)云服務(wù)器實(shí)例上的元數(shù)據(jù)服務(wù)，通過(guò)元數(shù)據(jù)服務(wù)查詢(xún)與云服務(wù)器實(shí)例綁定的角色以及其臨時(shí)憑據(jù)獲取，在竊取到角色的臨時(shí)憑據(jù)后，并根據(jù)竊取的角色臨時(shí)憑據(jù)相應(yīng)的權(quán)限策略，危害用戶(hù)對(duì)應(yīng)的云上資源。而在ElasticBeanstalk服務(wù)中也同樣存在著這種攻擊模式，ElasticBeanstalk服務(wù)創(chuàng)建名為aws-elasticbeanstalk-ec2-role的角色，并將其與云服務(wù)器實(shí)例綁定。awselasticbeanstalkec2-role角色的權(quán)限策略：從AWS官網(wǎng)可知，ElasticBeanstalk服務(wù)為aws-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)限策略。AWSElasticBeanstalkWebTier–授予應(yīng)用程序?qū)⑷罩旧蟼鞯紸mazonS3以及將調(diào)試信息上傳到AWSX-Ray的權(quán)限，見(jiàn)下圖：AWSElasticBeanstalkWorkerTier–授予日志上傳、調(diào)試、指標(biāo)發(fā)布和工作程序?qū)嵗蝿?wù)(包括隊(duì)列管理、定期任務(wù))的權(quán)限，見(jiàn)下圖：AWSElasticBeanstalkMulticontainerDocker–向AmazonElasticContainerService授予協(xié)調(diào)集群任務(wù)的權(quán)限，見(jiàn)下圖：e“elasticbeanstalk-”開(kāi)頭的S3存儲(chǔ)桶的讀取、寫(xiě)入權(quán)限以及遞歸訪問(wèn)權(quán)限，見(jiàn)下圖：通過(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”字lregion是資源所在的區(qū)域(例如，us-west-2)azonIDelasticbeanstalk-region-account-id存儲(chǔ)桶的名字。接下來(lái)介紹一下ElasticBeanstalk中元數(shù)據(jù)安全隱患：用戶(hù)在使用ElasticBeanstalk中部署Web應(yīng)用程序時(shí)，如果用戶(hù)的Web應(yīng)用程序源代碼中存在SSRF、XXE、RCE等漏洞，攻擊者可以利用這些漏洞訪問(wèn)元數(shù)據(jù)服務(wù)ole色的臨時(shí)憑據(jù)，并通過(guò)獲取到的信息對(duì)S3存儲(chǔ)桶發(fā)起攻擊，account-id、Region以及aws-elasticbeanstalk-ec2-role角色的臨時(shí)憑據(jù)獲取方式如下：者可以通過(guò)發(fā)送如下請(qǐng)求以獲取account-id、Region：https://x.x.x.x/ssrf.php?url=54/latest/dynamic/instance-identity/document。從響應(yīng)數(shù)據(jù)中Accountid、Region字段region-account-id存儲(chǔ)桶名稱(chēng)。攻擊者可以發(fā)送如下請(qǐng)求以獲取aws-elasticbeanstalk-ec2-role角色https://x.x.x.x/ssrf.php?url=54/latest/meta-data/iam/security-credentials/AWS-elasticbeanstalk-EC2-role。從AccessKeyId、SecretAccessKey、Token三個(gè)字段值。隨后，攻擊者使用獲取到的aws-elasticbeanstalk-ec2-role角色的臨上述攻擊模式的攻擊流程圖如下：elasticbeanstalk-region-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)用源代碼以及日志文件，具體操作如下：awss3cps3://elasticbeanstalk-region-account-id//攻擊者本地目錄–recursive。攻擊者可以通過(guò)在AWS命令行工具中配置獲取到的臨時(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)。具中配置獲取到的臨時(shí)憑據(jù)，并執(zhí)行如下指令將webshell文件上傳到存儲(chǔ)桶awss3cpwebshell.zips3://elasticbeanstalk-region-account-id/當(dāng)用戶(hù)使用AWSCodePipeline等持續(xù)集成與持續(xù)交付服務(wù)時(shí)，由于上傳webshell操作導(dǎo)致代碼更改，存儲(chǔ)桶中的代碼將會(huì)自動(dòng)在用戶(hù)實(shí)例上更新部l路徑進(jìn)而使用webshell對(duì)實(shí)例進(jìn)行權(quán)限控制。除了上文章節(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-role角色配置了較為合理的權(quán)限策略，使得即使Web應(yīng)用托管服務(wù)中托管的用戶(hù)應(yīng)用中存在漏洞時(shí)，攻擊者在訪問(wèn)實(shí)例元數(shù)據(jù)服務(wù)獲取aws-elasticbeanstalk-ec2-role角色的臨時(shí)憑據(jù)后，也僅僅有權(quán)限操作ElasticBeanstalk服務(wù)生成的elasticbeanstalk-region-account-idS3存儲(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ù)的其他業(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)行破壞，并竊取用戶(hù)數(shù)據(jù)。具體的攻擊模式可見(jiàn)下圖：由于攻擊者使用Web應(yīng)用托管服務(wù)生成的合法的角色身份，攻擊行為難以被發(fā)覺(jué)，對(duì)用戶(hù)安全造成極大的危害。針對(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)不需要將其他服務(wù)的資源訪問(wèn)權(quán)限(如數(shù)據(jù)庫(kù)讀寫(xiě)權(quán)限)授予給該角色。參考文獻(xiàn)1./zh_cn/elasticbeanstalk/latest/dg/iam-instanceprofile.html2./exploiting-ssrf-in-aws-elastic-beanstalk/3./zh_cn/elasticbeanstalk/latest/dg/con4.cepts-roles-instance.html5./2019/03/10/escalating-ssrf-to-rce/6./s/Y9CBYJ_3c2UI54Du6bneZA 三、對(duì)象存儲(chǔ)服務(wù)訪問(wèn)策略評(píng)估機(jī)制研究些模式的轉(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%。AllenHamilton公司(提供情報(bào)與防御顧問(wèn)服務(wù))在使用亞馬遜S3服務(wù)器存儲(chǔ)政府的敏感數(shù)據(jù)時(shí)，使用了錯(cuò)誤的配置，從而導(dǎo)致了政府保密信息可被公開(kāi)訪問(wèn)。經(jīng)安全研究人員發(fā)現(xiàn)，公開(kāi)訪問(wèn)的S3存儲(chǔ)桶中包含47個(gè)文件和文件夾，其中三個(gè)文件可供下載，其中包含了大量“絕密”(TOPSECRET)以及與此相似的案例有很多，例如Verizon數(shù)據(jù)泄露事件、道瓊斯客戶(hù)數(shù)據(jù)泄露事件。如何正確的使用以及配置存儲(chǔ)桶，成為了云上安全的一個(gè)重要環(huán)存儲(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)行了解。0101.對(duì)象存儲(chǔ)以進(jìn)行任意格式文件的上傳、002．存儲(chǔ)桶訪問(wèn)權(quán)限(ACL)訪問(wèn)控制列表(ACL)使用XML語(yǔ)言描述，是與資源關(guān)聯(lián)的一個(gè)指定被授從控制臺(tái)上來(lái)看，存儲(chǔ)桶訪問(wèn)權(quán)限分為公共權(quán)限與用戶(hù)權(quán)限，見(jiàn)下圖：從上圖的選項(xiàng)來(lái)看，公共權(quán)限和用戶(hù)權(quán)限配置共同組成了存儲(chǔ)桶訪問(wèn)權(quán)限。公共權(quán)限包括私有讀寫(xiě)、公有讀私有寫(xiě)和公有讀寫(xiě)這幾個(gè)選項(xiàng)可以選擇，用戶(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)。問(wèn)權(quán)√√√√√√√√但是公共權(quán)限與用戶(hù)權(quán)限有什么區(qū)別與關(guān)聯(lián)呢？二者又是如何作用于訪問(wèn)首先我們通過(guò)在控制臺(tái)中勾選的選項(xiàng)來(lái)測(cè)試一下公共權(quán)限是如何作用于0303.公共權(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ǔ)桶訪問(wèn)權(quán)限默認(rèn)為私有讀寫(xiě)。我們將公共權(quán)限設(shè)置為私有讀寫(xiě)，見(jiàn)下圖：如上所示，ACL描述了存儲(chǔ)桶擁有者(Owner)為(用戶(hù)UIN：10001xxx),且此用戶(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)的權(quán)限策略，見(jiàn)下圖紅框處：因此，在公共權(quán)限里勾選私有讀寫(xiě)，相當(dāng)于在ACL中不額外寫(xiě)入任何配公有讀私有寫(xiě)任何人(包括匿名訪問(wèn)者)都對(duì)該存儲(chǔ)桶中的對(duì)象有讀權(quán)限，但只有存儲(chǔ)桶創(chuàng)建者及有授權(quán)的賬號(hào)才對(duì)該存儲(chǔ)桶中的對(duì)象有寫(xiě)權(quán)限。我們將公共權(quán)限設(shè)置為公有讀私有寫(xiě)，見(jiàn)下圖：通過(guò)訪問(wèn)API接口，獲取此時(shí)存儲(chǔ)桶訪問(wèn)權(quán)限(ACL)條配置授予了AllUsers用戶(hù)組的READ的權(quán)限，按權(quán)限分類(lèi)來(lái)說(shuō)，屬于“匿名用戶(hù)公有讀”權(quán)限，示意圖如下：任何人(包括匿名訪問(wèn)者)都對(duì)該存儲(chǔ)桶中的對(duì)象有讀權(quán)限和寫(xiě)權(quán)限。如上所示，通過(guò)勾選公有讀寫(xiě)，ACL中新增了如下配置條目。04.04.用戶(hù)權(quán)限用戶(hù)權(quán)限和公共權(quán)限有什么區(qū)別呢？其實(shí)都是修改ACL策略，沒(méi)有本質(zhì)APIACL。從XML內(nèi)容可見(jiàn)，在控制臺(tái)新增一個(gè)擁有數(shù)據(jù)讀取、數(shù)據(jù)寫(xiě)入權(quán)限的賬接下來(lái)我們保持公共權(quán)限為默認(rèn)的私有讀寫(xiě)不變，并在用戶(hù)權(quán)限處添加一個(gè)ID為123456的賬號(hào)，我們?yōu)榇速~號(hào)設(shè)置權(quán)限讀取、權(quán)限寫(xiě)入的權(quán)限，APIACL。如上所示，在控制臺(tái)新增一個(gè)擁有權(quán)限讀取、權(quán)限寫(xiě)入的賬號(hào)后，ACL中新增了如下配置：時(shí)123456用戶(hù)可以對(duì)ACL進(jìn)行讀取以及更新操作，示意圖如下：在這環(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)榇速~號(hào)設(shè)置權(quán)限讀取、權(quán)限寫(xiě)入的權(quán)限，見(jiàn)下圖：APIACL通過(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è)者可能會(huì)發(fā)現(xiàn)一個(gè)有意思的問(wèn)題，在配置用戶(hù)權(quán)限時(shí)，ACLL私有讀寫(xiě)部分的ACL，我們發(fā)現(xiàn)了一個(gè)問(wèn)題，見(jiàn)雖然我們僅僅是在用戶(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)了答案：資源的擁有者，即Owner始終對(duì)資源具備完全控制權(quán)，無(wú)論ACL中是否。005.存儲(chǔ)桶策略(BucketPolicy)在分析完ACL之后，我們來(lái)看看Policy。存儲(chǔ)桶策略(BucketPolicy)使用JSON語(yǔ)言描述，支持向匿名身份或任何CAM賬戶(hù)授予對(duì)存儲(chǔ)桶、存儲(chǔ)桶操作、對(duì)象或?qū)ο蟛僮鞯臋?quán)限，在對(duì)象存儲(chǔ)中存儲(chǔ)桶策略可以用于管理該我們可以通過(guò)在控制臺(tái)中添加策略的方式來(lái)設(shè)置Policy權(quán)限。我們添加一個(gè)新策略，該策略允許所有用戶(hù)對(duì)我們的存儲(chǔ)桶進(jìn)行所有操API006.對(duì)象訪問(wèn)權(quán)限個(gè)對(duì)象同樣存在著可配置的訪問(wèn)權(quán)限，默認(rèn)繼承存儲(chǔ)：01顯式拒絕：在用戶(hù)策略、用戶(hù)組策略、存儲(chǔ)桶Policy中針對(duì)特定用戶(hù)02顯式允許：在用戶(hù)策略、用戶(hù)組策略、存儲(chǔ)桶Policy、存儲(chǔ)桶ACL中(deny)。如果在用戶(hù)組策略、用戶(hù)策略、存儲(chǔ)桶策略或者存儲(chǔ)桶/對(duì)象訪問(wèn)控制列表于資源的策略(存儲(chǔ)桶策略或者存儲(chǔ)桶/對(duì)象訪問(wèn)控制列表)中策略條目的并集，008.訪錯(cuò)誤配置導(dǎo)致的安全問(wèn)題承包權(quán)限差異性問(wèn)題但是將存儲(chǔ)桶的公共權(quán)限設(shè)置為私有讀寫(xiě)可以完全保護(hù)存儲(chǔ)桶中的中的對(duì)通過(guò)訪問(wèn)p2.png資源url可以發(fā)現(xiàn)，此時(shí)p2.png對(duì)象可以被訪問(wèn)，見(jiàn)下PUT)見(jiàn)下圖：象讀取或?qū)懭氩僮鲿r(shí)，如果沒(méi)有合理的或者錯(cuò)誤的在密鑰允許訪問(wèn)的resource指定為qcs:cos:<Region>:uidDavatart在獲取了臨時(shí)密鑰之后，攻擊者憑借此憑據(jù)讀寫(xiě)qcs::cos:<Region>:uid/<APPID>:<BucketName-APPID>/avatar/*路徑中的任意對(duì)象。攻擊者可以通過(guò)此方式覆蓋目錄中其他用戶(hù)資源，見(jiàn)下圖：qcscosRegion:uid/<APPID>:<BucketName-APPID>/avatar/<Usern因此，也可以顯式指定多個(gè)resource值來(lái)完全限定用戶(hù)有權(quán)限訪問(wèn)的最終資儲(chǔ)用戶(hù)數(shù)據(jù)的重要功能。但是由于用戶(hù)使用對(duì)象存儲(chǔ)服務(wù)時(shí)安全意識(shí)不足或?qū)υL問(wèn)權(quán)限以及訪問(wèn)策造成嚴(yán)重的安全問(wèn)題。httpslabsdetectifycomadeepdiveintoawss-access-controlstakingfullcontroloveryourassetshttpsbloglightspin.io/how-to-access-aws-s3-bucketshttpsbloglightspinio/risks-of-misconfigured-s3-bucketshttpscloudtencentcom/document/product/436/40265httpsmainqcloudimgcom/raw/document/intl/product/pdf/436_9511_zh.pdf 愈演愈烈之勢(shì)，一旦攻擊者在kubernetes集群中站穩(wěn)腳跟就會(huì)嘗試滲透集群涉及的所有容器，尤其是針對(duì)訪問(wèn)控制和隔離做的不夠好的集群受到的損害也會(huì)越大。例如由unit42研究人員檢測(cè)到的TeamTNT組織的惡意軟件Siloscape就是利用了泄露的AWS憑證或錯(cuò)誤配置從而獲得了kubelet初始訪問(wèn)權(quán)限后批量部署挖礦木馬或竊取關(guān)鍵信息如用戶(hù)名和密碼，組織機(jī)密和內(nèi)部文件，甚至控制集群中托管的整個(gè)數(shù)據(jù)庫(kù)從而發(fā)起勒索攻擊。根據(jù)微步在線的統(tǒng)計(jì)上一次遭受其攻擊的IP地址90%以上屬于中國(guó)，因此需要安全人Kubernetes集群中所有的資源的訪問(wèn)和變更都是通過(guò)kubernetesAPIServer的RESTAPI實(shí)現(xiàn)的，所以集群安全的關(guān)鍵點(diǎn)就在于如何識(shí)別并認(rèn)證客戶(hù)端身份并且對(duì)訪問(wèn)權(quán)限的鑒定，同時(shí)K8S還通過(guò)準(zhǔn)入控制的機(jī)制實(shí)現(xiàn)審計(jì)作用確保最后一道安全底線。除此之外K8S還配有一系列的安全機(jī)制(如Secret和ServiceAccount等)共同實(shí)現(xiàn)集群訪問(wèn)控制的安全，具體請(qǐng)求如其中用戶(hù)所控制的kubectl即每個(gè)Node節(jié)點(diǎn)都會(huì)啟用的進(jìn)程，可以把kubelet理解成【Server-Agent】架構(gòu)中的agent，用來(lái)處理Master節(jié)點(diǎn)下發(fā)到本節(jié)點(diǎn)的任務(wù)，管理Pod和其中的容器，比如創(chuàng)建容器、Pod掛載數(shù)據(jù)注冊(cè)節(jié)點(diǎn)信息，定期向Master匯報(bào)節(jié)點(diǎn)資源使用情況。如果沒(méi)有做好相關(guān)的權(quán)限管控或其遭受了任何的攻擊都可能導(dǎo)致對(duì)k8s集群更廣泛的危害。如以K認(rèn)證階段(Authentication)認(rèn)證階段即判斷用戶(hù)是否為能夠訪問(wèn)集群的合法用戶(hù)，APIServer目前提供了三種策略多種用戶(hù)身份認(rèn)證方式，他們分別如下表4-1：tl客戶(hù)端對(duì)應(yīng)的kube-config中經(jīng)常使用到的訪問(wèn)憑證，是一種比較安全的認(rèn)鑒權(quán)階段(Authorization)當(dāng)APIServer內(nèi)部通過(guò)用戶(hù)認(rèn)證后，就會(huì)執(zhí)行用戶(hù)鑒權(quán)流程，即通過(guò)鑒權(quán)策略決定一個(gè)API調(diào)用是否合法，APIServer目前支持以下鑒權(quán)策略其中Always策略要避免用于生產(chǎn)環(huán)境中，ABAC雖然功能強(qiáng)大但是難以理解且配置復(fù)雜逐漸被RBAC替代，如果RBAC無(wú)法滿(mǎn)足某些特定需求，可以現(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)久化etcd之前，攔截APIServer的請(qǐng)求，對(duì)請(qǐng)求的資源對(duì)象執(zhí)行自定義(校驗(yàn)、修改、拒絕等)操作。002.Kubelet認(rèn)證鑒權(quán)Kubelet有三種認(rèn)證方式:1.允許anonymous，這時(shí)可不配置客戶(hù)端證書(shū)atione2.webhook，這時(shí)可不配置客戶(hù)端證書(shū)ationwebhooke3.TLS認(rèn)證，也是目前默認(rèn)的認(rèn)證方式，對(duì)kubelet的HTTPS端點(diǎn)啟用X509客戶(hù)端證書(shū)認(rèn)證。ationewebhookeexxxx然而在實(shí)際環(huán)境當(dāng)你想要通過(guò)kubectl命令行訪問(wèn)kubelet時(shí)，無(wú)法傳遞bearertokens，所以無(wú)法使用webhook認(rèn)證，這時(shí)只能使用x509認(rèn)證。鑒權(quán)kubelet分別為AlwaysAllow和Webhook，默認(rèn)的及安全模式AlwaysAllow，允許所有請(qǐng)求。而Webhook的鑒權(quán)過(guò)程時(shí)委托給APIServerAPIServer一樣的默認(rèn)鑒權(quán)模式即RBAC。通常在實(shí)際環(huán)境中需要我們通過(guò)TBAC為用戶(hù)配置相關(guān)權(quán)限，包括配置用戶(hù)組以及其相對(duì)應(yīng)的權(quán)限。并最終將用戶(hù)和角色綁定完成權(quán)限的配置。TLSbootstrappingTLS在實(shí)際實(shí)現(xiàn)的時(shí)候成本較高，尤其集群中眾多的kubelet都需要與kube-APIServer通信，如果由管理員管理證書(shū)及權(quán)限，很有可能會(huì)因?yàn)樽C書(shū)過(guò)期等問(wèn)題出現(xiàn)混亂。這時(shí)候KubeletTLSBootstrapping就應(yīng)運(yùn)而生了。其主要實(shí)現(xiàn)兩個(gè)功能第一，實(shí)現(xiàn)kubelet與kube-APIServer之間的自動(dòng)認(rèn)證通信；第二，限制相關(guān)訪問(wèn)APIServer的權(quán)限。K8s目前默認(rèn)通過(guò)TLSbootstrapping這套機(jī)制為每個(gè)kubelet配置簽名證書(shū)確保與APIServer的交互安全。其核心思想是由kubelet自已生成及向APIServer提交自已的證書(shū)簽名請(qǐng)求文件(CSR)，k8s-master對(duì)CSR簽發(fā)后，kubelet再向APIServer獲取自已的簽名證書(shū)，然后再正常訪問(wèn)APIServer。具體如圖所示：0303.Kubelet提權(quán)案例路徑步驟創(chuàng)建和檢索證書(shū)簽名請(qǐng)求的權(quán)限即引導(dǎo)憑據(jù)用來(lái)向控制端提交證書(shū)簽名請(qǐng)求 (CSR)所以通常會(huì)看到找不到相關(guān)資源。srd8、接下來(lái)我們嘗試使用該token，設(shè)置好環(huán)境變量并獲取默認(rèn)命名空間中即其為最高權(quán)限的賬戶(hù)，至此我們可以執(zhí)行各種不同的攻擊。如從工作節(jié)點(diǎn)的實(shí)例竊取服務(wù)賬戶(hù)令牌訪問(wèn)云資源、列出配置、創(chuàng)建特權(quán)容器、后門(mén)露的憑據(jù)開(kāi)始，通過(guò)列出相關(guān)節(jié)點(diǎn)、實(shí)例生成和提交CSR充當(dāng)工作節(jié)點(diǎn)，并最終獲得集群管理員訪問(wèn)權(quán)限從而竊取TLSBootstrap憑據(jù)。04.04.緩解措施在實(shí)際生產(chǎn)環(huán)境中，一定要保護(hù)好kubelet憑證的數(shù)據(jù)避免類(lèi)似的提權(quán)事件發(fā)生，同時(shí)還可以搭配以下幾點(diǎn)方式來(lái)加固k8s的安全。1、保護(hù)好元數(shù)據(jù)，元數(shù)據(jù)由于其敏感性務(wù)必在服務(wù)后臺(tái)加強(qiáng)對(duì)元數(shù)據(jù)讀取的管控，避免攻擊者通過(guò)元數(shù)據(jù)讀取到相關(guān)憑據(jù)信息，哪怕是低權(quán)限的憑2、通過(guò)更安全的網(wǎng)絡(luò)策略避免類(lèi)似提權(quán)事件發(fā)生，默認(rèn)情況下拒絕所有3、啟用類(lèi)似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)的vpn也無(wú)法阻止相關(guān)危害，用戶(hù)可以直接限制對(duì)主服務(wù)器的訪問(wèn)來(lái)避免k8s的。參考文獻(xiàn)1./huanglingfa/p/13773234.html2./developer/article/15539473.https://kubernetes.io/zh/docs/reference/access-authn-authz/authentication/4./2018/01/07/kubernetes-tls-bootstrapping-note/ 五、國(guó)內(nèi)首個(gè)對(duì)象存儲(chǔ)攻防矩陣nS00L.對(duì)象存儲(chǔ)服務(wù)攻防矩陣概覽本文將詳細(xì)介紹《云安全攻防矩陣v1.0》中關(guān)于對(duì)象存儲(chǔ)服務(wù)攻防矩陣部02.02.初始訪問(wèn)API鑰泄露云平臺(tái)主API密鑰重要性等同于用戶(hù)的登錄密碼，其代表了賬號(hào)所有者的身份以及對(duì)應(yīng)的權(quán)限。云平臺(tái)API進(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ù)。API接口外，還提供了豐SDK要在SDK中配置存儲(chǔ)桶名稱(chēng)、路徑、地域等基本信息，并且需要配置云平臺(tái)的永久密鑰或臨時(shí)密鑰，這些信息將會(huì)被編寫(xiě)在SDK代碼中以供應(yīng)用程序操作存儲(chǔ)桶。但是，如果這些承載著密鑰的代碼片段不慎泄露，比如開(kāi)發(fā)者誤將源碼上傳至公開(kāi)倉(cāng)庫(kù)或者應(yīng)用開(kāi)發(fā)商在為客戶(hù)提供的演示示例中未對(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ù)。露在對(duì)象存儲(chǔ)服務(wù)使用過(guò)程中，為了方便用戶(hù)操作存儲(chǔ)桶，官方以及開(kāi)源社區(qū)提供了大量的對(duì)象存儲(chǔ)客戶(hù)端工具以供用戶(hù)使用，在使用這些工具時(shí)，首先需要在工具的配置文件或配置項(xiàng)中填寫(xiě)存儲(chǔ)服務(wù)相關(guān)信息以及用戶(hù)憑據(jù)，以便工具與存儲(chǔ)服務(wù)之間的交互。在某些攻擊場(chǎng)景下，例如開(kāi)發(fā)者個(gè)人PC遭受釣魚(yú)攻擊、開(kāi)發(fā)者對(duì)象存儲(chǔ)客戶(hù)端工具配置文件泄露等，這些編寫(xiě)在存儲(chǔ)服務(wù)工具配置文件中的憑據(jù)以及存儲(chǔ)桶信息將會(huì)被泄露出來(lái)，攻擊者可以通過(guò)分析這些配置文件，從中獲取憑據(jù)，而在這些工具中配置的，往往又是用戶(hù)的云平臺(tái)主API密鑰，攻擊者通過(guò)這些信息可以控制對(duì)象存儲(chǔ)服務(wù)，在一些嚴(yán)重的場(chǎng)景，攻擊者甚至可以控制用戶(hù)的所有云上資產(chǎn)。在一些對(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ù)編寫(xiě)在前端代碼中，雖然憑據(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)提供多種身份驗(yàn)證機(jī)制以供用戶(hù)登錄，包括手機(jī)驗(yàn)證、賬號(hào)密碼驗(yàn)證、郵箱驗(yàn)證等。在云平臺(tái)登錄環(huán)節(jié)，攻擊者通過(guò)多種手法進(jìn)行攻擊以獲弱口令、使用用戶(hù)泄露賬號(hào)數(shù)據(jù)、騙取用戶(hù)登錄手機(jī)驗(yàn)證碼、盜取用戶(hù)登錄賬號(hào)等。攻擊者使用獲取到的賬號(hào)信息進(jìn)行非法登錄云平臺(tái)后，即可操作對(duì)象存儲(chǔ)服務(wù)未授權(quán)訪問(wèn)云服務(wù)器實(shí)例元數(shù)據(jù)服務(wù)是一種提供查詢(xún)運(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ù)查詢(xún)，攻擊者除了可以獲取云服務(wù)器實(shí)例的一些屬性之外，更重要的是可以獲取與實(shí)例綁定的擁有操作對(duì)象存儲(chǔ)服務(wù)的角色，并通過(guò)此角色獲取對(duì)象存儲(chǔ)服務(wù)的控制權(quán)。0303.執(zhí)行I攻擊者利用初始訪問(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接口以供用戶(hù)使用，攻擊者可以通過(guò)使例如下載存儲(chǔ)對(duì)象、刪除存儲(chǔ)對(duì)象以及更新存儲(chǔ)對(duì)象等。除了使用云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.持久化針對(duì)對(duì)象存儲(chǔ)服務(wù)的持久化攻擊階段，主要依賴(lài)于業(yè)務(wù)中采用的代碼自動(dòng)化部署服務(wù)將植入后門(mén)的代碼自動(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è)試和部署操作。在這些場(chǎng)景中，攻擊者可以在存儲(chǔ)桶中存儲(chǔ)的Web應(yīng)用代碼內(nèi)安插后門(mén)代碼或后門(mén)文件，并觸發(fā)代碼自動(dòng)化部署服務(wù)將后門(mén)部署至服務(wù)器以完成持久化操作。這些存儲(chǔ)著惡意后門(mén)將會(huì)持久的存在于Web應(yīng)用代碼中，當(dāng)服務(wù)器代碼遷移時(shí)，這些后門(mén)也將隨著遷移到新的服務(wù)器上部署。05.05.權(quán)限提升WriteAcl提權(quán)對(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è)子用戶(hù)操作存儲(chǔ)桶ACL以及對(duì)象ACL的權(quán)限，即使該用戶(hù)并未被賦予讀取存儲(chǔ)桶、寫(xiě)入存儲(chǔ)桶、讀取對(duì)象、寫(xiě)入對(duì)象的權(quán)限，這并不表示此用戶(hù)不可以執(zhí)行上述操作，該用戶(hù)可以通過(guò)修改存儲(chǔ)桶以及對(duì)象的ACL，將目標(biāo)對(duì)象設(shè)置為任意讀取權(quán)限，從而獲取了存儲(chǔ)桶以及存儲(chǔ)對(duì)象的操作權(quán)限。因此，賦予子用戶(hù)操作存儲(chǔ)桶ACL以及對(duì)象ACL的權(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)操作。與通過(guò)WriteAcl提權(quán)操作不同的是，由于錯(cuò)誤的授予云平臺(tái)子賬號(hào)過(guò)高的操作訪問(wèn)管理功能的權(quán)限，子賬號(hào)用戶(hù)可以通過(guò)訪問(wèn)管理功能自行授權(quán)策略，例如授權(quán)QcloudCOSFullAccess策略，此策略授予子賬號(hào)用戶(hù)對(duì)象存儲(chǔ)服務(wù)全讀寫(xiě)訪問(wèn)權(quán)限，而非單純的修改存儲(chǔ)桶以及存儲(chǔ)對(duì)象的ACL。通過(guò)此攻擊手段，擁有操作對(duì)象存儲(chǔ)服務(wù)權(quán)限的子賬號(hào)，即使子賬號(hào)自身對(duì)目標(biāo)存儲(chǔ)桶、存儲(chǔ)對(duì)象無(wú)可讀可寫(xiě)權(quán)限，子賬號(hào)可以通過(guò)在訪問(wèn)管理中修改其對(duì)象存儲(chǔ)服務(wù)的權(quán)限策略，越權(quán)操作存儲(chǔ)桶中資源。06.06.竊取憑證在一些云上場(chǎng)景中，云服務(wù)會(huì)依托對(duì)象存儲(chǔ)服務(wù)存儲(chǔ)用戶(hù)Web應(yīng)用代碼，用以自動(dòng)化托管用戶(hù)的Web應(yīng)用程序。在這些場(chǎng)景中，用戶(hù)的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ù)賬號(hào)數(shù)據(jù)泄露在一些場(chǎng)景中，開(kāi)發(fā)者使用對(duì)象存儲(chǔ)服務(wù)存儲(chǔ)其業(yè)務(wù)中的用戶(hù)數(shù)據(jù)，例如用戶(hù)的姓名、身份證號(hào)碼、電話等敏感數(shù)據(jù)，當(dāng)然也會(huì)包含用戶(hù)賬號(hào)密碼等憑據(jù)信息。攻擊者通過(guò)對(duì)存儲(chǔ)桶中用戶(hù)數(shù)據(jù)的提取與分析以竊取這些用戶(hù)的憑據(jù)數(shù)據(jù)，并通過(guò)獲取的信息進(jìn)行后續(xù)的攻擊。07.07.橫向移動(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)到用戶(hù)的其他云上業(yè)務(wù)中。如果攻擊者獲取到的憑據(jù)為云平臺(tái)主API密鑰，攻擊者可以通過(guò)此密鑰橫向移動(dòng)到用戶(hù)的所有云上資產(chǎn)中。攻擊者通過(guò)從存儲(chǔ)桶中竊取的用戶(hù)賬號(hào)數(shù)據(jù)，用以橫向移動(dòng)至用戶(hù)的其他應(yīng)用中，包括用戶(hù)的非云上應(yīng)用。008.影響當(dāng)開(kāi)發(fā)者使用對(duì)象存儲(chǔ)服務(wù)存儲(chǔ)項(xiàng)目源碼時(shí)，攻擊者可以通過(guò)執(zhí)行下載存儲(chǔ)桶中的存儲(chǔ)對(duì)象指令，獲取到存儲(chǔ)于存儲(chǔ)桶中的項(xiàng)目源碼，造成源碼泄露事件發(fā)生，通過(guò)對(duì)源碼的分析，攻擊者可以獲取更多的可利用信息。當(dāng)用戶(hù)使用存儲(chǔ)服務(wù)存儲(chǔ)用戶(hù)數(shù)據(jù)時(shí)，攻擊者通過(guò)攻擊存儲(chǔ)服務(wù)，以竊取用戶(hù)敏感數(shù)據(jù)，這些信息可能包含用戶(hù)的姓名、證件號(hào)碼、電話、賬號(hào)信息等，當(dāng)用戶(hù)敏感信息泄露事件發(fā)生后，將會(huì)造成嚴(yán)重的影響。攻擊者在獲取存儲(chǔ)桶操作權(quán)限之后，可能試圖對(duì)存儲(chǔ)桶中存儲(chǔ)的數(shù)據(jù)進(jìn)行刪除或者覆蓋，以破壞用戶(hù)存儲(chǔ)的對(duì)象數(shù)據(jù)。數(shù)據(jù)除了破壞存儲(chǔ)服務(wù)中的用戶(hù)數(shù)據(jù)之外，攻擊者也可能會(huì)對(duì)存儲(chǔ)對(duì)象進(jìn)行以達(dá)到攻擊效果。在一個(gè)常見(jiàn)的場(chǎng)景中，用戶(hù)使用對(duì)象存儲(chǔ)服務(wù)部署靜態(tài)網(wǎng)站，攻擊者通過(guò)篡改其中頁(yè)面內(nèi)的文本內(nèi)容以及圖片，對(duì)目標(biāo)站點(diǎn)造成不良的影響。門(mén)攻擊者通過(guò)在對(duì)象存儲(chǔ)服務(wù)中存儲(chǔ)的Web應(yīng)用代碼中插入惡意代碼，或者在項(xiàng)目目錄中插入后門(mén)文件，當(dāng)這些植入后門(mén)的Web應(yīng)用代碼被部署至云服務(wù)器時(shí)，攻擊者可以利用這些后門(mén)發(fā)起進(jìn)一步的攻擊。當(dāng)用戶(hù)對(duì)存儲(chǔ)桶中的Web應(yīng)用代碼進(jìn)行遷移時(shí)，這些惡意代碼也將隨著業(yè)務(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è)置為私有讀寫(xiě)，或者使一些本應(yīng)有權(quán)限訪問(wèn)的角色無(wú)權(quán)訪問(wèn)存儲(chǔ)對(duì)象。攻擊者可以通過(guò)此技術(shù)手段完成針對(duì)對(duì)象存儲(chǔ)服務(wù)的拒絕服務(wù)攻擊，從而影響目標(biāo)資源的可用性。 在《淺談云上攻防——元數(shù)據(jù)服務(wù)帶來(lái)的安全挑戰(zhàn)》一文中，生動(dòng)形象的為我們講述了元數(shù)據(jù)服務(wù)所面臨的一系列安全問(wèn)題，而其中的問(wèn)題之一就是通過(guò)SSRF去攻擊元數(shù)據(jù)服務(wù)；文中列舉了2019年美國(guó)第一資本投資國(guó)際集團(tuán)(CapitalOneFinancialCorp.，下“CapitalOne公司”)信息泄漏的案例；我們內(nèi)部也監(jiān)測(cè)到過(guò)類(lèi)似的事件：測(cè)試人員通過(guò)SSRF漏洞攻擊元數(shù)AK最終通過(guò)獲取到的AK信息控制了超過(guò)200臺(tái)服務(wù)器。具體攻擊：通過(guò)上述案例，我們可以看到在云場(chǎng)景中，由于云廠商提供云服務(wù)均使用同一套網(wǎng)絡(luò)邊界和鑒權(quán)系統(tǒng)，且各云組件默認(rèn)相互信任。此時(shí)一旦存在SSRF漏洞，此類(lèi)邊界將不復(fù)存在，攻擊者可直接調(diào)用云廠商支持環(huán)境中的相應(yīng)接口，因此SSRF漏洞在云環(huán)境中更具有危害性。為此本文就SSRF與云環(huán)境結(jié)合所帶來(lái)的一些問(wèn)題以及SSRF常見(jiàn)的一些繞過(guò)方法進(jìn)行了整理，希望通過(guò)對(duì)這些方法的學(xué)習(xí)來(lái)提高我們?cè)谠粕蠈?duì)于SSRF的防護(hù)能力。在介紹SSRF漏洞在云場(chǎng)景中的危害之前，這里先為大家簡(jiǎn)單介紹一下什么是SSRF漏洞。SSRF(Server-SideRequestForgery：服務(wù)器端請(qǐng)求偽造)是一種由攻擊者構(gòu)造形成由服務(wù)端發(fā)起請(qǐng)求的一個(gè)安全漏洞。SSRF形成的原因大都是由于服務(wù)端提供了對(duì)外發(fā)起請(qǐng)求的功能且沒(méi)有對(duì)目標(biāo)地址做過(guò)濾與SSRF為回顯型SSRF和非回顯型SSRF。如圖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)(1)獲取敏感信息：攻擊者通過(guò)SSRF可以嘗試獲取一些存在敏感信息的系統(tǒng)文件或者網(wǎng)頁(yè)；(2)內(nèi)網(wǎng)信息探測(cè)：攻擊者也可以通過(guò)SSRF去對(duì)內(nèi)網(wǎng)的主機(jī)和端口進(jìn)針對(duì)性的對(duì)內(nèi)網(wǎng)的web應(yīng)用，或者其他應(yīng)用程序進(jìn)行攻擊，如weblogic，(4)DOS攻擊：如果有需要，攻擊者也可以利用SSRF企業(yè)服務(wù)進(jìn)行DOS攻擊。在云環(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ù)，可以用來(lái)配置或管理正在運(yùn)行中的實(shí)例。攻擊通過(guò)SSRF去訪問(wèn)元數(shù)據(jù)中存儲(chǔ)的臨時(shí)密鑰或者用于自啟動(dòng)實(shí)例的啟動(dòng)腳本，這些腳本可能會(huì)包含AK、密碼、源碼等等，然后根據(jù)從元數(shù)據(jù)服務(wù)獲取的信息，攻擊者可嘗試獲取到受害者賬戶(hù)下COS、CVM、集群等服務(wù)的權(quán)限。具體攻擊方式如下圖所示：攻擊KubeletAPI：在云環(huán)境中，可通過(guò)KubeletAPI查詢(xún)集群pod和但是，攻擊者可以通過(guò)SSRF去訪問(wèn)KubeletAPI，獲取信息和執(zhí)行命令。具體攻擊方式如下圖所近期我們也監(jiān)測(cè)到一個(gè)類(lèi)似的案例，如下圖所示，測(cè)試人員通過(guò)發(fā)現(xiàn)的攻擊DockerRemoteAPI：DockerRemoteAPI是一個(gè)取代遠(yuǎn)程命令行界面(rcli)的RESTAPI，默認(rèn)開(kāi)放端口為2375。此API如果存在未授權(quán)訪問(wèn)，則攻擊者可以利用其執(zhí)行docker命令，獲取敏感信息，并獲取服務(wù)器root權(quán)限。因此為了安全考慮，一般不會(huì)在外網(wǎng)開(kāi)放，此時(shí)我們就可以通過(guò)SSRF去嘗試攻擊那些不對(duì)外開(kāi)放的DockerRemoteAPI。其過(guò)越權(quán)攻擊云平臺(tái)內(nèi)其他組件或服務(wù)：由于云上各組件相互信任，當(dāng)云平臺(tái)內(nèi)某個(gè)組件或服務(wù)存在SSRF漏洞時(shí)，就可通過(guò)此漏洞越權(quán)攻擊其他組件校驗(yàn)，其中包括身份、權(quán)限等。如果服務(wù)A存在SSRF漏洞，則可構(gòu)造請(qǐng)02.02.55RF漏洞易出現(xiàn)的場(chǎng)景RF方法，這些手段很容易就繞過(guò)舊的防御策略。下面就為大httpusernamepasswordwwwxxxcom，此時(shí)@前的字符會(huì)被當(dāng)作用戶(hù)名制轉(zhuǎn)換繞過(guò)時(shí)，我們可以通過(guò)這一點(diǎn)去繞過(guò)防護(hù)。進(jìn)制轉(zhuǎn)換可http0.0.1/->http://2130706433/圖6-8利用十進(jìn)制繞過(guò)http0.0.1/->http://0x7F000001/圖6-9利用十六進(jìn)制繞過(guò)利用30X跳轉(zhuǎn)繞過(guò)X有時(shí)候會(huì)忽略這一點(diǎn)，在防護(hù)的時(shí)候只對(duì)第一次請(qǐng)求的鏈略了跳轉(zhuǎn)后的鏈接，因此可以通過(guò)這種方式去嘗試?yán)@過(guò)系serverimportHTTPServerBaseHTTPRequestHandleriflen(sys.argv)-1!=2:ntUsage{}<port_number><url>sysargvctBaseHTTPRequestHandlerlfnseheaderLocationsysargvsenderrorselfcodemessageNonenseheaderLocationsysargvelfendheadersHTTPServerintsysargvedirectserveforever網(wǎng)址繞過(guò)域名可能還做過(guò)認(rèn)證，在某些時(shí)候被信任的可能比個(gè)人網(wǎng)上都有搭建好的服務(wù)，方便快捷。因此本文將短網(wǎng)圖6-12利用短網(wǎng)址繞過(guò)圖6-13短網(wǎng)址繞過(guò)名解析服務(wù)繞過(guò)IP此類(lèi)服務(wù)有一個(gè)功能就是將xxx方便。因此有時(shí)候也可以嘗試?yán)么朔N方法去繞過(guò)系統(tǒng)的圖6-14利用域名解析服務(wù)繞過(guò)圖6-15利用域名解析服務(wù)繞過(guò)加端口的方式繞過(guò)圖6-16利用添加端口的方式繞過(guò)利用將自己的域名解析到目標(biāo)內(nèi)網(wǎng)IP的方式繞過(guò)象存儲(chǔ)回源功能繞過(guò)(1)新建一個(gè)存儲(chǔ)桶；圖6-17新建存儲(chǔ)桶(2)設(shè)置權(quán)限為公有讀私有寫(xiě)，其他的默認(rèn)即可；圖6-18新建公有讀私有寫(xiě)存儲(chǔ)桶(3)開(kāi)啟靜態(tài)網(wǎng)站；(4)在回源設(shè)置處添加回源規(guī)則；(6)源站設(shè)置頁(yè)面，回源地址填寫(xiě)要訪問(wèn)的地址，這塊限制了內(nèi)網(wǎng)地址，據(jù)需要填寫(xiě)。(7)設(shè)置好之后，在可能存在ssrf的地方填上靜態(tài)網(wǎng)站的地址即可。利用DNS重綁定(DNSRebinding)繞過(guò)RF以服務(wù)器端返回訪問(wèn)內(nèi)網(wǎng)資源的結(jié)果。名繞過(guò)httplocalhosthttp///http/利用封閉式字母數(shù)字(EnclosedAlphanumerics)字符繞過(guò)封閉式字母數(shù)字(EnclosedAlphanumerics)字符是一個(gè)Unicode塊，其中的字母數(shù)字塊包含一個(gè)表情符號(hào)，封閉的M用作掩碼工作的符號(hào)。它默認(rèn)為文以下是在網(wǎng)上搜集的一個(gè)封閉式字母數(shù)字(EnclosedAlphanumerics)字符號(hào)繞過(guò)IPIP進(jìn)行特性繞過(guò)。如>>>127.0.利用IPv6繞過(guò)合拳繞過(guò)一些問(wèn)題都一一進(jìn)行了防護(hù)，但在銜接的時(shí)候邏時(shí)候單一種方法往往是不行的，可以嘗試幾種方法的組FSRF習(xí)新的知識(shí)，以攻促oudtencentcomdeveloperarticle/index.php/blog/msg/179./1135/notes/blob/master/web_vul_SSRF.md./s/0wdxfetcp8TUtLZFWI16uA./p/73736127.http://byd.dropsec.xyz/2017/11/21/SSRF%E7%BB%95%E8%BF%87%E6%96%B9%E6%B3%95%E6%80%BB%E7%BB%93/httpswwwshuzhiduocomALPdoepLgJhttpblogleanotecom/post/snowming/e2c24cf057a4httpsmpweixinqqcom/s/Y9CBYJ_3c2UI54Du6bneZAhttpswwwfreebufcomarticlesweb79910.htmlhttpssirleeroyjenkinsmediumcomjustgopheritescalatinga-blind-ssrf-torceforkfa4530 Kubernetes為了緩解CVE-2020-8555等歷史漏洞帶來(lái)的安全問(wèn)題，對(duì)APIServerProxy請(qǐng)求進(jìn)行域名解析以校驗(yàn)請(qǐng)求的IP地址是否處于本地鏈路方式禁止由用戶(hù)觸發(fā)的對(duì)Services，Pods，Nodes，StorageClass對(duì)象的內(nèi)網(wǎng)httpsgithubcomkuberneteskubernetesissues/101493來(lái)看看這個(gè)漏洞中應(yīng)用到主要攻擊技巧：DNS重綁定攻擊(DNSRebinding)。DNS重綁定攻擊技術(shù)的實(shí)現(xiàn)主要依賴(lài)于攻擊者可將其自建的DNS服務(wù)器中AETKRseurldstshostDNSAipdevip.87";if($ip===$dev_ip){ntfilegetcontentsdst}這道CTF題目需要參賽者訪問(wèn)內(nèi)網(wǎng)地址并獲取存儲(chǔ)于其中的ipdnsgetrecordreshostDNSA)[0]['ip'];devip.87";ntfilegetcontentsdst地址是否位于本地鏈路(/16)或localhost(/8)范圍Kubernetes通過(guò)此方式防止惡意內(nèi)網(wǎng)資源的Proxy訪問(wèn)行為，但是IP這種攻擊技術(shù)將為云服務(wù)商帶來(lái)了極大的安全問(wèn)題：大多數(shù)云服務(wù)商提供托管，如果攻擊者通過(guò)方式訪問(wèn)到本地鏈路(/16)或localhostCVE漏洞原理景下，我們創(chuàng)建的集群的Master節(jié)點(diǎn)將與其他采用托管服務(wù)的用戶(hù)一并，由云es從上圖紅框處可以發(fā)現(xiàn)，此時(shí)我們創(chuàng)建的cve-2020-8562節(jié)點(diǎn)的狀態(tài)為在成功啟動(dòng)KubernetesAPI服務(wù)器的代理之后，通過(guò)如下命令使用cve-2020-8562節(jié)點(diǎn)，Kubernetes首先需要獲取cve-2020-8562節(jié)點(diǎn)的通過(guò)此方式，可以訪問(wèn)其他使用Kubernetes托管集群服務(wù)的租戶(hù)的0505總結(jié)s人員以及運(yùn)維人員的相應(yīng)重視。ithubcomkuberneteskubernetesissueshttpszhuanlanzhihucomp89426041httpscloudtencentcomdeveloperarticle400018 八、云服務(wù)器攻防矩陣AWSLaunchingEC2sdidnotrequirespecifyingAMIowner漏洞(CVE-2018-e。02.02.初始訪問(wèn)APII在攻擊者可以通過(guò)竊取到的云平臺(tái)主API密鑰后，冒用賬號(hào)所有者的身份泄露取持定的劫持風(fēng)險(xiǎn)。以送特定主題的釣魚(yú)郵件、行交流，通過(guò)竊取憑據(jù)、。應(yīng)用程序漏洞自定義鏡像務(wù)未授權(quán)訪問(wèn)3.執(zhí)行過(guò)控制臺(tái)登錄實(shí)例執(zhí)行門(mén)文件執(zhí)行用程序執(zhí)行以直接利用這些應(yīng)用程序在云服務(wù)器實(shí)例上執(zhí)行命令程代碼執(zhí)行漏洞執(zhí)行04.04.持久化這種情況在windows實(shí)例中居多。攻擊者可以在服務(wù)器中搜索此類(lèi)遠(yuǎn)程控制軟在userdata中添加后門(mén)a后門(mén)鏡像給現(xiàn)有的用戶(hù)分配額外的API密鑰建立輔助賬號(hào)登錄05.05.權(quán)限提升riteAcl對(duì)象存儲(chǔ)服務(wù)訪問(wèn)控制列表(ACL)是與資源關(guān)聯(lián)的一個(gè)指定被授權(quán)者和授L過(guò)訪問(wèn)管理提權(quán)用程序提權(quán)作系統(tǒng)漏洞進(jìn)行提權(quán)06.06.防御繞過(guò)閉安全監(jiān)控服務(wù) awscloudtraildelete-trail--name[my-trail]通過(guò)配置禁用多區(qū)域日志記錄功能，并在監(jiān)控區(qū)域外進(jìn)行攻擊，以AWS awscloudtrailupdate-trail--name[my-trail]--no-is-multi-regiontrailnoinclude-global-service-events監(jiān)控區(qū)域外進(jìn)行攻擊awscloudtraildescribe-trails式進(jìn)行防御繞過(guò)，并在攻擊流程結(jié)束后再次開(kāi)啟告警日志。以AWSCloudTrail awscloudtrailstop-logging--name[my-trail]awscloudtrailstart-logging--name[my-trail]過(guò)代理訪問(wèn)錄憑據(jù)據(jù)服務(wù)獲取角色臨時(shí)憑據(jù)54/latest/meta-data/54/latest/meta-data/iam/info54/latest/metadata/iam/security-olename應(yīng)用憑證用戶(hù)賬號(hào)數(shù)據(jù)泄露08.08.探測(cè)命令等方法來(lái)搜集基礎(chǔ)設(shè)施的信息。以AWSAPI接口為例，可以使用DescribeInstances接口來(lái)查詢(xún)賬戶(hù)中一個(gè)或多個(gè)實(shí)例的信息，或是使用09.09.橫向移動(dòng)過(guò)控制臺(tái)權(quán)限橫向移動(dòng)10.10.影響用戶(hù)的姓名、證件號(hào)碼、門(mén)密勒索httpscloudsectencen