無人批准的分叉工作流程Lint / quick-checks / linux-job,卻在pull_request時被自動觸發,代表該流程使用預設批准配置。(圖片來源/John Stawinski)

資安研究人員揭露一個攻擊PyTorch軟體供應鏈的新手法,透過入侵PyTorch的CI/CD工作管線,攻擊者可以向主儲存庫分支添加程式碼,上傳惡意的PyTorch版本到GitHub,還能在PyTorch的相依項目植入後門,進而影響PyTorch及其相依項目整個生態系。

這個PyTorch供應鏈攻擊,基於一個早前發現,可用於操縱GitHub Actions的CI/CD流程的漏洞CVE-2023-49291,攻擊者透過分叉拉取請求,成為有附加自託管執行器(Self-Hosted Runners)的儲存庫的貢獻者。自託管執行器(Self-Hosted Runners)是GitHub Actions的一個功能,讓用戶可以在自己的基礎設施上執行GitHub Actions工作流程,像是運作在用戶的伺服器、虛擬機器和容器上。

攻擊者使用名為Gato的GitHub攻擊工具,來辨識PyTorch儲存庫中的自託管執行器,Gato藉由檢查GitHub工作流程檔案和運作日誌,成功辨識出多個持續運作的自託管執行器,像是worker-rocm-amd-30(下圖)。

圖片來源_John Stawinski

接下來,資安人員分析PyTorch的拉取請求,發現過去貢獻者提交過的拉取請求,能夠觸發pull_request工作流程,且無需額外批准。這代表儲存庫未對先前貢獻者的分叉拉取請求設置工作流程批准要求。資安研究人員還在PyTorch工作流程檔案中發現許多GitHub機密,包括存取金鑰和GitHub個人存取權杖(PAT),而這些權杖在攻擊者入侵供應鏈時非常有用。

另外,研究人員還進一步探討自託管執行器的後期利用潛力,尋找從執行器擷取秘密資訊的策略。在分析PyTorch這個案例,研究人員不僅成功辨識出自託管執行器,還能夠利用這些自託管器獲取敏感資訊。

研究人員評估PyTorch團隊處理自託管執行器安全性問題的表現,並指出PyTorch團隊對安全問題的回應時間很長,且修復措施令人質疑,此外,這已經不是PyTorch首次遇到自託管執行器的安全挑戰,之前也曾遭遇類似的攻擊。

對於這類的安全漏洞,研究人員提到,安全有效的方法是更改GitHub預設配置,要求所有外部合作者的分叉拉取請求都要進行批准,對於需要使用自託管執行器的組織,應當使用隔離且一次性的執行器。不過這個問題也非PyTorch獨有,組織在公開儲存庫中使用自託管執行器,都需要更加謹慎小心,採取更嚴格的安全措施。

熱門新聞

Advertisement