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