![]()
GitHub Actions的一個(gè)配置失誤,讓全球最流行的開源漏洞掃描器變成了攻擊者的后門。攻擊者沒有新建惡意版本,而是直接修改了76個(gè)已有版本標(biāo)簽——這意味著那些沒鎖定代碼哈希的企業(yè),已經(jīng)在不知情的情況下運(yùn)行了數(shù)周惡意代碼。
攻擊時(shí)間線:一次" Incomplete "的修復(fù)如何釀成大禍
事件始于2025年2月底。攻擊者利用Trivy的GitHub Actions環(huán)境配置錯(cuò)誤,竊取了一個(gè)高權(quán)限訪問令牌。3月1日,Aqua Security團(tuán)隊(duì)披露事件并執(zhí)行了憑證輪換,但關(guān)鍵漏洞被遺漏——部分憑證仍然有效,攻擊者并未被真正驅(qū)逐。
18天的靜默期后,3月19日,攻擊者發(fā)起第二階段行動(dòng)。他們向aquasecurity/trivy-action倉庫的76個(gè)版本標(biāo)簽強(qiáng)制推送惡意提交,同時(shí)污染了aquasecurity/setup-trivy的全部7個(gè)標(biāo)簽。更隱蔽的是,一個(gè)被入侵的服務(wù)賬戶觸發(fā)了自動(dòng)化發(fā)布流程,將植入后門的Trivy二進(jìn)制文件標(biāo)記為0.69.4版本正式發(fā)布。
攻擊者的核心策略是"寄生"而非"新建"——篡改現(xiàn)有標(biāo)簽比發(fā)布可疑的新版本更難被發(fā)現(xiàn)。惡意代碼被設(shè)計(jì)成在合法Trivy掃描邏輯之前執(zhí)行,CI/CD工作流看似正常運(yùn)行,實(shí)則已在后臺(tái)完成數(shù)據(jù)竊取。
竊密范圍:CI/CD管道成了"憑證收割機(jī)"
惡意載荷在靜默執(zhí)行期間,系統(tǒng)性地收集CI/CD環(huán)境中的敏感信息。目標(biāo)清單包括:API令牌、AWS/GCP/Azure三大云平臺(tái)的憑證、SSH密鑰、Kubernetes令牌以及Docker配置文件。竊取的數(shù)據(jù)被實(shí)時(shí)外傳到攻擊者控制的基礎(chǔ)設(shè)施。
這次攻擊精準(zhǔn)打擊了開源生態(tài)的一個(gè)普遍陋習(xí)——依賴可變版本標(biāo)簽(如v0.69.4)而非固定提交哈希(commit hash)。Aqua Security確認(rèn),其商業(yè)產(chǎn)品因架構(gòu)隔離未受影響:專用管道、嚴(yán)格訪問控制、滯后于開源發(fā)布的受控集成流程,構(gòu)成了三道防線。
3月21日至22日的周末,調(diào)查發(fā)現(xiàn)了更多可疑活動(dòng)。攻擊者仍在嘗試重新建立訪問,表明這是一場(chǎng)持續(xù)進(jìn)行的戰(zhàn)役,而非一次性入侵。Aqua Security已與全球事件響應(yīng)公司Sygnia合作,從初步遏制轉(zhuǎn)向主動(dòng)修復(fù)。
辯論:開源安全工具的信任危機(jī),誰該背鍋?
正方觀點(diǎn):Aqua Security的披露和響應(yīng)足夠及時(shí)
支持者認(rèn)為,在復(fù)雜的供應(yīng)鏈攻擊中,3月1日的初步響應(yīng)符合行業(yè)標(biāo)準(zhǔn)。憑證輪換是標(biāo)準(zhǔn)操作,殘留訪問的發(fā)現(xiàn)往往需要時(shí)間驗(yàn)證。Aqua Security在確認(rèn)二次入侵后48小時(shí)內(nèi)就完成了惡意版本的全面下架,覆蓋GitHub Releases、Docker Hub和Amazon ECR三大分發(fā)渠道。
更關(guān)鍵的是,商業(yè)產(chǎn)品與開源項(xiàng)目的架構(gòu)隔離被證明有效——這種"雞蛋不放一個(gè)籃子"的設(shè)計(jì),恰恰是負(fù)責(zé)任的安全實(shí)踐。團(tuán)隊(duì)正在推進(jìn)的不可變發(fā)布驗(yàn)證(immutable release verification)和長(zhǎng)期令牌淘汰,屬于結(jié)構(gòu)性改進(jìn)而非臨時(shí)補(bǔ)丁。
反方觀點(diǎn):"Incomplete remediation"暴露了流程缺陷
批評(píng)者抓住3月1日的修復(fù)失敗不放。18天的窗口期讓攻擊者從容升級(jí)戰(zhàn)術(shù),從"潛伏"轉(zhuǎn)向"大規(guī)模污染"。如果初次響應(yīng)執(zhí)行了更徹底的憑證審計(jì),76個(gè)標(biāo)簽的篡改本可避免。
更深層的質(zhì)疑指向開源項(xiàng)目的安全投入。Trivy作為被數(shù)百萬CI/CD管道依賴的基礎(chǔ)設(shè)施,其GitHub Actions環(huán)境的配置審核顯然不足。攻擊者利用的是基礎(chǔ)性的配置錯(cuò)誤,而非什么高級(jí)零日漏洞——這種"低級(jí)錯(cuò)誤"在關(guān)鍵安全工具中出現(xiàn),本身就值得反思。
我的判斷:這是一次"典型"的供應(yīng)鏈攻擊,典型到令人不安
雙方都有理,但也都回避了真正棘手的問題。正方夸大了架構(gòu)隔離的普適性——大多數(shù)使用Trivy的企業(yè)沒有商業(yè)版作為備份;反方則低估了供應(yīng)鏈攻擊的固有難度,殘留訪問的排查在大型代碼庫中從來不是 trivial 的事(瑣碎的事)。
真正值得關(guān)注的,是攻擊者選擇的戰(zhàn)術(shù)模式。他們不搞花哨的零日漏洞,而是精準(zhǔn)利用開源生態(tài)的"默認(rèn)不安全":可變標(biāo)簽的便利性、CI/CD環(huán)境的憑證密集性、安全工具本身的信任溢價(jià)。這種"低成本、高杠桿"的攻擊思路,正在被更多威脅行為者復(fù)制。
Aqua Security的修復(fù)清單包括全面憑證吊銷、淘汰長(zhǎng)期令牌、實(shí)施不可變發(fā)布驗(yàn)證。但這些措施解決的是"這次怎么被打的",而非"下次怎么防別的"。當(dāng)安全工具本身成為攻擊面,整個(gè)行業(yè)需要重新思考開源基礎(chǔ)設(shè)施的信任模型——不是要不要用,而是如何在不信任的前提下安全地使用。
截至3月25日,調(diào)查仍在進(jìn)行中。攻擊者仍在嘗試重新進(jìn)入系統(tǒng),而數(shù)百萬開發(fā)者的CI/CD管道日志里,可能還躺著未被發(fā)現(xiàn)的異常。
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺(tái)“網(wǎng)易號(hào)”用戶上傳并發(fā)布,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.