最近，攻擊者在利用CI/CD以及開(kāi)發(fā)工具當(dāng)中的漏洞進(jìn)行攻擊，導(dǎo)致對(duì)開(kāi)發(fā)架構(gòu)的安全性有了新的要求。Codecov供應(yīng)鏈攻擊尤其對(duì)每一個(gè)在CI/CD環(huán)境中儲(chǔ)存機(jī)密信息的人發(fā)出了警告——無(wú)論這個(gè)環(huán)境看上去有多安全。

通過(guò)破解一個(gè)被幾千名開(kāi)發(fā)者使用的Bash上傳組件，Codecov攻擊者能夠從客戶環(huán)境中竊取憑證、密鑰、以及API token，還能保持兩個(gè)月中不被發(fā)現(xiàn)。在此之上，還成功攻擊了數(shù)百個(gè)客戶的網(wǎng)絡(luò)。類似的情況還有針對(duì)像Jenkins、GitHub Action和云原生容器環(huán)境等自動(dòng)化攻擊的攻擊，這些都進(jìn)一步讓企業(yè)去針對(duì)這些工具探索并部署有效的防御手段。

六條保護(hù)CI/CD管道的建議

1. 不要在CI/CD環(huán)境中儲(chǔ)存機(jī)密信息

Codecov供應(yīng)鏈攻擊獲得極大成功的原因，在于被攻擊者設(shè)法溢出的環(huán)境變量里存在硬編碼的機(jī)密信息，包括口令、通證和密鑰。攻擊者利用其中其中的一些憑證接入了企業(yè)的私有GitHub庫(kù)，進(jìn)一步從庫(kù)中竊取的數(shù)據(jù)就包含了應(yīng)該保密的數(shù)據(jù)。

盡管說(shuō)包括HashCorp、Twilio、Rapid7和Monday.com等Codecov的多個(gè)客戶公開(kāi)了供應(yīng)鏈攻擊的影響，到現(xiàn)在為止受影響最大的公司是日本的電商巨頭Mercari。超過(guò)2.7萬(wàn)條記錄被泄露，包括客戶的財(cái)務(wù)信息、商品信息、商業(yè)伙伴信息、公司員工信息、承包商信息等多個(gè)實(shí)體信息。

毫無(wú)疑問(wèn)，這些攻擊都是由Codecov的泄露引起的，但也有些人質(zhì)疑為何像客戶財(cái)務(wù)記錄這類的個(gè)人識(shí)別信息都會(huì)儲(chǔ)存在私有的GitHub庫(kù)里。

類似問(wèn)題也發(fā)生在HashiCorp將GPG私鑰儲(chǔ)存在CI/CD環(huán)境當(dāng)中。該密鑰用于簽署和驗(yàn)證由HashiCorp發(fā)布的軟件。在密鑰被廢除以前，攻擊者可以濫用該密鑰來(lái)偽造一個(gè)帶有HashiCorp簽名的惡意軟件發(fā)布。一個(gè)開(kāi)發(fā)人員甚至表示：“為什么沒(méi)有人提到Vault的供應(yīng)商HashiCorp，竟然將他們的簽名密鑰作為ENV保存的事實(shí)?天啊，這讓我對(duì)自己的人生感到好多了。”

組織需要重新思考哪些秘密信息能夠儲(chǔ)存在CI/CD工具集、環(huán)境變量與私有GitHub庫(kù)中。如果一個(gè)應(yīng)用需要將憑證或者通證儲(chǔ)存到這些位置，最好將憑證存到一個(gè)權(quán)限要求最小的賬戶或者資源中。那樣，即使相關(guān)秘密信息在不可預(yù)期的攻擊中被泄露了，損害也能被遏制。

2. 仔細(xì)檢查自動(dòng)化pull請(qǐng)求與計(jì)劃任務(wù)

像GitHub Actions這類的CI/CD自動(dòng)化工具能讓開(kāi)發(fā)者為他們的代碼庫(kù)建立計(jì)劃任務(wù)，比如自動(dòng)化否決和處理收到的pull請(qǐng)求。但是，如果一個(gè)貢獻(xiàn)者對(duì)一個(gè)有惡意意圖的開(kāi)源項(xiàng)目發(fā)起pull請(qǐng)求，又會(huì)如何呢?

2021年四月，GitHub Actions遭到攻擊者濫用，對(duì)幾百個(gè)庫(kù)發(fā)起pull請(qǐng)求，試圖用GitHub的基礎(chǔ)設(shè)施進(jìn)行挖礦。該大規(guī)模攻擊在2月份GitHub Actions的漏洞被報(bào)告后發(fā)生。

哪怕是最低限度的情況，這些pull請(qǐng)求會(huì)濫用GitHub的服務(wù)器進(jìn)行挖礦，或者執(zhí)行攻擊者的惡意代碼。如果項(xiàng)目所有者疏忽大意地合并了這些pull請(qǐng)求，就會(huì)將這些惡意代碼引入自己的庫(kù)以及更廣泛的供應(yīng)鏈。五月，GitLab報(bào)告在他們的平臺(tái)發(fā)現(xiàn)了一個(gè)類似的挖礦攻擊，攻擊者濫用了新賬戶的免費(fèi)時(shí)間。

由于像GitHub Actions和GitLab這種CI/CD自動(dòng)化工具的本質(zhì)是簡(jiǎn)化關(guān)鍵任務(wù)的自動(dòng)化能力，“守門”就成了一大挑戰(zhàn)。原本設(shè)計(jì)好的功能可能很快反而成為了一個(gè)安全隱患，被惡意人員所濫用。

GitHub最近宣布添加了新功能，以對(duì)抗濫用其Actions平臺(tái)進(jìn)行挖礦的攻擊者：“從首次貢獻(xiàn)者發(fā)起的pull請(qǐng)求在任何Actions工作流能執(zhí)行前，都需要庫(kù)合作者手動(dòng)通過(guò)。當(dāng)一個(gè)首次貢獻(xiàn)者打開(kāi)一個(gè)pull請(qǐng)求，他們會(huì)看見(jiàn)一條信息告知在他們的工作流執(zhí)行前，必須由一個(gè)維護(hù)者通過(guò)這個(gè)工作流。” GitHub的產(chǎn)品經(jīng)理Chris Patterson在博客中提到。

CI/CD解決方案和DevOps平臺(tái)的領(lǐng)軍廠商可以追隨GitHub的方式，增加一些安全檢查，發(fā)現(xiàn)他們基礎(chǔ)設(shè)施中被惡意人員大規(guī)模濫用的行為。

3. 加強(qiáng)并周期性審計(jì)云原生容器

沒(méi)有什么比確保業(yè)務(wù)容器恰當(dāng)配置并針對(duì)通常攻擊載體加固等標(biāo)準(zhǔn)最佳實(shí)踐更重要的了，這還包括了保證管道配置正確。

但是，一些細(xì)小的配置錯(cuò)誤有時(shí)候很難被人發(fā)現(xiàn)。然后問(wèn)題就來(lái)了，基于Docker的環(huán)境是否會(huì)不受漏洞威脅呢?這就是為什么需要經(jīng)常對(duì)自己的容器做安全審計(jì)發(fā)現(xiàn)脆弱性的原因，掃描容器映象和清單文件以發(fā)現(xiàn)常見(jiàn)的安全問(wèn)題依然很有幫助。

建議可以投資可以自動(dòng)化處理這些事情的可靠云原生容器安全解決方案。每年公布的大量安全隱患幾乎不可能全部由人工進(jìn)行追蹤。

另外，隨著企業(yè)啟用Kubernetes框架以及Docker容器來(lái)部署他們的應(yīng)用，WAF內(nèi)置的容器安全解決方案可以早期檢測(cè)并阻斷可疑的網(wǎng)絡(luò)流量。這就可以防止更大的失陷事件，即使攻擊者能夠滲透入容器并獲取最初的接入權(quán)限。

4. 集成深度代碼掃描以自動(dòng)化檢查代碼質(zhì)量

在代碼進(jìn)入業(yè)務(wù)環(huán)境之前，就被自動(dòng)化檢查代碼質(zhì)量、安全隱患和內(nèi)存漏出這類的漏洞，就可以有效地從頭開(kāi)始保護(hù)CI/CD管道。盡管說(shuō)關(guān)注點(diǎn)看上去主要針對(duì)網(wǎng)絡(luò)攻擊的防御，但是某些看上去無(wú)害的漏洞同樣產(chǎn)生大規(guī)模影響——比如最近的搞垮全球多個(gè)主要站點(diǎn)的Fastly事件。

GitHub代碼掃描或者Sonatype的Lift之類的解決方案能夠和現(xiàn)有的代碼工作流無(wú)縫集成，在對(duì)開(kāi)發(fā)者沒(méi)有任何成本的情況下提供基礎(chǔ)的防護(hù)。組織最終的目的應(yīng)該是支援開(kāi)發(fā)者做出他們能做的最好的工作，同時(shí)盡量防止應(yīng)用中漏洞或者安全隱患的出現(xiàn)。不過(guò)，這同時(shí)還要讓開(kāi)發(fā)團(tuán)隊(duì)和安全團(tuán)隊(duì)之間的摩擦盡可能少。因此，實(shí)時(shí)在開(kāi)發(fā)者寫(xiě)代碼的時(shí)候?qū)ζ涓婢?，能夠省下所有人的時(shí)間，同時(shí)從一開(kāi)始就確保CI/CD管道整體的工作流安全。

5. 盡早對(duì)最新的CI/CD工具漏洞進(jìn)行補(bǔ)丁修復(fù)

2021年三月，攻擊者利用名為z0Miner的挖礦僵尸網(wǎng)絡(luò)在有漏洞的Jenkins和ElasticSearch服務(wù)器上進(jìn)行門羅幣挖礦。通過(guò)對(duì)暴露在互聯(lián)網(wǎng)的服務(wù)器利用RCE漏洞，攻擊者得以感染并接管自動(dòng)化基礎(chǔ)設(shè)施，實(shí)施他們的惡意行為。

同樣，在去年，Jenkins服務(wù)會(huì)被攻擊者利用，快速實(shí)現(xiàn)DDoS攻擊。這是基于一個(gè)能引起UDP反射放大攻擊的DoS漏洞，漏洞編號(hào)為CVE-2020-2100，分別會(huì)影響Jenkins v2.219和Jenkins LTS 2.204.1以下的版本。

盡快在高危漏洞被披露的時(shí)候給自動(dòng)化工具和管道打上補(bǔ)丁，這依然是確保CI/CD基礎(chǔ)設(shè)施安全的關(guān)鍵。

6. 在進(jìn)行更新前驗(yàn)證其完整性

應(yīng)用最新的更新和補(bǔ)丁是一個(gè)好主意，但是如何確保收到的更新并未被篡改?“升級(jí)到最新版本”這個(gè)被安全人員用了十幾年的銘言在SolarWinds供應(yīng)鏈攻擊后開(kāi)始遭到質(zhì)疑。

在SolarWinds事件中，Orian的IT產(chǎn)品遭到惡意更新，使得攻擊者通過(guò)他們將惡意代碼下發(fā)到1.8萬(wàn)個(gè)客戶中。同樣的，Passwordstate的口令管理功能失陷，將惡意更新傳播給了他們的用戶。因此，現(xiàn)在盲目地進(jìn)行產(chǎn)品更新是一個(gè)糟糕的主意。

在Codecov的案例中，一個(gè)簡(jiǎn)單的完整性檢查就能發(fā)現(xiàn)為期兩個(gè)月的泄露事件。一個(gè)客戶注意到了在服務(wù)器上Bash Uploader的哈希校檢和與Codecov在GitHub庫(kù)上的合法校檢和不符，從而通知了Codecov。Codecov隨后修復(fù)了該問(wèn)題。

因此，一個(gè)深度的防御機(jī)制，要求對(duì)任何更新、補(bǔ)丁和下載都進(jìn)行完整性驗(yàn)證，從而將復(fù)雜的供應(yīng)鏈攻擊可能排除。

點(diǎn)評(píng)

CI/CD管道安全不僅僅需要拓寬對(duì)攻擊面的防御范圍，還需要一系列的安全意識(shí)與規(guī)范的補(bǔ)充。而從技術(shù)層面，由于CI/CD本身帶有極強(qiáng)的自動(dòng)化屬性，對(duì)于防護(hù)能力的自動(dòng)化水平也有了新的要求——安全不能以過(guò)于犧牲業(yè)務(wù)為代價(jià)而存在。同時(shí)，開(kāi)源軟件帶來(lái)的供應(yīng)鏈攻擊也意味著代碼也需要賦予“零信任”，并非來(lái)自可靠來(lái)源的代碼都必然是安全的。