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