持續整合和持續部署（CI/CD) pipelines 在促進精簡的軟體開發方面發揮關鍵作用。然而，正如這些 pipeline隨著網路安全情勢日益嚴峻，保護網路安全免受漏洞侵害的必要性也愈發凸顯。本次深入調查著重探討OWASP十大漏洞中辨識出的一個突出風險。 CI/CD 安全風險：中毒 Pipeline 執行（PPE）。
什麼中毒了？ Pipeline 執行（PPE）
根據 OWASP Top-10 CI/CD 安全風險，“中毒 Pipeline 執行 (PPE風險是指攻擊者在能夠存取原始碼控制系統但無法存取建置環境的情況下，實施攻擊的能力。 透過向建置過程中註入惡意程式碼/命令來操縱建置過程。 pipeline 組態， 本質上 “投毒” pipeline 並在建置過程中運行惡意程式碼”
簡而言之，中毒了 Pipeline 執行（PPE）產生於 攻擊者可以修改 pipeline 邏輯.
那裡有兩個 變種:
- 直接個人防護裝備 (D-PPE在D-PPE場景中， 攻擊者修改了 CI 配置文件 在他們有權存取的儲存庫中，可以透過兩種方式進行更改：一是將變更直接推送到儲存庫中不受保護的遠端分支；二是提交包含來自分支或派生分支的變更的 PR。 自CI以來 pipeline 執行過程由修改後的 CI 設定檔中的命令定義，攻擊者的惡意命令最終會在建置完成後在建置節點上執行。 pipeline 被觸發。
- 間接個人防護裝備 (個人防護裝備在某些情況下，即使擁有存取權限，對手也無法使用 D-PPE。 SCM 儲存庫（例如，如果 pipeline 配置為從同一儲存庫中單獨的受保護分支拉取 CI 設定檔）。 在這種情況下，與其毒害… pipeline 攻擊者本身會將惡意程式碼注入到被引用的檔案中。 pipeline （例如：從內部引用的腳本） pipeline 設定檔）
在這兩種情況下 GitHub 將執行修改後的操作。 pipeline 無需事先審查或批准.
早期發現個人防護裝備
我們如何偵測這類漏洞？
我們來看這個例子 pipeline :
以下是一個虛擬 shell 腳本 (runtests.sh) 的內容：
这 pipeline 很簡單：它的目的是為審稿者提供一些初步的提示。 Pull Request （公關）接受流程：
- 它將被觸發 拉取請求 （例如，每當建立一個 PR 時）
- 它會檢查 PR 程式碼（即貢獻的程式碼）。
- 它將完成建造
- 它將對貢獻的程式碼執行測試（例如，透過執行 shell 腳本）。
步驟 3（建置）和步驟 4（執行測試）會在程式碼無法編譯或測試失敗時執行。因此，這些步驟是接受 PR 的必要條件，但並非充分條件。如果成功，倉庫管理員將繼續審查貢獻的代碼，並根據審查結果接受、拒絕或評論該 PR。
Xygeni掃描儀
Xygeni 提供 CLI（“Xygeni掃描儀”）可以嵌入到 pipeline 或在命令列中運行。 Xygeni 掃描器將處理 pipelines 用於檢查漏洞，如果提供了 GitHub PAT，它將連接到 GitHub 以發現 org/repo 層級的漏洞。
Xygeni庫存
當我們對這個倉庫運行 Xygeni Scanner 時，它發現了一組有用的資源（ Xygeni庫存庫存中將包含許多不同類型的物品。 CI/CD 資產，如：
- 这 SCM 系統 倉庫儲存位置
- 这 SCM 插件 已安裝/已使用
- 这 代碼庫 本身
- 这 SCM 文章結構 倉庫所屬位置
- 这 CI/CD Pipelines 和工作
- 这 CI/CD 系統 運行 pipelines
- IaC 資源 已在倉庫中定義
- 外部 依賴
- 等等..
在我們的範例中，我們可以按某些特定資產類型篩選庫存（SCM以及 CICD 相關資產），因此我們可以看到：
- SCM 系統是 GitHub Cloud
- 程式碼庫儲存在 GitHub 雲端，並屬於特定的 GitHub 組織。
- 那裡有兩個 pipeline由 GitHub 提供支援 (CI/CD 系統）
- 祇限 pipeline 包含一個特定步驟
透過選擇以上選項 pipeline 我們可以看到一些漏洞：
- At pipeline 處於同一水平，它容易受到兩種因素的影響 直接 以及 間接個人防護裝備。
我們可以看到那些中毒者的詳細資料。 Pipeline 執行漏洞
Xygeni檢測到它是 易受D-PPE影響 因為它是由…觸發的 Pull Request 事件發生後，由於沒有額外的安全控制措施，任何倉庫使用者都可以修改該事件。 pipeline 這些修改將未經任何審查或批准就執行。
同樣地，Xygeni 也檢測到了這一點。 易受 I-PPE 影響 因為呼叫了 shell 腳本 pipeline任何倉庫使用者都可以修改 shell 腳本，這些修改無需任何審查或批准即可執行。
你想知道更多嗎？
利用個人防護裝備
為了充分利用個人防護裝備，我們考慮這樣一種情況： 兩種類型的倉庫用戶:
- An 內部用戶 （一位參與該程式碼庫開發的內部開發人員），擁有該程式碼庫的寫入權限
- An 外部用戶 （外包開發人員正在該倉庫上工作，但擁有倉庫的讀取權限），即不允許創建倉庫分支，只能在 fork 上工作。
假設他們都是惡意攻擊者（或被惡意行為者冒充）。程式碼庫中包含一些秘密訊息，而且他們都想獲取這些資訊。 竊取程式碼庫金鑰 並將其發送到黑客控制的伺服器。為此，他們將利用中毒攻擊。 Pipeline 執行漏洞 pipeline.
無論哪種情況（外部用戶和內部用戶），他們都會打開一個 Pull Request 修改內容相同：
- 这 pipeline shell腳本被修改 至 閱讀秘密 來自環境和 將其發送到黑客控制的伺服器
修改內容可能如下：
兩個用戶都將創建一個 Pull Request 經過修改建立 PR 後， GitHub 將執行這兩項修改。 （無需事先審核或批准）結果如下：
讀寫用戶也一樣。 兩種情況下均執行D-PPE和I-PPE。差別在於… 讀取用戶無法存取密鑰。 （！！！！）
原因如下： 如果 PR 來自 fork，GitHub 不允許存取倉庫金鑰。 雖然讀取使用者無法讀取金鑰，但他/她仍然可以運行任何其他程式。一個典型的攻擊範例是建立下載加密貨幣挖礦程式的 PR，這樣 GitHub 運行器在執行被投毒的 PR 時就會執行該挖礦程式。 pipeline.
這當然不是一個安全的環境！ 倉庫管理員可以採取哪些措施來避免這種情況？
經過一番谷歌搜索，倉庫管理員決定修改 pipeline 將在以下情況下觸發 pull_request_target 事件。為什麼？因為 pipelines 在 pull_request_target 上觸發，不允許執行 pipeline 修改也就是說，儘管用戶進行了任何修改，“原始” pipeline 將被執行。
按照我們的例子，攻擊方式將與之前相同。接下來會發生什麼事？ pipeline 修改？
正如預期的那樣， D-PPE未執行 但是，由於 I-PPE 仍然存在， 讀取用戶現在可以存取倉庫密鑰了！ ！ ！
為什麼讀取用戶現在能夠存取機密資訊？儘管 pipeline 雖然無法修改，但仍可以修改 shell 腳本。 當 pipeline 如果在 pull_request_target 上觸發，它將以特權模式執行。 so 它還將是 shell 腳本導致 shell 腳本能夠存取倉庫機密資訊！
預防措施
GitHub 提供了一些措施來防止惡意 PR。
分支保護規則
使用 GitHub，您可以為選定的分支定義分支保護規則。
對於受保護的分支機構，您可以指定一項策略，該策略 需要一個 pull request 合併之前 （以及其他條件，例如所需的審批數量、代碼所有者的審查等。）
以下幾個條件值得特別注意：
- “不"允許指定參與者繞過所需步驟 pull requests“。
- “不"請勿允許繞過上述設置“
雖然大多數條件都加強了政策的嚴格性，但這些條件卻放鬆了政策，這可能會為惡意活動敞開大門，例如，如果憑證被「特權」行為者竊取。
限制 GITHUB_TOKEN 權限（最小權限原則）
將 GitHub 令牌權限限制為必要的權限；這樣，即使攻擊者成功攻破了您的帳戶，您的帳戶也無法被完全控制。 pipeline他們恐怕也做不了什麼。
透過使用以下方式避免字串插值 pipeline 環境變數
無論何時，當你使用一些輸入變數時 pipeline請注意，預設應將它們視為「不受信任」的資料（其內容由最終使用者控制）。 不受信任的操作和工作流程安全 以及 學習 GitHub Actions。
在腳本中插入輸入變數時，應始終使用環境變量，而不是使用字串插值。
工作流程運作和審批要求
對於 公眾 倉庫，GitHub 允許指定 如何處理“外部”PR.
GitHub 組織設定（「組織 >> 設定 >> 操作 >> 常規」）可指定如何管理外部 PR：
預設情況下，GitHub 會要求首次貢獻者提交 PR 前獲得批准，這使得惡意請求攻擊更加複雜。即便如此，攻擊者仍然可能透過提交一些看似無害的內容來贏得專案維護者的信任。 pull request 在真正的襲擊發生之前。
從這個意義上說， 第三種選擇（要求所有外部合作者獲得批准）增加了更高程度的控制。
對於 私立 對於倉庫，GitHub 還提供了組織層級和倉庫層級的實用控制。
“不"從以下位置運行工作流程 Pull Requests」（預設未選取）允許使用者從 fork PR 執行工作流程（使用具有唯讀權限且無權存取金鑰的 GITHUB_TOKEN）。選取此選項並與最後一個選項（“需要對分支 PR 工作流程進行審批這樣，你就可以實現與私有倉庫類似的策略（如上圖）。
正如我們在從讀取用戶角度利用 PPE 漏洞所看到的那樣， 允許從 fork 運行工作流程 pull requests 不安全！ ！
剩餘選項（“從 fork 向工作流程發送寫入令牌 pull requests“和”從 for 向工作流程發送密鑰和變量 pull requests“） 降低安全級別 適用於分支 PR。
您可以在組織層級或程式碼倉庫層級定義此 fork 策略。如果該策略在組織層級被停用，則無法在程式碼倉庫層級啟用。但是，如果該策略在組織層級啟用，則可以在程式碼倉庫層級停用。
概括
我們希望您已經意識到擁有某些東西的後果。 pipeline 易受中毒影響 Pipeline 執行。這太容易了。 commit 脆弱的 pipeline而且，要寫一個安全的程式並不容易。
因此，使用 Xygeni 掃描器來了解此類漏洞是非常有價值的。
如果你不知道漏洞的存在，就無法解決它！
但是……還有一個懸而未決的問題…… 如何避免使用個人防護裝備？
這將是我們下一篇文章的主題🙂… 間接中毒 Pipeline 執行（I-PPE） !!
