研究人員警告稱(chēng)，在GitHub上托管代碼倉(cāng)庫(kù)的開(kāi)發(fā)者仍在不安全地使用GitHub Actions，設(shè)置了可能被利用來(lái)提取敏感認(rèn)證令牌的自動(dòng)工作流。

與GitHub Actions工作流相關(guān)的安全風(fēng)險(xiǎn)并非新鮮事，然而，Sysdig的研究人員已經(jīng)識(shí)別出了數(shù)十個(gè)存在漏洞的項(xiàng)目，其中包括來(lái)自知名且具備安全意識(shí)的高調(diào)企業(yè)MITRE和Splunk的項(xiàng)目。

Sysdig的研究人員在本周的一份報(bào)告中寫(xiě)道：“這些工作流往往包含機(jī)密信息，如API密鑰或憑證，這些信息可能被用于提升權(quán)限或在倉(cāng)庫(kù)內(nèi)橫向移動(dòng)，甚至如果被竊取，還可能在整個(gè)企業(yè)內(nèi)橫向移動(dòng)。盡管已有工具、技術(shù)和公開(kāi)研究詳細(xì)說(shuō)明了如何識(shí)別和利用這些漏洞，但許多開(kāi)源項(xiàng)目的整體成熟度仍然令人擔(dān)憂地低?！?/p>

Sysdig調(diào)查的一個(gè)攻擊向量涉及在pull_request_target事件上觸發(fā)的GitHub Actions工作流。據(jù)Sysdig稱(chēng)，這個(gè)攻擊向量會(huì)泄露機(jī)密和一個(gè)具有倉(cāng)庫(kù)寫(xiě)入權(quán)限的GitHub令牌，并且，由于該操作在基礎(chǔ)倉(cāng)庫(kù)而非觸發(fā)拉取請(qǐng)求的分支中執(zhí)行，因此如果未設(shè)置防護(hù)措施，它可能導(dǎo)致整個(gè)倉(cāng)庫(kù)被接管。

“在分析結(jié)果時(shí)，我們對(duì)發(fā)現(xiàn)的易受攻擊的pull_request_target工作流數(shù)量感到驚訝，”研究人員寫(xiě)道，“你可能會(huì)認(rèn)為這些僅限于不知名或不活躍的倉(cāng)庫(kù)，但事實(shí)并非如此，我們發(fā)現(xiàn)，幾個(gè)擁有數(shù)萬(wàn)顆星的高調(diào)項(xiàng)目仍在使用不安全的配置?！?/p>

GitHub Actions攻擊成為現(xiàn)實(shí)

GitHub Actions是一種CI/CD(持續(xù)集成和持續(xù)交付)服務(wù)，它使開(kāi)發(fā)者能夠通過(guò)設(shè)置在指定事件(如新代碼提交到倉(cāng)庫(kù))發(fā)生時(shí)觸發(fā)的工作流來(lái)自動(dòng)化軟件構(gòu)建和測(cè)試，這些工作流被稱(chēng)為Actions，是打包在.yml文件中的指令，通常在GitHub的基礎(chǔ)設(shè)施上的虛擬容器中執(zhí)行，并返回編譯后的二進(jìn)制文件、測(cè)試結(jié)果、日志等。

為了操作，工作流必須能夠克隆倉(cāng)庫(kù)并對(duì)其執(zhí)行操作，為此，系統(tǒng)會(huì)在本地.git文件夾中創(chuàng)建并保存一個(gè)臨時(shí)的GITHUB_TOKEN，以允許執(zhí)行經(jīng)過(guò)認(rèn)證的git命令，這個(gè)令牌本應(yīng)是短暫的，并且應(yīng)該在工作流完成后停止工作。

多年來(lái)，研究人員已經(jīng)展示了GitHub Actions如何被濫用，包括通過(guò)域名拼寫(xiě)錯(cuò)誤(typosquatting)、未清除機(jī)密信息的構(gòu)建產(chǎn)物以及在工作流之間轉(zhuǎn)移時(shí)的產(chǎn)物污染等方式，并且，這些不僅僅是理論上的攻擊。去年12月，攻擊者通過(guò)GitHub Actions腳本注入漏洞，成功入侵了GitHub上Ultralytics YOLO AI庫(kù)的構(gòu)建過(guò)程，這導(dǎo)致被污染的庫(kù)版本被上傳到了PyPI倉(cāng)庫(kù)。

危險(xiǎn)的拉取請(qǐng)求工作流觸發(fā)器

當(dāng)開(kāi)發(fā)者從他們分叉的代碼倉(cāng)庫(kù)版本提交新代碼回主倉(cāng)庫(kù)以供包含時(shí)，就會(huì)發(fā)生拉取請(qǐng)求，然后，項(xiàng)目的開(kāi)發(fā)者會(huì)對(duì)拉取請(qǐng)求進(jìn)行審查和評(píng)論，之后才會(huì)接受請(qǐng)求進(jìn)行提交。

在GitHub Actions中，pull_request觸發(fā)器會(huì)促使工作流在分叉分支的上下文中執(zhí)行，創(chuàng)建一個(gè)僅具有主倉(cāng)庫(kù)讀取權(quán)限的GITHUB_TOKEN，然而，pull_request_target觸發(fā)器會(huì)促使工作流在目標(biāo)分支(通常是主分支)的上下文中執(zhí)行，具有對(duì)倉(cāng)庫(kù)中存儲(chǔ)的所有機(jī)密信息的完全訪問(wèn)權(quán)限，以及一個(gè)具有讀取和寫(xiě)入權(quán)限的GITHUB_TOKEN。開(kāi)發(fā)者在使用此觸發(fā)器時(shí)需要謹(jǐn)慎，特別是對(duì)于那些嘗試從拉取請(qǐng)求中檢出、運(yùn)行或構(gòu)建代碼的工作流，因?yàn)榇a可能是惡意的，并且將獲得工作流的機(jī)密信息、令牌和權(quán)限。

GitHub Actions文檔實(shí)際上已經(jīng)警告了這種危險(xiǎn)行為，Sysdig發(fā)現(xiàn)，許多開(kāi)發(fā)者仍然以這種方式使用它來(lái)測(cè)試?yán)≌?qǐng)求中的代碼更改。

Sysdig發(fā)現(xiàn)的一個(gè)例子是Spotipy，這是一個(gè)用于與Spotify Web API交互的開(kāi)源Python庫(kù)，該項(xiàng)目在GitHub上相當(dāng)受歡迎，擁有超過(guò)5000顆星和近1000個(gè)分支。

Spotipy的工作流integration_tests.yml在pull_request_target上觸發(fā)，在從拉取請(qǐng)求的倉(cāng)庫(kù)檢出代碼之前，執(zhí)行pip install(Python包安裝器)命令以安裝依賴(lài)項(xiàng)。

如果攻擊者在他們的倉(cāng)庫(kù)中放置了一個(gè)惡意的setup.py文件，他們就可以在工作流的pip install操作期間執(zhí)行惡意代碼。研究人員的概念驗(yàn)證部署了一個(gè)memdump.py腳本，該腳本從內(nèi)存中提取了憑證，包括SPOTIPY_CLIENT_ID、SPOTIPY_CLIENT_SECRET以及具有讀寫(xiě)權(quán)限的特權(quán)GITHUB_TOKEN。

研究人員還在他們的惡意代碼中添加了sleep命令，以延長(zhǎng)工作流的執(zhí)行時(shí)間，從而延長(zhǎng)GITHUB_TOKEN的有效性，以便在它過(guò)期之前被濫用，該漏洞被評(píng)為嚴(yán)重級(jí)別，并被分配了CVE-2025-47928。

MITRE和Splunk修正倉(cāng)庫(kù)配置錯(cuò)誤

另一個(gè)值得注意的例子是MITRE CAR(網(wǎng)絡(luò)分析倉(cāng)庫(kù))，它諷刺地托管了一個(gè)分析集合，包括檢測(cè)規(guī)則和邏輯，旨在幫助安全團(tuán)隊(duì)識(shí)別映射到MITRE ATT&CK框架的對(duì)手行為。

這個(gè)倉(cāng)庫(kù)包含一個(gè)類(lèi)似于Spotipy的工作流，它在pull_request_target上觸發(fā)，以從拉取請(qǐng)求中檢出代碼并發(fā)出pip install -r ./scripts/requirements.txt命令。由于requirements.txt文件是檢出代碼的一部分，因此它完全處于潛在攻擊者的控制之下。

“再次，我們成功竊取了默認(rèn)的高特權(quán)GITHUB_TOKEN和其他機(jī)密信息，最終在倉(cāng)庫(kù)內(nèi)獲得了提升的權(quán)限，”Sysdig團(tuán)隊(duì)表示，“在向MITRE報(bào)告該漏洞后，它得到了確認(rèn)并迅速被MITRE團(tuán)隊(duì)修復(fù)?！?/p>

第三個(gè)例子是Splunk的一個(gè)名為security_content的倉(cāng)庫(kù)，它有一個(gè)類(lèi)似的可濫用工作流，在這種情況下，提取的GITHUB_TOKEN僅限于讀取權(quán)限，但研究人員設(shè)法從倉(cāng)庫(kù)中提取了其他憑證，名為APPINSPECTUSERNAME和APPINSPECTPASSWORD，該問(wèn)題在報(bào)告后得到了修復(fù)，但提取的憑證的性質(zhì)和敏感性尚不清楚。

緩解措施

有幾種方法可以緩解這些配置錯(cuò)誤風(fēng)險(xiǎn)，首先，如果可能的話，應(yīng)避免使用pull_request_target，并且在不完全理解其安全影響和風(fēng)險(xiǎn)的情況下不要使用，以這種方式執(zhí)行的工作流不應(yīng)檢出不受信任的代碼。

如果仍然需要特權(quán)工作流，那么應(yīng)首先在不特權(quán)的工作流中執(zhí)行不安全任務(wù)，如檢出和運(yùn)行不安全代碼，然后將驗(yàn)證后的結(jié)果傳遞給特權(quán)工作流，這被稱(chēng)為工作流分割，是GitHub推薦的一種策略。

其次，GITHUB_TOKEN的權(quán)限應(yīng)配置為只讀，正如Splunk倉(cāng)庫(kù)中的情況一樣，這將無(wú)法保護(hù)工作流執(zhí)行過(guò)程中暴露的其他機(jī)密信息，但將防止攻擊者獲得對(duì)主倉(cāng)庫(kù)的寫(xiě)入權(quán)限。

“一種可以考慮的緩解措施是將工作流配置為僅在拉取請(qǐng)求被分配了特定標(biāo)簽時(shí)才運(yùn)行，這實(shí)際上需要具有倉(cāng)庫(kù)寫(xiě)入權(quán)限的維護(hù)者進(jìn)行手動(dòng)審查，”Sysdig研究人員建議道，“由于外部貢獻(xiàn)者無(wú)法分配標(biāo)簽，因此這確保了拉取請(qǐng)求在手動(dòng)審查后才會(huì)觸發(fā)工作流。”