可能出現什麼問題？ CI/CD pipelines?

持續整合和持續交付（CI/CD) pipeline自動化是任何以「現代」方式建立軟體的軟體組織的基石。自動化賦予了軟體強大的功能，但大多數開發人員卻忽略了它所蘊含的責任。

開發者 是的，我們接受 CI/CD 安全 認真對待並對程式碼維護人員進行嚴格管控，進行審查 commit合併前；作業和 pipeline系統由高級職員維護，他們負責防止機密外洩。 pipeline而且這工具是由熟悉這東西的人員安裝的。還能出什麼問題呢？

尊敬的開發者： CI/CD 系統很複雜，其廣泛的攻擊面吸引了惡意行為者。務必保持警惕，切勿過於自信。

預設配置有時會被保留，這反而成了駭客的「好幫手」。其中可能存在嚴重漏洞。 CI/CD pipeline 來源，在系統配置中，或圍繞著過程和上下文 pipeline 以及它是如何被觸發的。

在這篇文章中，我們將設身處地站在反派的角度思考。想像一下，我們正在閱讀……的思考。 M3M3N70 （Memento Mori？） 沼澤狂怒 在暗網的某個地方，可能用的是非西方語言，但永遠不要忘記邪惡正在全球蔓延。

 

在過去的美好時光裡，一切都那麼容易…

M3M3N70：想當年，我們的生意真是太輕鬆了……零日漏洞唾手可得，應用程式漏洞百出，很容易利用，我們可以快速橫向轉移。

沼澤狂怒媽的！雖然還有一些傻瓜在瞎搞，但情況已經改變了。大公司對應用程式安全那一套深信不疑。

M3M3N70沒錯。但新的傻瓜是開發者們。對我們來說，採用他們使用的工具會更容易。尤其是持續整合（CI），簡直是金礦！雲端存取令牌， SCM 憑證、生產資料庫密碼、SSH 私鑰、其他 CI 使用者的憑證…從枯燥的開發工作跳到真正重要的部分相當容易。

自動化軟體的建置、測試與部署 CI/CD 該工具通常需要分步驟地將密鑰傳遞給命令。而這些密鑰經常洩露，造成臭名昭著的後果。

Pipeline需要一些有時會洩漏的秘密

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

或許，美好的舊時光就是在 Git 歷史中尋找… .env 文件（開發者忘記將其添加到） .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

它被用於 GitHub 工作流程中 .github/deploy.yaml 其中包含類似這樣的內容：

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70：哇！那些AWS密鑰居然奏效了！我們先測試了應用程式中一個不起眼的改動，然後趁他們不注意加了點「陷阱」。搞定！真是個成功的行動…

惡意行為者利用洩漏的 AWS 金鑰上傳了一個經過修改並植入惡意軟體的應用程序，然後使用這些憑證運行了部署命令。洩漏的密鑰以及其中包含的資訊… pipeline「多麼精彩的宣傳活動！」這句話可能意味著《記憶片段》為可憐的受害者帶來了巨大的災難。

Memento 在這裡告訴我們，一旦發生秘密洩漏（例如範例中的 AWS 存取金鑰洩漏），就必須撤銷該秘密（輪換上述金鑰）。 立即總會有一個 曝光視窗 洩漏處 commit 以及秘密無效化； 重寫 Git 歷史記錄很難 （即使是最強硬的獨裁國家也曾嘗試過這種篡改歷史的做法，但都徒勞無功），而且可能無效（我們的朋友可能在秘密洩露程式碼庫之前就已經克隆了該程式碼庫）。 commit立即輪換密鑰，並在暴露窗口期內一邊查看目標帳戶的活動日誌一邊祈禱！

或許組織應該 禁止使用長期保密資訊 CI/CD pipelines並將其替換為臨時憑證。在前面使用 GitHub Actions 中的 AWS 金鑰的範例中，使用臨時憑證會更安全。 OpenID Connect (OIDC) 供應商 取得執行操作所需的短期憑證。

沼澤狂怒你真是太幸運了！先前洩漏帶有硬編碼密鑰的腳本是很常見的做法，即使在公開存取的 S3 儲存桶中也是如此。你只需要遍歷儲存桶中的對象，然後用 grep 指令搜尋就能找到有用的資訊。

有時，由於配置缺陷（未被發現），用於部署的區域（本例中為 AWS S3 儲存桶）對外部人員開放讀取權限。 沼澤狂怒 使用的格式大致如下：

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

該儲存桶可能是在配置範本中建立的，因此可以自動掃描其安全漏洞。

這個工具的預設配置對我們來說只是個玩具。

為了舉出具體的例子，我們來談談… 詹金斯是目前最受歡迎的 CI 工具之一。

沼澤狂怒你還記得 Jenkins 裡的「啟用安全」複選框嗎？有多少組織為了方便而選擇不啟用它？還有那些「任何人都能做任何事預設啟用“權限組合”？還有那些煩人的 Jenkins 插件，例如… GitHub OAuth 插件配置該功能的人同時選擇了“授予所有已驗證用戶讀取權限”和“使用 GitHub 儲存庫權限”，這使我們能夠存取他們的所有專案。

（抱歉，詹金斯，拿你舉例子了😉）

始終精通（甚至痴迷）安全原則。其中之一是… 預設安全 原則：控制項的預設設定應盡可能安全。安全性應內建於系統中。 CI/CD 工具和 pipeline從一開始就注重安全性，而不是事後補救。但使用者友善性和便利性往往與安全性相衝突。

就 Jenkins 而言，內建身份驗證過於脆弱： 永遠不要使用 Jenkins 中的內建身份驗證機制。最好選擇第三方機制（SAML、LDAP、Google 等），並搭配基於角色的授權策略（RBAC）外掛程式。同時，務必格外謹慎。 admin 帳戶。

照顧好工作和 pipeline Jenkins 中的檔案會被處理。同樣適用於 配置即程式碼插件 及其配置文件，這些配置文件適用於 Jenkins 配置。

從自架遷移 CI/CD 將系統遷移到基於雲端的SaaS系統消除了一些潛在風險，允許在組織網路內部進行橫向移動，但也帶來了其他風險，例如需要在現有內部系統和外部系統之間建立外部連接。 CI/CD 工具。

組織應努力cis在加固方面應盡到應有的注意義務 CI/CD 系統從最嚴格的設定開始，逐步開放所需的最低權限。 pipeline 腳步。

配置安全性 CI/CD 工具的使用可能非常複雜。許多工具都有插件或擴充程序，而這些插件或擴充功能往往存在許多漏洞，需要定期更新。

針對此類複雜工具的安全性配置錯誤掃描器或基準測試可能會有所幫助。

注入程式碼 pipeline 娛樂和盈利指令

M3M3N70您是否曾經使用過不受信任的程式碼檢出功能？這種功能會引入易受攻擊的操作和腳本，容易受到命令注入攻擊。

本節內容表明 pipeline 本身可能存在編碼錯誤，使惡意行為者能夠注入任意程式碼執行程式。 pipeline 不改變 pipeline 源頭本身例如，使用 PR（公關稿）。

第一個例子 GitHub 工作流程令人遺憾:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

結合 pull_request_target 使用明確檢出不受信任的 PR 來觸發工作流程是一種危險的做法，可能會導致程式碼庫遭到入侵。例如，以下不幸的組合：

• pull_request_target 該事件預設擁有對目標倉庫及其密鑰的寫入權限，即使是來自外部分支的事件也是如此，並且在 PR 的目標倉庫上下文中運行。
• 從不受信任的來源倉庫檢出 PR 程式碼，
• 觸發任何可能對 PR 控制的內容進行操作的腳本，例如在以下情況下： npm install以及
• 未使用觸發條件。 pull_request_target 只有當 PR 被賦予某種「此 PR 已審核」標籤時，該事件才會運作（外部使用者無法為 PR 指派標籤）。

第二個例子採用了不受信任的輸入（來自問題、評論或 pull request作為傳遞給 a 的參數的來源 pipeline 透過表達式執行命令。這是 pipeline 作業系統命令注入漏洞的版本。

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

執行操作會根據範本產生臨時 shell 腳本， $ 替換後，它容易受到 shell 命令注入攻擊。擁有虛假 GitHub 帳戶的攻擊者可以建立一個標題為「已替換」的問題。 a"; bad_code_goes_here;#然後，砰！ 

沼澤狂怒哦，那些傢伙只是提交了一個 issue，就等於為命令注入打開了方便之門…

GitHub Actions 中存在程式碼執行漏洞，例如 gajira-comment已修復。請閱讀 “GitHub 工作流程中的不受信任輸入” 完整的細節。

這個故事的寓意是： 永遠不要在未先審查 PR 的情況下，從不可信的來源檢出並建構 PR。 除非經過嚴格的出處認證，否則這裡的「不受信任」可能意味著任何可能被劫持的開發者帳號。

 

此處意外部署了惡意軟體！

持續部署 這是自動化發展的高潮，但如果缺乏適當的審批控制，這一高潮可能會受阻。 pipeline 流程。

從源端完全自動化部署的風險 commit 對生產系統而言，風險包括惡意程式碼可能被部署到生產環境中而不被偵測到，以及部署過程中的錯誤可能導致中斷或故障。

為了降低這些風險，通常建議組織在其部署過程中實施“硬性終止”，這需要 人類的認可 在版本部署到最終環境之前。

他們正在關門。

沼澤狂怒那些令人愉悅的預設密碼 CI/CD 工具正在被清除。訪問 /var/lib/jenkins/secrets/initialAdminPassword 這條路已經走不通了。現在很多工具都提供雙重認證（2FA），新冠疫情讓這項功能流行起來，就連最懶的程式設計師都在用！

M3M3N70我們正在與雙重驗證作鬥爭，但這並不容易。要對他們進行魚叉式網路釣魚攻擊非常困難，因為 「Scatter Swine」與 Twilio 合作使用 WebAuthn 金鑰就困難得多。至少，我們可以嘗試… 竊取 cookie 以繞過 MFA但需要突破開發者的思維定型。

多因素身份驗證是降低身份驗證金鑰外洩風險的正確方向。大多數現代 DevOps 工具都支援 MFA。 WebAuthn/U2F 下的驗證金鑰（請參閱） FIDO2項目如果管理得當，它們可能是 DevOps 中 MFA 的最佳選擇。

沼澤狂怒DevOps 團隊正在覺醒。他們骨子裡就流淌著「最小權限原則」。他們不再是只會寫程式碼的「代碼猴子」了。現在，我們會被代碼審查員當場抓獲。

事實上， pipeline現在比幾年前更穩健，移除了薄弱的操作和腳本，並增加了額外的安全測試步驟，甚至可以偵測到我們隱藏的投放器。 commit我們劫持的包裹和包裹。

給讀者的問題：從原始碼建置軟體並部署到生產環境的過程是否風險很高？您認為您的 DevOps 處於哪個階段？ 美好的舊時光 給壞人用的？

最終建議

從哪裡開始呢？ CI/CD pipeline是？

第一項建議很簡單：謹慎行事 檢討 pipelines （它們是） 批評 安全審查需要耗費大量資源。審查成本高昂但必不可少，而且必須認真執行。審查人員應清楚審查內容。每個步驟都必須檢查是否有缺陷。

或許，結合專家評審員和自動惡意程式碼掃描器，可以有所幫助。

第二項建議是： 培訓編寫程式碼的開發人員 pipeline並維護它們的安全性需要考慮的事項：

• 如何正確處理內部服務和雲端服務的身份驗證，避免處理長期憑證的麻煩。
• 如何限制 pipeline它只能存取所需的確切資源集。最小權限原則再次發揮作用。
• 如何撰寫製作步驟 pipeline可復現，例如版本鎖定，並避免命令注入漏洞。
• 如何從安全角度批准部署（還有其他方面！）：哪些安全措施 standard應該進行匹配，以及如何在系統中添加相應的檢查/門。 pipelines.

第三項建議是 配置 CI/CD 系統應謹慎使用強大的身份驗證機制，禁用預設密碼和不安全的設置，並限制權限…注意已安裝的插件和擴充功能中的漏洞。這可能是後續文章的重點，敬請關注。

第四項建議是： 利用 CI/CD pipeline用於安全自動化原始碼分析（SAST），來源成分分析（SCA）、金鑰外洩掃描、反惡意軟體工具、容器安全掃描器或自動執行時間偵測器（DAST 和惡意軟體偵測器）可以定期在系統上運作。 pipeline您的組織可能會強制執行。 standard關於安全掃描的覆蓋範圍 CI/CD.

請記住，這些工具並不能取代專家評審，否則您可能會產生一種虛假的安全感。

如果您熟悉 OWASP Top 10，那麼最近一個不錯的專案是… OWASP頂級10 CI/CD 安全風險.

免責聲明

（1）本文的範例皆使用 GitHub 作為 GitHub 平台。 SCM以 AWS 作為雲端供應商，GitHub Actions 或 Jenkins 作為雲端服務商。 CI/CD 工具。它們並不比其他工具更弱/更安全。絕無惡意！這些工具功能強大，需要正確使用。

(2) M3M3N70 以及  沼澤狂怒 均為虛構人物。如有雷同，純屬巧合……或者並非如此？

閱讀更多

• Haymore, A. 等人 “10個真實案例，講述我們如何妥協” CI/CD pipelinesNCC集團，2022年1月。
• configure-aws-credentials GitHub 行動 以及  在 Amazon Web Services 中設定 OpenID Connect 有關如何在 GitHub 工作流程中執行 AWS 命令​​進行部署的詳細信息，請參閱相關文件。
• 洛巴切夫斯基 J. “保護 GitHub Actions 和工作流程安全 第一部分：防止漏洞請求”GitLab 安全實驗室，2020 年 12 月。
• 洛巴切夫斯基 J. “保護 GitHub Actions 和工作流程安全（第二部分）：不受信任的輸入”GitLab 安全實驗室，2021 年 1 月。
• OWASP。 OWASP Top 10 CI/CD 安全風險”2022年7月。
• Saltzer J. 和 Schroeder M. “電腦系統中的資訊保護”1975 年 4 月。安全原則隨著技術的發展而演變，但 47 年後，大多數安全理念仍然有效。
• 英國國家網路安全中心。 確保建置和部署安全 pipeline“英國國家網路安全中心，2019 年 2 月。