何が問題になる可能性があるか CI/CD pipelines?

継続的インテグレーションと継続的デリバリー（CI/CD) pipeline自動化は、現代的な方法でソフトウェアを開発するあらゆるソフトウェア組織の基盤となります。自動化は大きな力をもたらしますが、ほとんどの開発者はそれに伴う責任を見落としています。

Developer: ええ、私たちは CI/CD セキュリティ 真剣に取り組んで、コードメンテナーを厳しく管理し、レビューします。 commit合併前のs; ジョブと pipelineは上級スタッフによって管理されており、機密情報が漏洩しないように注意しています。 pipelineそれに、そのツールは専門知識を持った担当者によってインストールされた。何が問題になるだろうか？

開発者の皆様へ CI/CD システムは複雑です。その広範な攻撃対象領域は悪意のある攻撃者を引きつけます。用心深く、決して過信しないようにしましょう。

デフォルト設定はそのまま残され、ハッカーにとって最高の味方となることがあります。重大な欠陥が存在する可能性があります。 CI/CD pipeline システムの構成、またはプロセスとコンテキストに関するソース pipeline そして、それがどのように引き起こされるのか。

この記事では、悪役の立場になって考えてみましょう。 M3M3N70 （メメント・モリ？）そして 沼地の怒り ダークウェブのどこか、おそらく非西洋の言語で書かれているだろうが、悪は世界中に広がっているということを決して忘れてはならない。

 

古き良き時代は、とても簡単だったのに…。

M3M3N70: 古き良き時代に戻りましょう。私たちのビジネスはとても簡単でした...ゼロデイは簡単に手に入り、アプリは簡単に悪用できる脆弱性が満載で、私たちは瞬時に横方向に移動できました。

沼地の怒り: ちくしょう！まだ頭のおかしい奴もいるけど、状況は変わった。大企業はAppSecのくだらないものにかなり疑念を抱いている。

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ツールの1つ。

沼地の怒り: 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 ソース自体例えば、プルリクエストを使用する

最初の例として 残念な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 信頼できないプルリクエストを明示的にチェックアウトするワークフローのトリガーは、リポジトリの侵害につながる可能性のある危険な行為です。この例では、以下の不幸な組み合わせが発生しています。

• pull_request_target イベントは、デフォルトでは外部フォークからでもターゲットリポジトリとターゲットリポジトリのシークレットへの書き込み権限を持ち、PR のターゲットリポジトリのコンテキストで実行されます。
• ソースから PR コードをチェックアウトします、信頼されていないリポジトリ、
• PR管理コンテンツに対して動作する可能性のあるスクリプトをトリガーします。 npm install,
• トリガーに条件を使用しない pull_request_target このイベントは、PRに「このPRは審査済みです」といったラベルが割り当てられた場合にのみ実行されます（外部ユーザーはPRにラベルを割り当てることはできません）。

2 番目の例では、信頼できない入力 (問題、コメント、または pull request) に渡される引数のソースとして pipeline 式によるコマンド。これは pipeline OSコマンドインジェクション脆弱性のバージョン。

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

実行操作では、テンプレートに基づいて一時的なシェルスクリプトが生成されます。 $ 置換されているため、シェルコマンドインジェクションに対して脆弱です。偽のGitHubアカウントを持つ攻撃者は、タイトルが a"; bad_code_goes_here;#そして、ドーン！ 

沼地の怒りああ、あの人たちは単に問題を提起しただけで、コマンドインジェクションの扉を開いてしまったんだ…

GitHub Actionsには、次のようなコード実行の脆弱性がありました。 ガジラコメント修正済みです。お読みください。 「GitHubワークフローにおける信頼できない入力」 完全な詳細については。

この話の教訓： 信頼できないソースからのプルリクエストは、必ず事前にレビューせずにチェックアウトしてビルドしないでください。 ここでいう「信頼できない」とは、厳格な出所認証が行われていない限り、乗っ取られる可能性のある開発者アカウントすべてを指す可能性がある。

 

意図しないマルウェアの展開が発生しました！

継続的な展開 は自動化のクライマックスだが、適切な承認管理がないためにそのクライマックスは阻害される可能性がある。 pipeline フロー。

ソースからの完全自動化されたデプロイメントのリスク commit 本番システムへの脅威には、悪意のあるコードが検出されずに本番環境に展開される可能性や、展開プロセスにおけるエラーによって混乱や停止が発生する可能性などが含まれます。

これらのリスクを軽減するために、組織は展開プロセスに「ハードブレーク」を導入することが推奨されることが多い。 人間の承認 リリースが最終環境に展開される前に。

彼らはドアを閉めている

沼地の怒り: 楽しいデフォルトパスワード CI/CD ツールが消去されています。 /var/lib/jenkins/secrets/initialAdminPassword もはや時代遅れの手法だ。多くのツールが2段階認証（2FA）を提供しており、これはコロナ禍で普及した。そして、最も怠惰なプログラマーでさえもそれを利用しているのだ！

M3M3N70: 2FAと戦っていますが、そう簡単ではありません。彼らをスピアフィッシングするのは難しいです。 「Scatter Swine」はTwilioと共同でWebAuthnキーでは、はるかに困難です。少なくとも、 MFAを回避するためにクッキーを盗むしかし、開発者の領域に侵入する必要がある。

多要素認証は、認証情報の漏洩リスクを軽減するための正しい方向への一歩です。最新のDevOpsツールのほとんどはMFAをサポートしています。また、WebAuthn / U2Fによる認証キーもサポートしています（参照）。 FIDO2プロジェクト適切に管理されていれば、これらはDevOpsにおけるMFAの最良の選択肢となる可能性がある。

沼地の怒りDevOpsの連中が目覚めた。彼らの血には「最小権限」の原則が染み付いている。そして彼らはもはや単なるコードモンキーではない。今ではレビュー担当者に現行犯で捕まる始末だ。

実際には、 pipelineは数年前よりも少し堅牢になり、脆弱なアクションやスクリプトが削除され、ステルスで隠されたドロッパーさえも検出する追加のセキュリティテスト手順が追加されました。 commit私たちが乗っ取ったsとパッケージ。

読者への質問：ソースからソフトウェアを構築し、本番環境にデプロイするプロセスはリスクの高いビジネスでしょうか？DevOps を次の段階に位置づけることができますか？ 古き良き時代 悪者のために？

最終的な提言

どこから始めればいいのか CI/CD pipelines？

最初の推奨事項はシンプルです。慎重に レビュー pipelines （彼らです 重大な セキュリティ上の問題に対処するため、リソースを投入してレビューを実施する必要があります。レビューは費用がかかりますが、必要不可欠であり、適切に実施しなければなりません。レビュー担当者は、何に着目すべきかを認識しておく必要があります。各ステップは、欠陥がないか確認する必要があります。

自動化された悪意のあるコードスキャナーを備えた専門家によるレビューを組み合わせることで、状況が改善されるかもしれない。

2つ目の推奨事項は 開発者を育成し、 pipelines およびセキュリティを維持します考慮すべき事項：

• 内部サービスとクラウドサービスにおける認証を適切に処理し、長期的な認証情報の管理に伴う煩わしさを回避する方法。
• 制限する方法 pipeline必要なリソースにのみアクセスできるようにする。最小権限の原則がここでも活きてくる。
• 作成手順の書き方 pipelineバージョン固定のような再現性を確保し、コマンドインジェクションの脆弱性を回避する。
• セキュリティの観点からデプロイメントを承認する方法（他にもあります！）：どのセキュリティ standards は一致させる必要があり、対応するチェック/ゲートを追加する方法 pipelines.

3つ目の推奨事項は 構成する CI/CD 適切な注意を払ってシステム強力な認証、デフォルトパスワードや安全でない設定の排除、最小限の権限設定… インストールされているプラ​​グインや拡張機能の脆弱性にも注意してください。今後の記事では、これらの点に焦点を当てていく予定ですので、ご期待ください。

4つ目の推奨事項は 活用する CI/CD pipelineセキュリティ自動化のためのソースコード分析（SAST）、ソース組成分析（SCA) 機密情報漏洩スキャン、マルウェア対策ツール、コンテナセキュリティスキャナー、または自動ランタイム検出ツール (DAST およびマルウェア) を定期的に実行できます。 pipeline組織は、 standardセキュリティスキャンに関する報道について CI/CD.

ただし、これらのツールは専門家によるレビューを不要にするものではないことを覚えておいてください。そうでなければ、誤った安心感を抱いてしまう可能性があります。

OWASPトップ10に精通しているなら、最近の良いプロジェクトは OWASPトップ10 CI/CD セキュリティリスク.

免責事項

（１）この記事の例ではGitHubを使用しています SCMAWSをクラウドプロバイダーとして、GitHub ActionsまたはJenkinsを CI/CD これらはツールです。他の代替手段と比べて、性能が劣る、あるいは安全性が低いということはありません。悪意は一切ありません！これらのツールは強力なので、適切に使用する必要があります。

(2) M3M3N70 (NAIST) と 沼地の怒り これらは架空のキャラクターです。実在の人物や団体（存命・故人を問わず）との類似点は、単なる偶然です…それともそうではないのでしょうか？

もっと読むには

• Haymore, A. 他 「私たちが妥協してきた10の実話」 CI/CD pipelines」NCCグループ、2022年1月。
• configure-aws-credentials GitHubアクション (NAIST) と Amazon Web Services での OpenID Connect の設定 GitHubワークフローでデプロイするためのAWSコマンドの実行方法の詳細については、こちらをご覧ください。
• ロバチェフスキー J. 「GitHub Actionsとワークフローのセキュリティを維持する パート1：pwnリクエストの防止」GitLab Security Lab、2020年12月。
• ロバチェフスキー J. 「GitHub Actionsとワークフローのセキュリティを維持する パート2：信頼できない入力」GitLab Security Lab、2021年1月。
• OWASP。 「OWASPトップ10」 CI/CD セキュリティリスク””2022年7月
• Saltzer J. & Schroeder M. 「コンピュータシステムにおける情報の保護」1975年4月。セキュリティの原則は技術の進歩とともに進化してきたが、47年経った今でも、セキュリティとセキュリティに関する考え方のほとんどは有効である。
• 英国NCSC 「構築と展開を安全に行う」 pipeline　英国国家サイバーセキュリティセンター、2019年2月。