2023公有云安全風(fēng)險(xiǎn)分析報(bào)告

綠盟科技集團(tuán)股份有限公司（以下簡稱綠盟星云實(shí)驗(yàn)室專注于云計(jì)算安全相關(guān)的前沿領(lǐng)域研究?；贗aaS環(huán)受到嚴(yán)重影響印度跨國銀行數(shù)百萬數(shù)據(jù)遭遇泄露美國內(nèi)部軍事電子郵件數(shù)據(jù)遭至泄露5導(dǎo)致大規(guī)模數(shù)據(jù)泄露長達(dá)多年2.9丹麥知名云服務(wù)被黑，所有數(shù)據(jù)丟失6云服務(wù)配置錯(cuò)誤的安全風(fēng)險(xiǎn)分析83.1容器鏡像倉庫泄露風(fēng)險(xiǎn)分析云服務(wù)自身的安全風(fēng)險(xiǎn)分析4.2權(quán)限配置錯(cuò)誤風(fēng)險(xiǎn)分析連接云服務(wù)的第三方供應(yīng)鏈安全風(fēng)險(xiǎn)分析12023年，云計(jì)算持續(xù)迅猛發(fā)展，廣泛滲透各行業(yè)，隨著應(yīng)用程序在混合云和多云環(huán)境中的部署增加，面向租戶的云上風(fēng)險(xiǎn)也相應(yīng)提升，如攻擊者可利用互聯(lián)網(wǎng)上泄露的憑證信息訪問租戶資產(chǎn)，并通過一系列攻擊手段對租戶資產(chǎn)的安全性構(gòu)成威脅。再如攻擊者可以利用租戶的云存儲(chǔ)訪問錯(cuò)誤配置，直接獲取云存儲(chǔ)桶內(nèi)的敏感信息，以上風(fēng)險(xiǎn)最終會(huì)造成數(shù)據(jù)泄露事件的發(fā)生。其次，公有云服務(wù)自身也存在漏洞，若云廠商未及時(shí)對漏洞進(jìn)行修復(fù)，攻擊者使得用戶對應(yīng)用運(yùn)營變得更加便捷，但復(fù)雜的軟件供應(yīng)鏈與不必要的服務(wù)暴露也帶來了極大本篇報(bào)告，綠盟科技星云實(shí)驗(yàn)室基于云安全研究方面的積累對未來云安全發(fā)展趨勢進(jìn)行了簡要分析，總結(jié)了2023年的十大云安全事件，圍繞十大事件風(fēng)險(xiǎn)根因，聯(lián)合創(chuàng)新研究院第一章，我們對未來云安全發(fā)展趨勢進(jìn)行了簡要分析，我們認(rèn)為面向租戶的云服務(wù)配置第三章，我們分析了云服務(wù)配置錯(cuò)誤可能導(dǎo)致的嚴(yán)重后果。如容器鏡像、源代碼倉庫、云存儲(chǔ)桶中可能存儲(chǔ)了用戶關(guān)鍵服務(wù)的密鑰信息，也可能存儲(chǔ)用戶的隱私數(shù)據(jù)，這給攻擊者第四章，我們對公有云服務(wù)自身的安全性進(jìn)行了分析，如公有云數(shù)據(jù)庫服務(wù)自身的安全性較容易被忽略，且數(shù)據(jù)庫中存放用戶敏感數(shù)據(jù)，如賬號信息，個(gè)人信息等，因此也成為攻第五章，我們分析了用戶在云上部署的開發(fā)運(yùn)營一體化DevOps服務(wù)的安全性。DevOps流程中，用戶使用大量的第三方服務(wù)或者依賴庫，使用的服務(wù)鏡像，都有可能存在漏洞，更希望通過本報(bào)告，各位讀者能了解、發(fā)現(xiàn)自己云上資產(chǎn)的暴露面和攻擊面，以防范潛在2觀點(diǎn)1：安全左移過程中，自建倉庫的風(fēng)險(xiǎn)應(yīng)重點(diǎn)關(guān)注，研究表明，暴露在互聯(lián)網(wǎng)上的超過10%鏡像倉庫存在鏡像泄露風(fēng)險(xiǎn)，約16%代碼倉庫存在未授權(quán)訪問漏洞，且絕大部分自建倉庫中泄露的鏡像和源代碼存在不同程度的敏感數(shù)據(jù)泄露風(fēng)險(xiǎn)。如被利用，可能會(huì)對數(shù)觀點(diǎn)2：綠盟科技統(tǒng)計(jì)的2023年重大云安全事件中，約四成是因?yàn)槿藶殄e(cuò)誤配置導(dǎo)致的云存儲(chǔ)桶數(shù)據(jù)泄露，這些事件暴露了用戶使用存儲(chǔ)桶服務(wù)時(shí)存在訪問控制配置不當(dāng)和缺乏觀點(diǎn)3：SaaS服務(wù)作為一種靈活的云服務(wù)模型，涵蓋各種服務(wù)類別，不同的服務(wù)面臨不觀點(diǎn)4：IaaS服務(wù)通常提供大規(guī)模的計(jì)算存儲(chǔ)資源，云租戶需要自行搭建服務(wù)，其風(fēng)險(xiǎn)2·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室2022年的網(wǎng)絡(luò)空間測繪年報(bào)[1]中，我們從對象存儲(chǔ)服務(wù)風(fēng)險(xiǎn)、公有云憑證泄露風(fēng)險(xiǎn)、云原生服務(wù)泄露風(fēng)險(xiǎn)、源代碼倉庫暴露風(fēng)險(xiǎn)四個(gè)角度出發(fā)，對云上風(fēng)險(xiǎn)進(jìn)行了梳理分析。2023年，我們通過對不斷曝出的云安全事件的觀察，發(fā)現(xiàn)這些風(fēng)險(xiǎn)依然存在，并呈現(xiàn)以下1.云租戶的錯(cuò)誤導(dǎo)致數(shù)據(jù)泄漏事件依然不斷。隨著云上數(shù)據(jù)泄露事件激增，租戶不恰當(dāng)配置或暴露服務(wù)造成連鎖安全事件的風(fēng)險(xiǎn)突顯，例如2023年5月，豐田汽車公司外包給TC公司的部分?jǐn)?shù)據(jù)因所屬的云存儲(chǔ)桶配置錯(cuò)誤而遭到大規(guī)3.合作伙伴被攻陷的導(dǎo)致供應(yīng)鏈安全風(fēng)險(xiǎn)。連接第三方云服務(wù)導(dǎo)致的供應(yīng)鏈安全風(fēng)險(xiǎn)備受關(guān)注。隨著敏捷開發(fā)趨勢越發(fā)明顯，企業(yè)云應(yīng)用管理越發(fā)遵循開發(fā)運(yùn)營一體化的理念。由于DevOps流程的各個(gè)階段涉及眾多組件，且這些組件被暴露在互聯(lián)網(wǎng)中，因此攻擊者可通過對組件的脆弱性配置或漏洞進(jìn)行利用，竊取重要數(shù)據(jù)并植入惡意腳本，引發(fā)供應(yīng)鏈攻擊。典型事件如2023年5月，勒索軟件團(tuán)伙CL0P利用了MOVEitCloudSQLi零日漏洞發(fā)起供應(yīng)鏈攻擊，受害機(jī)構(gòu)數(shù)量逼近900家，影響人數(shù)超2000萬[5]。這成為繼2020年Solarwinds事件后又的有一起重大供應(yīng)鏈安全事件。隨著云服務(wù)的廣泛應(yīng)用，云安全面臨著日益增大的挑戰(zhàn)。人為錯(cuò)誤配置是主要的風(fēng)險(xiǎn)來源，無論是云租戶還是云服務(wù)商都可能犯錯(cuò)。此外，連接第三方云服務(wù)引發(fā)的供應(yīng)鏈攻擊也備受關(guān)注。我們只有深入了解這些云上風(fēng)險(xiǎn)的根本原因，才能更有效地加強(qiáng)云安全防護(hù)，使4·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室2.1簡介本章我們總結(jié)了2023年十大云安全事件并進(jìn)行簡單介紹，后續(xù)第三章至第五章我們將圍繞2.2微軟AzureActiveDirectory配置錯(cuò)誤導(dǎo)致Bing服務(wù)受到2023年1月，Wiz發(fā)現(xiàn)了AzureActiveDirectory（AAD）中的一個(gè)新攻擊向量，影響Microsoft的Bing服務(wù)。該攻擊向量基于常見的AAD配置錯(cuò)誤，使得配置錯(cuò)誤的應(yīng)用程序允研究人員發(fā)現(xiàn)了多個(gè)微軟應(yīng)用程序容易受到這種攻擊的影響，包含Mag新聞、CNSAPI、PowerAutomate博客等應(yīng)用程序，其中一個(gè)是用于驅(qū)動(dòng)Bing服務(wù)的內(nèi)容管理系統(tǒng)（CMS）。該漏洞能夠?qū)е鹿粽呓庸茉揃ing服務(wù)，修改搜索結(jié)果，并有可能導(dǎo)致數(shù)百萬Bing用戶的Wiz將這次攻擊命名為“#BingBang”。該漏洞利用方式十分簡單，甚至無需編寫任何代2.3全球范圍VMwareESXi服務(wù)器遭至勒索軟件攻擊2023年2月3日左右，法國計(jì)算機(jī)緊急響應(yīng)小組(CERT-FR)發(fā)出警告，有攻擊者正通過利用一個(gè)在2021年3月就發(fā)現(xiàn)的VMwarevCenterServer遠(yuǎn)程代碼執(zhí)行漏洞（CVE-2021-21974對全球多地未打補(bǔ)丁的VMwareESXi部署新型ESXiArgs勒索軟件。ESXiArgs勒索軟件會(huì)對ESXi服務(wù)器上的配置文件進(jìn)據(jù)悉，意大利、法國、芬蘭、美國、加拿大等國均遭到攻擊。根據(jù)安全大數(shù)據(jù)公司Censys檢索披露[7]，歐洲和北美已經(jīng)有千臺服務(wù)器遭到破壞。奧地利計(jì)算機(jī)安全應(yīng)急響應(yīng)小組也發(fā)出警告，稱“至少有3762個(gè)系統(tǒng)”受到了影響。意大利電信公司也因?yàn)樵摾账鞴舫霈F(xiàn)大規(guī)?；ヂ?lián)網(wǎng)中斷。開源勒索軟件支付跟蹤器Ransomwhere跟蹤了四筆總價(jià)值52023年重大云安全事件回顧88,000美元的贖金。2.4DigitalOcean存儲(chǔ)桶被公開訪問，印度跨國銀行數(shù)百萬并在全球至少15個(gè)國家設(shè)有分支機(jī)構(gòu)。印度政府將ICICI銀行的資產(chǎn)命名為“關(guān)鍵信息基礎(chǔ)設(shè)施”，對其的任何傷害均會(huì)影響國家安全，然而其關(guān)鍵數(shù)據(jù)安全性卻依然得不到保障[8]。2023年2月，Cybernews研究團(tuán)隊(duì)發(fā)現(xiàn)ICICI銀行因其系統(tǒng)使用了DigitalOcean務(wù)，但并未正確配置存儲(chǔ)桶的訪問控制權(quán)限，導(dǎo)致銀行泄露了360萬個(gè)敏感文件，其中包含銀行對賬單、現(xiàn)任員工和求職者簡歷等重要信息，Cybernews研究團(tuán)隊(duì)立即聯(lián)系了ICICI銀行和印度計(jì)算機(jī)應(yīng)急相應(yīng)小組（CERT-INICICI第一時(shí)間通過修改訪問權(quán)限限制了存儲(chǔ)桶更詳細(xì)的分析請參見研究案例7：DigitalOcean存儲(chǔ)桶公開可訪問，印度跨國銀行數(shù)2.5約3TB托管至Azure上的美國內(nèi)部軍事電子郵件數(shù)據(jù)遭2023年2月21日，美國在線新聞網(wǎng)站TechCrunch報(bào)道稱，美國國防部的一個(gè)服務(wù)器泄露了約3TB美國軍方內(nèi)部電子郵件數(shù)據(jù)[9]。該服務(wù)器托管在微軟為國防部提供的Azure政務(wù)云上，理論上該政務(wù)云與其他網(wǎng)絡(luò)是物理隔離的，很可能是由于錯(cuò)誤配置導(dǎo)致郵件服務(wù)2023年2月8日，這個(gè)郵件服務(wù)器被Shodan掃描發(fā)現(xiàn)。安全研究員AnuragSen發(fā)現(xiàn)服務(wù)器泄露了大量敏感信息，并向TechCrunch提供了泄露線索。該服務(wù)器存儲(chǔ)了包括內(nèi)部2.6阿里云數(shù)據(jù)庫服務(wù)被曝嚴(yán)重漏洞“BrokenSesame”2023年4月，Wiz研究團(tuán)隊(duì)在官方博客[43]中披露了一系列被命名為“BrokenSesame”的阿里云數(shù)據(jù)庫服務(wù)漏洞。該漏洞會(huì)導(dǎo)致未授權(quán)訪問阿里云租戶的PostgreSQL數(shù)據(jù)庫，并6·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室研究人員深入研究了阿里云的兩個(gè)主流云服務(wù)：ApsaraDBRDSforPostgreSQL和AnalyticDBforPostgreSQL，其中，ApsaraD備份和災(zāi)難恢復(fù)功能，AnalyticDBforPostgreSQL是一個(gè)托管數(shù)據(jù)倉庫服務(wù)。研究人員發(fā)現(xiàn)研究人員旨在識別攻擊者如何繞過云服務(wù)商設(shè)置的安全邊界，并獲取對其他用戶數(shù)據(jù)的更詳細(xì)的分析請參見研究案例9:阿里云數(shù)據(jù)庫服務(wù)被曝嚴(yán)重漏洞“BrokenSesame”2.7勒索軟件團(tuán)伙CL0P利用了MOVEitCloudSQLi零日漏洞：受害機(jī)構(gòu)數(shù)量逼近900家，影響人數(shù)超2000萬MOVEittransfer和MOVEitCloud是ProgressSoftware公司生產(chǎn)的托管文件傳輸產(chǎn)品，可對文件進(jìn)行加密，采用FTP或SFTP等文件傳輸協(xié)議來傳輸數(shù)據(jù)，提供自動(dòng)化服務(wù)、分析和故障轉(zhuǎn)移功能，在全球醫(yī)療保健行業(yè)得到大規(guī)模應(yīng)用。2023年5月27日，俄羅斯勒索軟件組織CL0P在陣亡將士紀(jì)念日[11]當(dāng)天通過利用MOVEittransfer和MOVEitCloud中的零日漏洞（后被披露為CVE-2023-34362漏洞）對全球各大企業(yè)發(fā)起大規(guī)模軟件供應(yīng)鏈攻擊。許多知名企業(yè)也受到影響，如殼牌公司、德意志銀行、普華永道、索尼、西門子、BBC、英國航空公司、美國能源部和農(nóng)業(yè)部等。這次大規(guī)模攻擊已危及全球超過900家私營和公共部2.8ToyotaConnected云配置錯(cuò)誤導(dǎo)致大規(guī)模數(shù)據(jù)泄露長達(dá)2023年5月12日，ToyotaConnectedCorporation（以下簡稱TC）宣布，豐田汽車公司外包給TC公司的部分?jǐn)?shù)據(jù)因云環(huán)境設(shè)置不正確而遭到泄露。此次數(shù)據(jù)泄露事件影響約輛的位置信息、車輛在上述位置的時(shí)間以及車載終端ID和車輛識別號VIN，甚至包含2016年11月14日至2023年4月2.9丹麥知名云服務(wù)被黑，所有數(shù)據(jù)丟失72023年重大云安全事件回顧犯罪者曾將贖金定為6個(gè)比特幣，價(jià)值157,000美元，但CloudNordic/AzeroCloud決定不支付[46]。最終這次入侵導(dǎo)致CloudNordic/AzeroCloud完全癱瘓，所有用戶的數(shù)據(jù)丟失，包括2.10微軟研究團(tuán)隊(duì)使用的AzureBlob存儲(chǔ)桶意外暴露38TB2023年9月，Wiz安全團(tuán)隊(duì)公布一起關(guān)于MicrosoftAI研究團(tuán)隊(duì)的數(shù)據(jù)泄露事件，泄露數(shù)據(jù)總量達(dá)38TB，泄露數(shù)據(jù)包括Microsoft服務(wù)的密碼、密鑰以及Microsoft員工的30,000多條內(nèi)部MicrosoftTeams消息[15]。這起數(shù)據(jù)泄露事件的起因是MicrosoftAI研究團(tuán)隊(duì)在Github中開源的一個(gè)人工智能模型――robust-models-transfer。該模型被存儲(chǔ)在AzureBlob中，MicrosoftAI研究團(tuán)隊(duì)同時(shí)據(jù)悉，該Azure賬戶SAS令牌于2020年7月已被公開至Github中，并在2021年10月將該令牌的有效期延長至2051年10月。當(dāng)前，MicrosoftAI團(tuán)隊(duì)已在2023年8月替換的亞馬遜S3(SimpleStorageService)存儲(chǔ)桶由于錯(cuò)誤配置泄露了16,000多份包含員工護(hù)照、2.12小結(jié)從上述事件不難看出，云服務(wù)配置錯(cuò)誤、云服務(wù)自身漏洞、不安全的供應(yīng)鏈?zhǔn)菍?dǎo)致這些事件的主要原因。其中，由于存儲(chǔ)桶配置錯(cuò)誤導(dǎo)致的數(shù)據(jù)泄露事件高達(dá)四起，云服務(wù)自身漏本報(bào)告的后續(xù)章節(jié)將圍繞這十大典型云安全事件的風(fēng)險(xiǎn)根因展開，通過案例分析和實(shí)際析9●觀點(diǎn)1：安全左移過程中，自建倉庫的風(fēng)險(xiǎn)應(yīng)重點(diǎn)關(guān)注，研究表明，暴露在互聯(lián)網(wǎng)上的超過10%鏡像倉庫存在鏡像泄露風(fēng)險(xiǎn)，約16%代碼倉庫存在未授權(quán)訪問漏洞，且絕大部分自建倉庫中泄露的鏡像和源代碼存在不●觀點(diǎn)2：綠盟科技統(tǒng)計(jì)的2023年重大云安全事件中，約四成是因?yàn)槿藶殄e(cuò)誤配置導(dǎo)3.1容器鏡像倉庫泄露風(fēng)險(xiǎn)分析截止2023年11月，我們對全球暴露的16661個(gè)主流自建鏡像倉庫進(jìn)行了研究分析（Harbor數(shù)據(jù)占9042條，DockerRegistry數(shù)據(jù)占7619條超過10%的鏡像倉庫由于錯(cuò)誤配置（DockerRegistry倉庫占比約66%，Harbor倉庫占比34%其由此泄露的鏡像高達(dá)31000個(gè)。我們對31000個(gè)泄露的自建倉庫鏡像進(jìn)行了研究分析，97%的鏡像存在不同程度的敏感通信等各個(gè)行業(yè)，6%為口令信息，這些口令涉及數(shù)據(jù)庫、管理系統(tǒng)、自建倉庫等各種關(guān)鍵自建鏡像倉庫泄露通常始于倉庫服務(wù)在互聯(lián)網(wǎng)上的暴露，如圖3.1所示，攻擊者會(huì)發(fā)現(xiàn)暴露在互聯(lián)網(wǎng)中的倉庫，并通過漏洞或錯(cuò)誤配置進(jìn)行利用以從倉庫中竊取鏡像，隨后做敏感品1.倉庫掃描2 133.敏感提取·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室品1.倉庫掃描2 133.敏感提取2.鏡像竊取2.鏡像竊取4.攻擊利用圖3.1容器自建鏡像倉庫常見攻擊路徑我們發(fā)現(xiàn)在自建容器鏡像倉庫中，配置錯(cuò)誤是導(dǎo)致容器鏡像泄露的主要原因之一，如Harbor的項(xiàng)目訪問權(quán)限[17]、DockerRegistry的認(rèn)證機(jī)制[18]等，這些配置項(xiàng)若被錯(cuò)誤設(shè)置提及Harbor倉庫時(shí)，不得不提CVE-2022-46463，這個(gè)“漏洞”被誤認(rèn)為是未授權(quán)訪問漏洞，但不久前Harbor官方回復(fù)這個(gè)“漏洞”實(shí)際上是一個(gè)功能特性，而非真實(shí)漏洞。該特性可能會(huì)導(dǎo)致設(shè)置為“公開”的項(xiàng)目中的鏡像被未授權(quán)訪問和拉取。如圖3.2所示，盡管圖3.2Harbor公開項(xiàng)目特性設(shè)置默認(rèn)情況下，由于DockerRegistry的認(rèn)證機(jī)制不會(huì)開啟，因而攻擊者可以直接調(diào)用官方提供的API接口獲取鏡像倉庫的項(xiàng)目列表和版本信息，進(jìn)而可獲取鏡像的詳細(xì)信息，最終竊接下來，我們將分享若干鏡像倉庫泄露案例，本報(bào)告中所有研究工作均在政府主管部門（注：下述研究案例1-12包括綠盟科技星云實(shí)驗(yàn)室研究的某軟件服務(wù)公司的Harbor鏡像倉庫暴露在互聯(lián)網(wǎng)中，并且該鏡像倉庫由于配置錯(cuò)誤，可泄露的鏡像中包含大量的業(yè)務(wù)源代碼，經(jīng)敏感識別分析，我們發(fā)現(xiàn)其中一個(gè)鏡像泄露了圖3.3某軟件服務(wù)公司泄露的鏡像倉庫某醫(yī)藥O2O運(yùn)營管理公司的自建鏡像倉庫由于配·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室值得關(guān)注的是，鏡像中的配置文件泄露了該公司運(yùn)營管理平臺的登錄口令，由于該運(yùn)營平臺直接暴露在互聯(lián)網(wǎng)中，因而可被任意進(jìn)行訪問。如3.5所示，該賬號泄露了全國超過10如果不法分子獲取了這些敏感信息，他們可以輕松地利用醫(yī)藥消費(fèi)數(shù)據(jù)對消費(fèi)者或藥店某校園安全軟件服務(wù)公司的自建容器鏡像倉庫泄露多所高校業(yè)務(wù)系統(tǒng)的源碼，其中多個(gè)疑似管理節(jié)點(diǎn)的接入賬號口令、視頻監(jiān)控系統(tǒng)登錄賬號密碼和疑似校園安全事件管理數(shù)據(jù)庫如圖3.6所示，鏡像中的配置文件泄露了疑似校園安全事件管理數(shù)據(jù)庫的登錄信息，該·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室圖3.6某鏡像泄露的數(shù)據(jù)庫信息通過進(jìn)一步研究，我們發(fā)現(xiàn)該組織在關(guān)聯(lián)鏡像中還疑似泄露了如圖3.7所示的視頻監(jiān)控圖3.7某高校業(yè)務(wù)鏡像疑似泄露視頻監(jiān)控管理系統(tǒng)賬號信息3.2源代碼倉庫泄露風(fēng)險(xiǎn)分析如Gitblit、Gogs、Gitea、Gitlab等主流自建代碼倉庫因?yàn)椴渴鸨憬?、使用方便等?yōu)勢，在許多環(huán)境中得到廣泛應(yīng)用。然而，我們發(fā)現(xiàn)許多組織對所采用的代碼托管軟件的特性了解并不充分。大量的自建代碼倉庫由于配置錯(cuò)誤存在未授權(quán)訪問的風(fēng)險(xiǎn)，這是攻擊者獲取自建我們對全球暴露的80578個(gè)主流自建代碼倉庫進(jìn)行了研究分析（GitblGogs數(shù)據(jù)占13938條，Gitea數(shù)據(jù)占24318條，Gitlab數(shù)據(jù)占38208條約16%的代碼倉庫存在未授權(quán)訪問風(fēng)險(xiǎn)（Gitblit數(shù)據(jù)占40%，Gogs數(shù)據(jù)占20%，Gitea數(shù)據(jù)占16%，Gitlab數(shù)據(jù)占11%超過150000個(gè)源代碼可被直接拉取。借助敏感識別技術(shù)，我們對這些泄露的源代碼項(xiàng)目進(jìn)行了研究分析，54%的源代碼項(xiàng)目存在不同程度的敏感信息泄露。泄露的敏感信息中，91%為業(yè)務(wù)源代碼，這些源碼涉及到政府、醫(yī)療、教育、金融、通信等各個(gè)行業(yè)；7%為身份證、銀行號、手機(jī)號等其他敏感數(shù)據(jù)；2%為關(guān)鍵口令信息，這些口令涉盡管在過去多幾年里我們一直致力于向大眾提醒“大部分軟件的默認(rèn)配置是不安全的研究案例4：某文旅軟件服務(wù)商自建代碼倉庫泄露某組織的Gitea代碼倉庫長期暴露在互聯(lián)網(wǎng)中，并且由于配置錯(cuò)誤，無需認(rèn)證便可以從互聯(lián)網(wǎng)上獲取該倉庫的所有項(xiàng)目數(shù)據(jù)。如圖3.8所示，我們從其中的一個(gè)“公司年會(huì)抽獎(jiǎng)”項(xiàng)目配置文件中發(fā)現(xiàn)了疑似組織名稱，結(jié)合實(shí)體分析技術(shù)，我們最終確認(rèn)該代碼倉庫為某文·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室圖3.8某文旅軟件服務(wù)商年會(huì)抽獎(jiǎng)項(xiàng)目配置該倉庫泄露的項(xiàng)目多達(dá)26個(gè)，這些項(xiàng)目幾乎涵蓋了其官網(wǎng)介紹中的選取了某市的一個(gè)文旅項(xiàng)目進(jìn)行敏感分析，除大量業(yè)務(wù)代碼外，源碼中存在大量的關(guān)鍵口令信息，如圖3.9所示，其中的幾塊代碼段泄露了互聯(lián)網(wǎng)服務(wù)器和互聯(lián)網(wǎng)數(shù)據(jù)庫的地址和賬號圖3.9某文旅項(xiàng)目泄露的關(guān)鍵賬號口令信息研究案例5：某大數(shù)據(jù)解決方案服務(wù)商自建代碼倉庫泄露大量業(yè)務(wù)源碼和疑似城市統(tǒng)計(jì)我們測繪到，某大數(shù)據(jù)解決方案服務(wù)商自建代碼倉庫暴露在互聯(lián)網(wǎng)中，如圖3.10所由于配置錯(cuò)誤，所有人無需認(rèn)證便可以直接獲取所有項(xiàng)目信息和源代碼。值得關(guān)注的是，該圖3.10某大數(shù)據(jù)解決方案服務(wù)商自建代碼倉庫泄露該倉庫泄露了前端、后端、APP、數(shù)據(jù)處理等9個(gè)項(xiàng)目的源代碼，我們選取了部分項(xiàng)目進(jìn)行源代碼敏感分析，幾乎每個(gè)項(xiàng)目均泄露了不同程度的敏感數(shù)據(jù)。如圖3.11所示，我配置文件中發(fā)現(xiàn)了某業(yè)務(wù)系統(tǒng)的后臺數(shù)據(jù)庫賬號口令信息。該信息二次泄露了大量的疑似城·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室圖3.11某大數(shù)據(jù)解決方案服務(wù)商數(shù)據(jù)庫信息泄露研究案例6：某大數(shù)據(jù)集團(tuán)下屬科技公司自建代碼倉庫泄露某省國資委、城投、水務(wù)等我們發(fā)現(xiàn)某科技公司自建代碼倉庫暴露在互聯(lián)網(wǎng)中，該公司屬于某省大數(shù)據(jù)集團(tuán)下屬企該倉庫直接泄露了11個(gè)項(xiàng)目的源代碼，這些項(xiàng)目涉及某省國資委、城投、水務(wù)等多個(gè)組織。我們對其中的部分項(xiàng)目進(jìn)行了敏感識別分析，大部分的項(xiàng)目均泄露了不同程度的敏感數(shù)據(jù)。如圖3.12所示，項(xiàng)目中的一個(gè)配置文件中泄露了其互聯(lián)網(wǎng)數(shù)據(jù)庫的賬號口令圖3.12某大數(shù)據(jù)集團(tuán)下屬科技公司數(shù)據(jù)庫泄露3.3存儲(chǔ)桶泄露風(fēng)險(xiǎn)分析由于人為錯(cuò)誤配置，存儲(chǔ)桶數(shù)據(jù)往往可以被公開訪問，這意味著只要在瀏覽器中輸入了正確的域名，世界上任何人都可以訪問這些數(shù)據(jù)。這種情況下，存儲(chǔ)桶的數(shù)據(jù)可能會(huì)被惡意金融數(shù)據(jù)、商業(yè)機(jī)密等。這些數(shù)據(jù)泄露不僅會(huì)損害個(gè)人隱私和商業(yè)利益，還可能導(dǎo)致法律訴泄露直接相關(guān)的，這表明云存儲(chǔ)桶的安全性在當(dāng)前云計(jì)算環(huán)境中仍然面臨著嚴(yán)重的風(fēng)險(xiǎn)和挑戰(zhàn)。在下文，我們將對這些具有共性的重大安全事件進(jìn)行詳細(xì)的研究分析，以深入探討事件的背景、原因、影響以及可能的應(yīng)對措施。通過對這些事件的深入分析，我們希望能夠從中汲取經(jīng)驗(yàn)教訓(xùn)，加強(qiáng)對云安全的認(rèn)識，提高對云存儲(chǔ)桶數(shù)據(jù)泄露等安全威脅的應(yīng)對能力，以如前文提到，泄露的敏感文件中包含銀行用戶的詳細(xì)信息、信用卡號、姓名、護(hù)照、出20·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室如圖3.13-3.16所示。圖3.13云存儲(chǔ)中泄露文件總數(shù)的屏幕截圖圖3.14護(hù)照泄露截圖21圖3.15銀行對賬單泄露截圖22·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室除此之外，CloudSEK聯(lián)合創(chuàng)始人兼首席執(zhí)行官RahulSasi還表示[21]，泄露的存儲(chǔ)桶還Spaces是DigitalOcean提供的對象存儲(chǔ)服務(wù)，從其官方API文檔[22]可以看出，Spaces對象存儲(chǔ)與AmazonS3對象存儲(chǔ)服務(wù)兼容，用戶可通過設(shè)置ACL策略以完成對存儲(chǔ)23<AccessControlPolicyxmlns="/doc/2006-03-01/"><DisplayName>xxxx</DisplayName><AccessControlList><Granteexmlns:xsi="/2001/XMLSchema-instance"xsi:type="Group"><URI>/groups/global/AllUsers</URI></Grantee><Permission>READ</Permission><Granteexmlns:xsi="/2001/XMLSchema-instance"xsi:type="CanonicalUser"></Grantee><Permission>FULL_CONTROL</Permission></AccessControlList></AccessControlPolicy>從上述示例xml文件中的<Permission>標(biāo)簽值(FULL_CONTROL)可以看出，該策略賦予了存儲(chǔ)桶的公開訪問權(quán)限。ICICI銀行及被發(fā)現(xiàn)暴露在可公開訪問的DigitalOcean存儲(chǔ)桶中，“公開訪問”也就意味著任何人，無論是否擁有DigitalOcean賬號，只要知道文件的URL，就可以訪問和下載行內(nèi)部流程的細(xì)節(jié)，并危及其用戶和員工及其數(shù)據(jù)的安全?！比缇W(wǎng)絡(luò)犯罪分子可以使用被盜取的憑據(jù)和個(gè)人數(shù)據(jù)在用戶不知情的情況下以個(gè)人的名義開設(shè)賬戶，進(jìn)行轉(zhuǎn)賬和實(shí)施信用卡24·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室2.為用戶提供識別和避免電子郵件、網(wǎng)站、電話的欺詐行為的指導(dǎo)，并時(shí)刻敦促用戶向3.若受到隱私泄露情況，應(yīng)及時(shí)更改登錄密鑰，設(shè)置強(qiáng)密碼，避免弱密碼被暴破的風(fēng)險(xiǎn)AzureBlob存儲(chǔ)桶是由Microsoft提供的云對象存儲(chǔ)解決方案，適用于存儲(chǔ)大量的非結(jié)構(gòu)包括Blob、文件、隊(duì)列和表，同時(shí)為Azure存儲(chǔ)數(shù)據(jù)提供了一個(gè)唯一的命名空間[23]。共享訪問簽名(SAS)令牌是一種簽名URL，是一種臨時(shí)訪問憑證，是Azure提供的一種對存儲(chǔ)賬戶中資源進(jìn)行安全委托訪問的方式。使用SAS可以精細(xì)控制用戶端訪問Azure對象1.客戶端可以訪問哪些資源（Blob容器、表、隊(duì)列或2.SAS的有效期限。Azure存儲(chǔ)支持三種類型的共享訪問簽名SAS：用戶委托SAS、服務(wù)SAS和賬戶SAS。用戶可以通過創(chuàng)建賬戶SAS令牌進(jìn)行Blob存儲(chǔ)數(shù)據(jù)共享，并且能夠設(shè)置該令牌的訪問權(quán)限和有效時(shí)間。在有效時(shí)間內(nèi)，任何人都可以通過賬戶SAS令牌的URL按照訪問權(quán)限訪問相在此次事件中，MicrosoftAI研究團(tuán)隊(duì)采用了AzureBlob存儲(chǔ)和賬戶SAS令牌作為模型研究團(tuán)隊(duì)在生成賬戶SAS令牌時(shí)設(shè)置了不安全的訪問權(quán)限，即該令牌具有整個(gè)存儲(chǔ)賬戶的訪問權(quán)限，如圖3.17所示[15]，導(dǎo)致用戶不僅可以通過該SAS令牌訪問模型，甚至可以訪問存儲(chǔ)賬戶中的額外數(shù)據(jù)，其中包含了38TB的私人文件。除了權(quán)限設(shè)置過于寬松外，該令牌還被配置為Blob存儲(chǔ)桶的“完全控制”權(quán)限，這意味著惡意用戶可以修改、刪除現(xiàn)有的25圖3.17SAS令牌權(quán)限配置錯(cuò)誤導(dǎo)致此次事件的主要原因是SAS令牌權(quán)限配置錯(cuò)誤，歸根到底還是臨時(shí)憑證的權(quán)限安全1.應(yīng)做到對云賬戶下所有臨時(shí)憑證的可見與監(jiān)控，避免“影子”憑證對賬戶、資源造成嚴(yán)重危害，如臨時(shí)憑證的使用途徑與其具備的權(quán)限應(yīng)嚴(yán)格匹配，應(yīng)避免對臨時(shí)憑證進(jìn)行過度授權(quán)。再如臨時(shí)憑證的過期時(shí)間應(yīng)嚴(yán)格控制，應(yīng)做到定期更換以避免較長時(shí)間2.應(yīng)避免使用臨時(shí)憑證作為數(shù)據(jù)共享的“鑰匙”；4.應(yīng)使用諸如云安全態(tài)勢管理（CloudSecurityPostureManagement，CSPM）等工具3.4小結(jié)本章深入探討了云服務(wù)配置錯(cuò)誤導(dǎo)致的安全風(fēng)險(xiǎn)，特別是自建容器鏡像倉庫、自建代碼倉庫和存儲(chǔ)桶泄露風(fēng)險(xiǎn)。通過具體的研究案例分析，我們發(fā)現(xiàn)由于配置錯(cuò)誤或?qū)υ品?wù)安全26·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室性認(rèn)識不足等原因，大規(guī)模的敏感數(shù)據(jù)仍然被持續(xù)泄露。這些泄露的個(gè)人隱私信息、商業(yè)機(jī)●●定期對云服務(wù)進(jìn)行安全審計(jì)和配置核查，及時(shí)發(fā)現(xiàn)并修復(fù)潛在的安全漏洞和錯(cuò)誤●訂閱專業(yè)的EASM服務(wù)，監(jiān)控和保護(hù)暴露資產(chǎn)；通過采取上述措施，可以有效降低云服務(wù)配置錯(cuò)誤導(dǎo)致的安全風(fēng)險(xiǎn)，確保敏感數(shù)據(jù)免受28·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室●觀點(diǎn)3：SaaS服務(wù)作為一種靈活的云服務(wù)模型，涵蓋各種服務(wù)類別，不同的服務(wù)面企業(yè)可以通過租用公有云資源來存儲(chǔ)和處理數(shù)據(jù)，與私有云相比，公有云的安全問題更1.公有云中的數(shù)據(jù)可能會(huì)面臨更多的泄露風(fēng)險(xiǎn)。相較于原有的IT基礎(chǔ)設(shè)施，部署在公有2.公有云環(huán)境面臨跨租戶劫持的風(fēng)險(xiǎn)。由于公有云面向多租戶的特性，企業(yè)租賃云服務(wù)就會(huì)面臨多租戶共享同一云基礎(chǔ)設(shè)施的場景，進(jìn)而會(huì)導(dǎo)致跨租戶劫持風(fēng)險(xiǎn)，如攻擊者可以利用漏洞從一個(gè)云租戶入手，得手后再攻擊其他租戶，進(jìn)而影響到其它租戶的業(yè)3.數(shù)據(jù)所有權(quán)和廠商鎖定風(fēng)險(xiǎn)：公有云服務(wù)模型中，租戶數(shù)據(jù)存儲(chǔ)在云服務(wù)商的服務(wù)器上，租戶需要明確了解他們在合同中對數(shù)據(jù)的所有權(quán)，并且在云服務(wù)商終止服務(wù)時(shí)，需要知曉如何獲取數(shù)據(jù)的權(quán)限，以此避免由于數(shù)據(jù)無法遷移或鎖定而導(dǎo)致的依賴性問近年來伴隨云計(jì)算的興起，針對公有云的攻擊事件層出不窮，本章我們將通過對當(dāng)下安4.1跨租戶劫持風(fēng)險(xiǎn)分析由于SaaS服務(wù)天然為多租戶環(huán)境，因此跨租戶劫持成為用戶常面臨的一大風(fēng)險(xiǎn)，跨租戶劫持風(fēng)險(xiǎn)通常指的是在多租戶環(huán)境中存在的安全威脅，其中一個(gè)租戶可能試圖獲取或篡改另一個(gè)租戶的數(shù)據(jù)或資源。租戶是指在同一云服務(wù)或系統(tǒng)中獨(dú)立運(yùn)行的不同組織、用戶或應(yīng)29研究案例9:阿里云數(shù)據(jù)庫服務(wù)被曝嚴(yán)重漏洞“BrokenSesame”1.AnalyticDBforPostgreSQL容器逃逸漏洞從一個(gè)Postgres的普通用戶開始，第一步研究人員可通過定時(shí)任務(wù)提權(quán)到數(shù)據(jù)庫容器的root權(quán)限。容器內(nèi)有一個(gè)每分鐘執(zhí)行/usr/bin/tsar的定時(shí)任務(wù)。圖4.1定時(shí)任務(wù)通過對該二進(jìn)制文件執(zhí)行l(wèi)dd命令，可以看到它會(huì)從自定義的位置/u01加載共享庫。而當(dāng)前用戶adbpgadmin對/u01目錄具有寫權(quán)限。研究人員可以通過對此共享庫文件的覆蓋，來讓下次定時(shí)圖4.2鏈接庫鏈接狀態(tài)30·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室研究人員拿到數(shù)據(jù)庫容器Root權(quán)限后，可通過阿里云站點(diǎn)開啟SSL加密功能，這一步由于存在權(quán)限配置問題，研究人員控制宿主機(jī)（KubernetesNode）后可以通過對注冊表2.ApsaraDBRDSforPostgreSQL命令注入漏洞壞。針對此功能，研究人員發(fā)現(xiàn)其存在命令注入漏洞，可以在負(fù)責(zé)此功能的容器中執(zhí)行任意研究人員發(fā)現(xiàn)在控制宿主機(jī)（KubernetesNode）后，此服務(wù)的私有容器注冊表存儲(chǔ)庫和用于AnalyticDB的相同，可以使用AnalyticDB的憑證完成對ApsaraDBRDS的供應(yīng)鏈攻擊。當(dāng)設(shè)計(jì)具有多個(gè)容器的服務(wù)時(shí)，確切地定義他們?nèi)绾螀f(xié)同工作是至關(guān)重要的。研究人員在ApsaraDB和AnalyticDB這兩項(xiàng)服務(wù)中，數(shù)據(jù)庫容器與KubernetesPod中的其他業(yè)務(wù)容器共享不同的Linux命名空間。由于共享PID命名空間，使得容器能夠建議：利用容器隔離技術(shù)確保容器之間相互獨(dú)立運(yùn)行，避免了應(yīng)用程序或服務(wù)之間的沖在ApsaraDBRDS的案例研究中，我們發(fā)現(xiàn)由于Kubernetes節(jié)點(diǎn)托管多個(gè)用戶數(shù)據(jù)庫的31建議：在Pod中使用最小特權(quán)的容器，避免賦予容器過多的權(quán)限。使用SecurityContext[25]配置來限制容器的權(quán)限，例如限制特權(quán)模式、能力和掛載的文件系統(tǒng)等；采用gVisor3）Kubernetes權(quán)限配置過高在ApsaraDB和AnalyticDB這兩項(xiàng)服務(wù)中，由于Kubernetes集群是多租戶的，如果Kubernetes服務(wù)賬號（ServiceAccount）權(quán)限過高，則可以訪問其他租戶的資源。建議：使用最小權(quán)限原則，如使用基于角色的訪問控制（Role-basedaccesscontrol，4.2權(quán)限配置錯(cuò)誤風(fēng)險(xiǎn)分析權(quán)限配置問題通常是因?yàn)橘x予了云租戶過大的權(quán)限造成的，使得惡意用戶可以超越當(dāng)前限制，獲取到高危權(quán)限，并利用SaaS服務(wù)的產(chǎn)品特性對宿主機(jī)產(chǎn)生影響。該問題主要體現(xiàn)在云服務(wù)廠商對用戶的權(quán)限限制不當(dāng)和對SaaS服務(wù)的產(chǎn)品特性限制不當(dāng)?shù)萚26]。為了讓讀者對權(quán)限配置錯(cuò)誤導(dǎo)致的風(fēng)險(xiǎn)有更清晰的理解，下面我們將通過三個(gè)具體案例Microsoft在Azure中提供了自己的單點(diǎn)登錄（SSO）服務(wù)，即AAD（AzureActiveDirectory它是在AzureAppServices或AzureFunctions中創(chuàng)建的應(yīng)用程序中最常見的身單租戶應(yīng)用程序只允許來自相同租戶的用戶為該應(yīng)用程序發(fā)放OAuth令牌。另一方面，多租戶應(yīng)用程序允許任何Azure租戶為它們發(fā)放OAuth令牌。因此，應(yīng)用程研究人員掃描了AzureAppServices和AzureFunctions以查找暴露的端點(diǎn)，并在其中發(fā)現(xiàn)了一個(gè)典型的“責(zé)任共擔(dān)”[47]混淆案例。如圖4.3所示，為Azure的一個(gè)APPFunctions有者來說，這是一個(gè)理所當(dāng)然的過程。然而，該服務(wù)僅確保了令牌的有效性。對于應(yīng)用程序1https://gvisor.dev/docs/2https://katacontainers.io/docs/32·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室對于單租戶身份驗(yàn)證，影響僅限于應(yīng)用程序的租戶-來自相同租戶的所有用戶都可以連但對于多租戶應(yīng)用程序，暴露的范圍就廣泛得多-沒有進(jìn)行適當(dāng)?shù)尿?yàn)證，任何Azure用研究人員掃描的所有多租戶應(yīng)用程序中，有25%存在認(rèn)證繞過漏洞。以“Bing問答”應(yīng)錯(cuò)誤的權(quán)限定義導(dǎo)致非超級用戶獲取了schemapg_catalog下創(chuàng)建函數(shù)的權(quán)限（在PostgreSQL數(shù)據(jù)庫中，pg_catalog是一個(gè)系統(tǒng)模式（systemschema），用于存儲(chǔ)有關(guān)數(shù)據(jù)庫內(nèi)部結(jié)構(gòu)和元數(shù)據(jù)的信息）。在創(chuàng)建PostgreSQL插件時(shí)，執(zhí)行插件的SQL的用戶角色會(huì)獲得超級用戶權(quán)限。通過利用函數(shù)調(diào)用的優(yōu)先級特性，攻擊者執(zhí)行自定義的函數(shù)，嵌入提權(quán)33數(shù)據(jù)庫查看數(shù)據(jù)庫可用擴(kuò)展3▲構(gòu)造提權(quán)邏輯并創(chuàng)建pg_catalog下特定函數(shù)數(shù)據(jù)庫查看數(shù)據(jù)庫可用擴(kuò)展3▲構(gòu)造提權(quán)邏輯并創(chuàng)建pg_catalog下特定函數(shù)1.我們在申請到數(shù)據(jù)庫服務(wù)后，發(fā)現(xiàn)初始用戶在系統(tǒng)schemapg_catalog下具備創(chuàng)建函2.我們調(diào)研了數(shù)據(jù)庫擴(kuò)展支持情況，發(fā)現(xiàn)部分?jǐn)U展存在使用pg_catalog模式下系統(tǒng)函數(shù)3.我們隨后利用PostgreSQL函數(shù)優(yōu)先級設(shè)定，構(gòu)造特定系統(tǒng)函數(shù)并嵌入提權(quán)邏輯，在惡意用戶1155讀取用戶權(quán)限22用戶權(quán)限表擴(kuò)展查看原始sql確定待嵌入函數(shù)數(shù)據(jù)庫擴(kuò)展創(chuàng)建7創(chuàng)超級用戶權(quán)限錯(cuò)誤的權(quán)限定義允許非超級用戶在schemapg_catalog下創(chuàng)建并替換函數(shù)。攻擊者能夠通過服務(wù)器日志，確定超級用戶在日常運(yùn)維中會(huì)執(zhí)行的函數(shù)。一旦確定目標(biāo)函數(shù)，攻擊者可以替換該函數(shù)并嵌入提權(quán)SQL語句。當(dāng)該函數(shù)下次被調(diào)用后，攻擊者即可成為數(shù)34查看服務(wù)器日志數(shù)據(jù)庫等待 ·NSFOCUS查看服務(wù)器日志數(shù)據(jù)庫等待 1.我們在申請到數(shù)據(jù)庫服務(wù)后，發(fā)現(xiàn)在初始用戶在系統(tǒng)schemapg_catalog下具備創(chuàng)建讀取用戶權(quán)限讀取用戶權(quán)限2用戶權(quán)限表5數(shù)據(jù)庫函數(shù)表查看日志確定待嵌入函數(shù)47超級用戶提權(quán)邏輯嵌入函數(shù)服務(wù)器日志權(quán)限36我們在成為超級用戶后，發(fā)現(xiàn)若數(shù)據(jù)庫實(shí)例被禁用program特性（允許數(shù)據(jù)庫的特定用35數(shù)據(jù)庫越權(quán)問題說明當(dāng)前數(shù)據(jù)庫用戶權(quán)限機(jī)制可能存在漏洞。在多租戶共享數(shù)據(jù)庫服務(wù)4.3小結(jié)云安全實(shí)踐在很多方面與傳統(tǒng)的IT和網(wǎng)絡(luò)安全實(shí)踐相似，但是存在一些重要差異。與傳（例如，云存儲(chǔ)服務(wù)、云計(jì)算服務(wù)、云網(wǎng)絡(luò)服務(wù)）的安全，云租戶則負(fù)責(zé)管理虛擬機(jī)管理程序之上的所有內(nèi)容（例如訪客操作系統(tǒng)、用戶、應(yīng)用程序，數(shù)據(jù)）的安全。攻擊者可能嘗試?yán)萌鏟uppet、Chef和Ansible等基礎(chǔ)設(shè)施即代碼(InfrastructureasCode，IaC)工具來發(fā)起攻擊和中斷服務(wù)，因而云租戶必須制定各種安全措施，以保護(hù)基于云的應(yīng)用程序和數(shù)據(jù)并Gartner認(rèn)為云安全是需要考慮的，但是更多是到底如何安全使用云，即企業(yè)應(yīng)該把重心放在自身如何進(jìn)行應(yīng)用的構(gòu)建，從而運(yùn)用云的最佳實(shí)踐，并逐步完善云安全管理能力[27]。用戶在使用公有云各類服務(wù)時(shí)應(yīng)對這些風(fēng)險(xiǎn)保持警惕，與云服務(wù)商建立強(qiáng)有力的合作關(guān)系，并采取適當(dāng)?shù)陌踩胧﹣泶_保其數(shù)據(jù)和業(yè)務(wù)的安企業(yè)業(yè)務(wù)系統(tǒng)上云不是一蹴而就的，也不是一帆風(fēng)順的。建議首先要對數(shù)據(jù)進(jìn)行分類，36·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室在上云過程中，建議從前兩個(gè)數(shù)據(jù)開始，以驗(yàn)證上云過程是否可以，并在此過程中逐步最后，云安全相對傳統(tǒng)安全進(jìn)行了顛覆，但并不是完全排他。首先，不是所有的應(yīng)用都會(huì)上云，原有的一些安全舉措仍然有效;其次，上云后建議打開云原生的安全管控能力，包括對工作負(fù)載安全或者對用戶訪問行為分析，云上提供的數(shù)據(jù)相對很全面;最后，如果采用38·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室●觀點(diǎn)5：近年敏捷開發(fā)模式流行，但開發(fā)者安全意識缺失，造成大量DevOps組件服務(wù)暴露在互聯(lián)網(wǎng)上，不同程度帶有NDay漏洞。這些漏洞可能來自于組件本身，或5.1DevOps與云計(jì)算云計(jì)算敏捷、彈性的特性促使企業(yè)紛紛上云，這使得云應(yīng)用自身的開發(fā)、部署也逐漸遵循開發(fā)運(yùn)營一體化（DevOps）的原則。一方面云計(jì)算為DevOps提供了靈活、可擴(kuò)展的基礎(chǔ)設(shè)施和服務(wù)支持。另一方面，DevOps也通過自動(dòng)化的持續(xù)集成、持續(xù)部署，更好地適應(yīng)云計(jì)算的快速、靈活和彈性的特點(diǎn)，加速了云計(jì)算的落地與實(shí)踐。因此，云計(jì)算與DevOps5.2DevOps風(fēng)險(xiǎn)分析近年來件供應(yīng)鏈安全事件層出不窮，如2021年的Codecov供應(yīng)鏈攻擊事件。該事件直接導(dǎo)致近3萬用戶的隱私數(shù)據(jù)泄漏。Codecov是一款國外軟件審計(jì)平臺，該平臺被部署在云上作為CI/CD工作流中的一環(huán)。攻擊者利用Codecov鏡像Dockerfile中的錯(cuò)誤配置提取BashUploader腳本（用戶可通過該腳本上傳測試數(shù)據(jù)）中的訪問憑證，進(jìn)而通過該憑證修改用戶的BashUploader腳本[28]，在長達(dá)1000多行的BashUploader腳本中添加如下兩圖5.1BashUploader腳本中注入的惡意代碼上述代碼會(huì)將CI過程中所有的環(huán)境變量發(fā)送至第三方服務(wù)器，這些環(huán)境變量中可能包含Git訪問憑證、APIKey等敏感信息和密鑰，攻擊者可以通過這些憑證訪問更多的服務(wù)、編碼、測試、構(gòu)建、發(fā)布、部署、運(yùn)營及監(jiān)控，每個(gè)階段均會(huì)涉及大量組件，這些敏感數(shù)據(jù)往往會(huì)成為巨大的攻擊杠桿。一旦讓攻擊者有機(jī)可趁，可能會(huì)進(jìn)一步導(dǎo)致云計(jì)算環(huán)境的數(shù)據(jù)泄露、服務(wù)中斷、供應(yīng)鏈安全等風(fēng)險(xiǎn)，從而危及系統(tǒng)的可用性、機(jī)密性和完整性。39為了更深入了解DevOps風(fēng)險(xiǎn)，我們從數(shù)據(jù)流的角度將DevOps流程中各個(gè)階段產(chǎn)生的通常情況下，CI/CD工具根據(jù)用戶自定義的管道流程，在開發(fā)者進(jìn)行g(shù)itpush/pull等操作時(shí)觸發(fā)接入源碼倉庫，在接入過程中由于源碼倉庫自身提供多種接入方式，進(jìn)而擴(kuò)大了風(fēng)險(xiǎn)面，圖5.3展示了Gitlab提供的幾種訪問途徑：圖5.3源碼倉庫訪問途徑可以看出除了常規(guī)的源碼訪問（push/pull/mergerequest等）、Web訪問以及API訪問，Gitlab還提供Webhook訪問。在第三方開發(fā)團(tuán)隊(duì)對源碼倉庫進(jìn)行push/pull操作時(shí)，若未對40·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室關(guān)于引入第三方開源組件的風(fēng)險(xiǎn)，通常包含以下四部分內(nèi)容：開源組件自身漏洞導(dǎo)致的風(fēng)險(xiǎn):許多開源組件自身存在漏洞，不同風(fēng)險(xiǎn)級別的漏洞會(huì)導(dǎo)致CI/CD環(huán)境面臨不同程度風(fēng)險(xiǎn)，例如若開源組件存在RCE漏洞，攻擊者則可能利用該漏洞獲取CI/CD管道中的環(huán)境變量，進(jìn)而獲取Gitlab或Github的有效訪問憑證，最終接管整不安全的開源組件管理導(dǎo)致的風(fēng)險(xiǎn):在CI/CD管道中，我們通常會(huì)引入第三方開源組件對項(xiàng)目依賴項(xiàng)進(jìn)行構(gòu)建管理。例如Java項(xiàng)目中，通常會(huì)引入Maven倉庫，若我們的項(xiàng)目直接從Maven中央倉庫進(jìn)行拉取，我們就無法確定是否引入了含有漏洞的組件，進(jìn)而可能導(dǎo)攻擊者為開源組件添加后門程序?qū)е碌娘L(fēng)險(xiǎn):若攻擊者擁有訪問開源組件倉庫的權(quán)限，進(jìn)而可以通過為開源組件添加惡意后門程序，以重新對外發(fā)布的形式，引發(fā)大規(guī)模供應(yīng)鏈攻擊的風(fēng)險(xiǎn)。若用戶的項(xiàng)目源碼中引入了含有后門的開源組件，攻擊者則有可能利用該漏洞對構(gòu)建階段，CI/CD管道通常會(huì)引入插件對源碼以及第三方開源組件代碼進(jìn)行構(gòu)建。這類述提到的Codecov供應(yīng)鏈?zhǔn)录校芎φ呦螺d了攻擊者精心注入惡意代碼的文件，導(dǎo)致CI/自動(dòng)化測試是CI/CD管道中必經(jīng)的一環(huán)，自動(dòng)化測試常包含集成測試、單元測試、安全例如Gitlab的CI/CD管道默認(rèn)支持引入開源代碼審計(jì)工具bundler-audit、gemnasium等。還是外部，若是外部將不受DevOps實(shí)施者的控制，可能進(jìn)而會(huì)導(dǎo)致測試流量被代理到第三方服務(wù)器的風(fēng)險(xiǎn)，再如當(dāng)測試階段完成后，測試結(jié)果最終存儲(chǔ)在哪里，若存儲(chǔ)在外部，也會(huì)41此外，風(fēng)險(xiǎn)漏洞管理也十分關(guān)鍵，如當(dāng)Gitlab進(jìn)行鏡像掃描后產(chǎn)生了一系列待修復(fù)的漏洞，誰擁有什么權(quán)限訪問這些漏洞很重要，若管理員分配了錯(cuò)誤的權(quán)限，則可能導(dǎo)致未授權(quán)訪問的風(fēng)險(xiǎn)，這里的未授權(quán)訪問主要針對的是第三方團(tuán)隊(duì)的開發(fā)人員。經(jīng)歷測試階段后，CI/CD管道會(huì)評估最新的測試結(jié)果，一旦測試通過會(huì)將軟件進(jìn)行打包以及后續(xù)的分發(fā)。此處以微服務(wù)架構(gòu)的項(xiàng)目舉例，打包階段時(shí)，各個(gè)微服務(wù)通過Dockerfile文件進(jìn)行鏡像構(gòu)建，并進(jìn)行簽名后將鏡像上傳至倉庫。分發(fā)部署階段時(shí)，Kubernetes會(huì)從鏡像倉庫中拉取最新版本的鏡像以完成后續(xù)部署。以上過程中可能會(huì)產(chǎn)生一定的風(fēng)險(xiǎn)，主要鏡像自身內(nèi)容引發(fā)的風(fēng)險(xiǎn):若業(yè)務(wù)鏡像依賴的基礎(chǔ)鏡像含有漏洞，可能導(dǎo)致攻擊者利用已知漏洞對服務(wù)自身或其他微服務(wù)發(fā)起攻擊，若鏡像中的應(yīng)用代碼含有漏洞，也將會(huì)導(dǎo)致被鏡像分發(fā)過程引發(fā)的風(fēng)險(xiǎn):由于CI/CD與Kubernetes可能不在同一環(huán)境，因而可能導(dǎo)致攻擊者在分發(fā)過程中趁虛而入，利用鏡像來源的不確定性（惡意鏡像簽名）對鏡像的傳輸過程進(jìn)行劫持，并替換成惡意鏡像，亦或是對鏡像倉庫直接發(fā)起攻擊，造成巨大影響。鑒于上述提出的DevOps流程各階段風(fēng)險(xiǎn)，我們對相關(guān)組件服務(wù)的暴露面和攻擊面進(jìn)行了統(tǒng)計(jì)和分析。在測繪到21萬多個(gè)不同DevOps組件服務(wù)中約有23%存在不同程度的未授權(quán)訪問情況，如未授權(quán)訪問代碼、鏡像、組件后臺等。漏洞與不安全配置加上極低的利用成本，使得互聯(lián)網(wǎng)中暴露的DevOps組件服務(wù)存在嚴(yán)重的安全我們研究的DevOps組件包括Confluence1、Gitlab2、Harbor3、Sonarqube4、Jenkins5、Docker6、Kubernetes7及Prometheus8，涵蓋DevOps流程的8個(gè)階段，下面逐1/software/confluence2/3https://goharbor.io/4/products/sonarqube/5https://www.jenkins.io/6/7https://kubernetes.io/8https://kubernetes.io/42服務(wù)數(shù)量（個(gè)）·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室服務(wù)數(shù)量（個(gè)）5.2.1ConfluenceConfluence是一款由Atlassian公司開發(fā)的協(xié)作與文檔管理工具，主要用于團(tuán)隊(duì)協(xié)作、知識共享和文檔編寫。由于Confluence與其他Atlassian產(chǎn)品（如Jira、Bitbucket）無縫集成，因此形成了一個(gè)全面的協(xié)作和開發(fā)生態(tài)系統(tǒng)，使得Confluence在整個(gè)軟件開發(fā)生命周在DevOps計(jì)劃階段，Confluence作為信息中心，幫助團(tuán)隊(duì)收集、整理和共享與項(xiàng)目相關(guān)的文檔、設(shè)計(jì)文稿、技術(shù)規(guī)范等信息，確保所有相關(guān)方了解項(xiàng)目狀態(tài)和進(jìn)展，減少信息斷組件暴露面分析我們對2023年全球互聯(lián)網(wǎng)暴露的21150個(gè)Confluence服務(wù)進(jìn)行了測繪，并對結(jié)果進(jìn)行統(tǒng)計(jì)、分析。下面從地區(qū)、歸屬組織、端口及版本分布情況分別進(jìn)行介紹。圖5.4展示了暴露Confluence服務(wù)數(shù)量的Top10地區(qū)，前三的地區(qū)分別是美國、日本和德國，暴露數(shù)量占測繪總量的40%。其中美國暴露資產(chǎn)數(shù)量排名首位，暴露的Confluence服務(wù)達(dá)到5062個(gè)，占比約23%。05062173217241298107710169589439359271298地區(qū)圖5.4暴露Confluence服務(wù)地區(qū)分布情況圖5.5展示了暴露的Confluence服務(wù)歸屬組織的Top5。在能夠測繪到歸屬組織的Confluence服務(wù)中，占比位居首位的是亞馬遜（Amazon約78%；第二位是光環(huán)新網(wǎng)（GuanghuanXinwangDigital約2%；第三位是西云數(shù)據(jù)（NWCDcloud約1%。43服務(wù)數(shù)量（個(gè)）Amazon服務(wù)數(shù)量（個(gè)）Amazon17%17%78%圖5.5暴露Confluence服務(wù)歸屬組織分布情況如圖5.6所示，我們測繪了全球21150個(gè)暴露端口的Confluence服務(wù)，并記錄了Top10。其中，暴露數(shù)量前三的端口分別是443、8089和8200，占比2%。其中443端口暴露量最多，共計(jì)280個(gè)，占比約1%。02801641641089188868483端口圖5.6暴露Confluence服務(wù)端口分布情況同時(shí)，我們還對Confluence服務(wù)的版本情況進(jìn)行了統(tǒng)計(jì)，共21150個(gè)，圖5.7展示了Top10版本。其中，暴露數(shù)量前三的版本分別是7.13.0、7.17.4和7.19.17，占比98%。其中7.13.0版本Confluence暴露量最多，共計(jì)18518個(gè)，占比約87%。截至報(bào)告撰寫時(shí)，Confluence最新版本為8.7.2。44服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）0185182290111622版本圖5.7暴露Confluence服務(wù)版本分布情況組件攻擊面分析與影響首先，我們發(fā)現(xiàn)互聯(lián)網(wǎng)暴露的21150個(gè)Confluence服務(wù)中，約有99%均不同程度存在NDay漏洞。我們僅對影響暴露Confluence服務(wù)的Top10漏洞（Top10的選擇標(biāo)準(zhǔn)為影響暴露Confluence服務(wù)數(shù)量）進(jìn)行統(tǒng)計(jì)、分析。如圖5.8所示，我們發(fā)現(xiàn)有CVE-2023-22503可以看出排名Top5的漏洞均為2023年被曝出的，且Top10漏洞中代碼、命令執(zhí)行類漏洞占比最高，約占58%。這類漏洞將直接影響Confluence運(yùn)行的宿主機(jī)，容易造成服務(wù)中斷2500020855017282I17090I17031I17021I3726漏洞圖5.8暴露Confluence服務(wù)漏洞分布情況45此外，我們還對Confluence覆蓋CVSS3.0評分7.5以上的漏洞版本進(jìn)行了統(tǒng)計(jì)分析。具體見表格5-1：表5-1Confluence版本漏洞統(tǒng)計(jì)分析7.13.0，7.17.4，7.13.43CVE-2023-22508，CVE-2023-22522，CVE-2023-225187.19.17，8.5.4，7.19.16，8.6.21CVE-2023-225228.5.33CVE-2023-22522，CVE-2023-22527，CVE-2023-225188.6.12CVE-2023-22522，CVE-2023-22518同時(shí)，我們匯總了近年來與Confluence相關(guān)的安全事件,可以看出平均每年都有安全事2021年，某黑客組織利用ConfluenceCVE-2021-26084未授權(quán)代碼注入漏洞入侵了Jenkins項(xiàng)目開發(fā)團(tuán)隊(duì)服務(wù)器，并植入了挖礦工具[30]?？赡軐?dǎo)致服務(wù)資源被大量占用、性能下降，影響正常業(yè)務(wù)運(yùn)行，甚至服務(wù)中斷。2022年，瑞士網(wǎng)絡(luò)威脅情報(bào)公司Prodaft發(fā)現(xiàn)，AvosLocker勒索組織利用ConfluenceCVE-2022-26134未授權(quán)OGNL代碼注入漏洞對暴露在互聯(lián)網(wǎng)上的未打補(bǔ)丁的Confluence2023年11月，工信部網(wǎng)絡(luò)安全威脅和漏洞信息共享平臺監(jiān)測發(fā)現(xiàn)，黑客組織在使用ConfluenceCVE-2023-22518身份認(rèn)證繞過漏洞及Cerber勒索病毒新變種實(shí)施勒索攻擊[32]。勒索攻擊會(huì)使得計(jì)算機(jī)系統(tǒng)將無法正常使用，直至受害者交納巨額贖金。組件風(fēng)險(xiǎn)緩解措施1.及時(shí)將Con?uence及Con?uence插件升級至安全版本；5.定期培訓(xùn)Con?uence使用人員的安全意識，防止社工；5.2.2GitlabGitlab是一個(gè)基于Git版本控制系統(tǒng)的開源代碼托管平臺，支持Git版本控制系統(tǒng)，使團(tuán)隊(duì)能夠方便存儲(chǔ)、追蹤和管理源代碼。Gitlab強(qiáng)大的CI/CD功能使其成為一些團(tuán)隊(duì)和組織的46服務(wù)數(shù)量（個(gè)）·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室服務(wù)數(shù)量（個(gè)）首選，它能夠自動(dòng)化構(gòu)建、測試和部署流程，提高開發(fā)效率。在DevOps編碼階段，Gitlab為DevOps流程提供了高效的代碼管理、版本控制和協(xié)同開發(fā)的解決方案，有助于團(tuán)隊(duì)更加順暢地進(jìn)行軟件開發(fā)工作。組件暴露面分析分析。下面從地區(qū)、歸屬組織、端口及版本分部情況分別進(jìn)行介紹。如圖5.9所示，暴露數(shù)量前三的地區(qū)分別是中國、美國和德國，暴露數(shù)量約占測繪總量的55%。其中中國暴露量排名首位，暴露的Gitlab服務(wù)達(dá)到11559個(gè)，占比約27%。0115595724572456313081192212908061015897882地區(qū)圖5.9暴露Gitlab服務(wù)地區(qū)分布情況圖5.10展示了暴露的Gitlab服務(wù)歸屬組織測繪情況，在能夠測繪到歸屬組織的Gitlab服務(wù)中，占比位居首位的是阿里云（Alibaba約10%；第二位是亞馬遜（Amazon約10%；第三位是HetznerOnlineGmbH，約6%。47服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）AlibabaAmazonHetznerOnlineGmbHTencentChinanetOther圖5.10暴露Gitlab服務(wù)歸屬組織分布情況其中，暴露數(shù)量前三的端口分別是443、80和80共計(jì)24733個(gè)，占比約59%。2473375357535118366211836626156054614193650端口圖5.11暴露Gitlab服務(wù)端口分布情況同時(shí)，我們還對Gitlab服務(wù)的版本情況進(jìn)行了統(tǒng)計(jì)，共32160個(gè)，圖5.12展示了其分布情況。其中，暴露數(shù)量前三的版本分別是16.7.3、14.8.4和16.6.5，占比33%。其中16.7.3版本Gitlab暴露量最多，共計(jì)9003個(gè)，占比約27%。截至報(bào)告撰寫時(shí)，Gitlab最新版本為16.8。48服務(wù)數(shù)量（個(gè)）·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室服務(wù)數(shù)量（個(gè)）9003884842581575557545530520884842版本圖5.12暴露Gitlab服務(wù)版本分布情況組件攻擊面分析與影響我們發(fā)現(xiàn)互聯(lián)網(wǎng)暴露的Gitlab服務(wù)中，約有77%均不同程度存在NDay漏洞。我們僅對影響暴露Gitlab服務(wù)的2023年Top10漏洞進(jìn)行統(tǒng)計(jì)、分析。如圖5.13所示，我們發(fā)現(xiàn)CVE-2023-3424（拒絕服務(wù)）16528個(gè)，CVE-2022023-1708（命令執(zhí)行）14873個(gè)，CVE-2023-2199（拒絕服務(wù)）14701個(gè)，CVE-2023-65.1%。拒絕服務(wù)漏洞將直接導(dǎo)致Gitlab無法提供正常服務(wù)，導(dǎo)致DevOps中斷，嚴(yán)重影響49服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）0165281652815300148731470114392131579083448743214234漏洞圖5.13暴露Gitlab服務(wù)漏洞分布情況同時(shí)，我們匯總了近年來與Gitlab相關(guān)的安全事件。雖然近些年沒有被曝出重大安全事2021年11月，微步情報(bào)局利用蜜罐捕獲到GitLab未授權(quán)遠(yuǎn)程命令執(zhí)行漏洞（CVE-2021-22205）在野利用，攻擊成功后攻擊者會(huì)植入挖礦木馬進(jìn)行挖礦。該漏洞無需進(jìn)行身2021年11月，GoogleCloud發(fā)現(xiàn)攻擊者利用GitLab漏洞（CVE-2021-22205通過受漏洞影響的資產(chǎn)發(fā)起超過1Tbps的DDoS攻擊。這些被黑客控制的Gitlab服務(wù)器是僵尸網(wǎng)絡(luò)的一部分，該僵尸網(wǎng)絡(luò)由“數(shù)千個(gè)受感染的GitLab實(shí)例”組成[34]。組件風(fēng)險(xiǎn)緩解措施5.2.3Harbor服務(wù)數(shù)量（個(gè)）·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室服務(wù)數(shù)量（個(gè)）作為容器鏡像倉庫，Harbor提供了安全、可靠的存儲(chǔ)，同時(shí)支持訪問控制、漏洞掃描和復(fù)制等功能，為企業(yè)級應(yīng)用的構(gòu)建、共享和交付提供了便利。在DevOps構(gòu)建階段，Harbor能夠提供可靠的鏡像管理和安全保障，推動(dòng)了持續(xù)集成和組件暴露面分析分析。下面從地區(qū)、歸屬組織、端口及版本分布情況分別進(jìn)行介紹。如圖5.14所示，Harbor服務(wù)暴露數(shù)量前三的地區(qū)分別是中國、美國和德國，暴露數(shù)量約占測繪數(shù)據(jù)的74%。其中中國暴露數(shù)量排名首位，達(dá)到3985個(gè)，占比約53%。0地區(qū)圖5.14暴露Harbor服務(wù)地區(qū)分布情況圖5.15展示了暴露的Harbor服務(wù)歸屬組織測繪情況，在能夠測繪到歸屬組織的服務(wù)中，位居首位的是阿里云（Alibaba占比約19%；第二位是亞馬遜（Amazon占比約12%；第三位是騰訊（Tencent占比約9%。服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）19%52%12%4%4%Amazon圖5.15暴露Harbor服務(wù)歸屬組織分布情況其中，暴露數(shù)量前三的端口分別是443、80和84共計(jì)4197個(gè)，占比約56%，進(jìn)而我們可以看出被暴露的Harbor服務(wù)多數(shù)采用了HTTPS證0端口圖5.16暴露Harbor服務(wù)端口分布情況同時(shí)，我們還對Harbor服務(wù)的版本情況進(jìn)行了統(tǒng)計(jì)，共4780個(gè)，圖5.17展示了其分布情況。其中，暴露數(shù)量前三的版本分別是2.8.2、2.9.1和2.9.0，約占14%。其中2.8.2版服務(wù)數(shù)量（個(gè)）·NSFOCUS《2023公有云安全風(fēng)險(xiǎn)分析報(bào)告》綠盟科技星云實(shí)驗(yàn)室服務(wù)數(shù)量（個(gè)）0版本圖5.17暴露Harbor服務(wù)版本分布情況組件攻擊面分析與影響我們發(fā)現(xiàn)互聯(lián)網(wǎng)暴露的Harbor服務(wù)中，約有55%均不同程度存在NDay漏洞。我們對影響暴露Harbor服務(wù)的Top10漏洞進(jìn)行統(tǒng)計(jì)、分析。如圖5.18所示，我們共發(fā)現(xiàn)CVE-2023-20902（未授權(quán)訪問）2438個(gè)，CVE-2022-46463（認(rèn)證繞過）2309個(gè)，CVE-2020-13788（服務(wù)端請求偽造）663個(gè)，CVE-2019-19030（未授權(quán)訪問）472個(gè)，CVE-2020-站請求偽造）178個(gè)，CVE-2019-19026（SQL注入）178個(gè)，CVE-2019-19029（SQL注入漏洞）178個(gè)及CVE-2019-16097（未授權(quán)訪問）117個(gè)。由于篇幅原因，其余漏洞情況不約占42%。服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）0漏洞圖5.18暴露Harbor服務(wù)漏洞分布情況此外，我們還對Harbor服務(wù)Top10版本的CVSS3.0評分7.5以上的漏洞覆蓋情況進(jìn)行了統(tǒng)計(jì)分析。詳見表5-2：表5-2Harbor版本漏洞統(tǒng)計(jì)分析2.5.3，2.4.11CVE-2022-46463組件風(fēng)險(xiǎn)緩解措施1.根據(jù)官方補(bǔ)丁版本及時(shí)對Harbor版2.根據(jù)官方提供的緩解措施進(jìn)行臨時(shí)緩解，Harbor相關(guān)的漏洞緩解措施可參考官方Github的Securityadvisories版面[35]5.2.4SonarQubeSonarQube是一個(gè)開源的代碼質(zhì)量管理平臺，在全球范圍內(nèi)有龐大的開發(fā)者社區(qū)。SonarQube專注于靜態(tài)代碼分析，幫助團(tuán)隊(duì)檢測和解決代碼質(zhì)量問題。SonarQube在國內(nèi)在DevOps測試階段，SonarQube能夠?qū)Υa執(zhí)行靜態(tài)分析，識別潛在的缺陷、漏洞，提前發(fā)現(xiàn)問題，減少后期的維護(hù)成本。此外，SonarQube提供實(shí)時(shí)的代碼質(zhì)量反饋，開發(fā)者能夠及時(shí)了解代碼的健康狀況，并在測試階段進(jìn)行迭代改進(jìn)。組件暴露面分析我們對2023年全球互聯(lián)網(wǎng)暴露的11781個(gè)SonarQube服務(wù)進(jìn)行了測繪，并對結(jié)果進(jìn)服務(wù)數(shù)量（個(gè)）AmazonMircrosoftGoogleDigitaloceanHetznerOnlineGmbHOther服務(wù)數(shù)量（個(gè)）AmazonMircrosoftGoogleDigitaloceanHetznerOnlineGmbHOther行統(tǒng)計(jì)、分析。下面從地區(qū)、歸屬組織、端口及版本分布情況分別進(jìn)行介紹。如圖5.19所示，SonarQube服務(wù)暴露數(shù)量前三的地區(qū)分別是美國、德國和愛爾蘭，暴露數(shù)量約占測繪數(shù)據(jù)的63%。其中美國暴露數(shù)量排名首位，達(dá)到5755個(gè)，占比約48%。0地區(qū)圖5.19暴露SonarQube服務(wù)地區(qū)分布情況圖5.20展示了暴露的SonarQube服務(wù)歸屬組織測繪情況，在能夠測繪到歸屬組織的服務(wù)中，位居首位的是亞馬遜（Amazon占比約58%；第二位是微軟（Mircrosoft占比約12%；第三位是谷歌（Google），占比約6%。19%19%2%3%6%58%12%圖5.20暴露SonarQube服務(wù)歸屬組織分布情況如圖5.21所示，我們測繪了全球11781個(gè)暴露端口的SonarQube服務(wù)，并記錄了分布情況。其中，暴露數(shù)量前三的端口分別是443、9000和80，暴露數(shù)量約占測繪數(shù)據(jù)的服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）95%。其中443端口暴露量最多，共計(jì)5264個(gè)，占比約44%。0端口圖5.21暴露SonarQube服務(wù)端口分布情況同時(shí)，我們還對SonarQube服務(wù)的版本情況進(jìn)行了統(tǒng)計(jì)，共542個(gè)，圖5.22展示了其分布情況。其中，暴露數(shù)量前三的版本分別是7.9.1、8.8.5.1版本SonarQube暴露量最多，均為29個(gè)，占比約5%。截至報(bào)告撰寫時(shí)，SonarQube最新版本為10.3.0。50版本圖5.22暴露SonarQube服務(wù)版本分布情況組件攻擊面分析與影響服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）由于近幾年SonarQube并未曝出新漏洞，因此我們發(fā)現(xiàn)互聯(lián)網(wǎng)暴露的11781個(gè)SonarQube服務(wù)中，僅有1.2%存在NDay漏洞。我們對其四個(gè)歷史漏洞進(jìn)行統(tǒng)計(jì)、分析。15個(gè)。能夠測繪到存在漏洞的SonarQube服務(wù)約占暴露總資產(chǎn)的1%。其中，每個(gè)資產(chǎn)可0CVE-2019-17579CVE-2018-19413CVE-202漏洞圖5.23暴露SonarQube服務(wù)版本分布情況此外，我們還對SonarQube服務(wù)Top10版本的CVSS3.0評分7.5以上的漏洞覆蓋情況進(jìn)行了統(tǒng)計(jì)分析。詳見表5-3：表5-3SonarQube版本漏洞統(tǒng)計(jì)分析8.4.21CVE-2020-27986組件風(fēng)險(xiǎn)緩解措施服務(wù)數(shù)量（個(gè)）服務(wù)數(shù)量（個(gè)）1.將SonarQube升級至安全版本；2.參考官網(wǎng)給出的安全實(shí)踐進(jìn)行加固[36]；5.2.5JenkinsJenkins是一款開源的自動(dòng)化服務(wù)器，用于構(gòu)建、測試和部署軟件項(xiàng)目。它通過提供易來自全球的開發(fā)者在貢獻(xiàn)插件、腳本和解決方案，幫助其他用戶更好地利用Jenkins進(jìn)行自在DevOps發(fā)布階段，Jenkins通過集成版本控制系統(tǒng)和構(gòu)建工具來實(shí)現(xiàn)自動(dòng)化將應(yīng)用程序部署到目標(biāo)環(huán)境中。此外，Jenkins還支持并行部署、藍(lán)綠部署等策略，幫助團(tuán)隊(duì)更靈組件暴露面分析我們對2023年全球互聯(lián)網(wǎng)暴露的63579個(gè)Jenkins服務(wù)進(jìn)行了測繪，并對結(jié)果進(jìn)行統(tǒng)計(jì)、分析。下面從地區(qū)、歸屬組織、端口及版本分布情況分別進(jìn)行介紹。如圖5.24所示，Jenkins服務(wù)暴露數(shù)量前三的地區(qū)分別是美國、中國和德國，暴露數(shù)量約占測繪數(shù)據(jù)的60%。其中美國暴露數(shù)量排名首位，達(dá)到21745個(gè)，占比約34%。0