Argo CDのゼロデイ脆弱性（CVE-2022-24348）から学んだ教訓
2022年2月10日
0 分で読めます脆弱性に関する最新情報
新たに重大度の高い脆弱性 CVE-2022-1025 が公開されました。この問題の解決にも推奨されるバージョン番号に、こちらの推奨内容を更新しました。
2022年1月30日、Argo CDチームは、人気の継続的デリバリープラットフォームにおいて、攻撃者がデプロイメントから機密情報を窃取できる可能性のある脆弱性を発見したと、Apiiroの研究者から連絡を受けました。Argo CDチームは、現在サポート対象となっている3つのリリースすべてに対する修正を迅速に開発し、48時間以内にユーザーへ公開しました。CodeFreshの共同創業者であり、ArgoプロジェクトのメンテナーでもあるDan Garfieldは、このCVEに関するブログ記事で、迅速な対応が実現したのは、過去18か月にわたってプロジェクト全体でセキュリティを重視してきたためだと述べています。
この記事では、脆弱性の内容と、この脆弱性によって引き起こされる可能性があったサプライチェーン攻撃から自らを守るための、より広い視点での対策について解説します。
Argo CDの脆弱性とは？
CVE-2022-24348は、攻撃者が悪意を持って細工したHelmチャートを使い、他のアプリケーションに属するデータへアクセスできるディレクトリ／パストラバーサルの脆弱性です。これにより、権限昇格や、Argo CDが稼働するKubernetesクラスターへの攻撃拡大につながる可能性があります。
自分たちが脆弱かどうかを確認するには？
Argo CD 0.5.0から2.1.12、2.2.7、または2.3.1を使用している場合は脆弱性の影響を受けるため、直ちに最新バージョンへアップグレードしてください。2022年3月24日時点の最新バージョンは以下のとおりです。
2.3.2
2.2.8
2.1.14
どのようなリスクがある？
これは、攻撃者がソフトウェアのリリース後に正面から攻撃するのではなく、開発中に侵入を試みる、増え続けるサプライチェーン攻撃の新たな事例です。最近の事例としては、CodeCov、iOS App Store、そして最も有名なSolarWindsへの攻撃があります。今回のインシデントでは、攻撃者が脆弱性を悪用する悪意のあるHelmチャートを作成し、Argo CDのreposerver内にある他のアプリケーションの機密データへアクセスできる可能性がありました。
この脆弱性の具体的な仕組みは、元のCVEの開示情報に記載されているため、ここでは詳しく繰り返しません。簡単に言うと、特定の予測可能な絶対ファイルパスを含むURIをHelmチャートに仕込むことで、攻撃者はArgo reposerver内のそのパスから、他のアプリケーションやユーザーのスコープに属するデータも含め、機密性の高いファイルシステムのデータを外部へ持ち出せる可能性があります。
修正方法は？
クラスターのCVE-2022-24348を修正する方法を探している方は、簡単です。ここで読むのをやめて、Argo CDのデプロイメントを直ちにアップグレードしてください！その後、より大きな視点で考えるために、この記事に戻ってきてください。
対応できましたか？それでは、ソフトウェアサプライチェーンセキュリティをめぐる、より大きな課題について考えていきましょう。
サプライチェーン攻撃の軽減策
今回のような次のゼロデイから、どうすれば自分たちを守れるでしょうか？この脆弱性はArgo CDアプリケーションに固有のものなので、簡単で汎用的な答えはありません。しかし、悪意のある細工が施されたファイル（今回の場合はHelmチャート）がそもそもシステムに入り込まないようにするために、より上位のレベルで実践できる対策がいくつかあります。
1. 小さく、レビューしやすいコミットを心がける
小さく反復的な変更を行うアジャイルの実践は、健全な開発手法として有効なだけでなく、変更が提出された際に、安全でない、または疑わしい変更を見つけやすくします。あなたの組織の誰かがStackOverflowから怪しいコードをコピー＆ペーストするとは言いませんが、1000行のコミットに埋もれていなければ、コードレビューで見つけるのはずっと簡単です。
2. SDLCのシステムはすべて本番環境と同じように扱う
ビルドサーバー、特に自作のものを、おもちゃのように扱ってしまう人は少なくありません。ネットワーク機器室の余ったデスクトップで稼働し、よく知られた管理者パスワードが設定され、外部サービスへの接続にランダムな開発者の認証情報を使うプラグインが何百も入ったJenkins、GitLab、RunDeckのサーバーのことです。そう、あれです！（特定のプロジェクトを責めているわけではありません。管理が不十分なツールなら、どれも攻撃者にとって格好の標的になります。）
これまで、ビルドサーバーやデプロイサーバーは優先度が低いものと見なされ、攻撃への備えも十分ではありませんでした。たとえばSolarWindsやCodeCovへの攻撃は、これらのシステムもユーザーデータを保管する本番サーバーと同じくらい真剣に扱う必要があることを示しています。
共有認証情報を使わない。
検証されていない独自のプラグイン、アクション、モジュールを使わない。
アクセスを適切に制限するため、適切な一元管理型RBACを必ず利用する。
3. サプライチェーンを把握する
システムがビルドする成果物の出所と、その中身を把握することは極めて重要です。安全なサプライチェーンの実現は、何冊もの本にできるほど大きなテーマです。実際、このテーマだけを扱うカンファレンスも数多く開催されています。特に注意すべき主な領域をいくつかご紹介します。
自分たちで管理していないソースから取得したコンテナイメージ、OSパッケージ、コードライブラリ、そしてHelmチャートを、無条件に信頼してはいけません。検証済みで署名された成果物を保管するプライベートな管理対象リポジトリは、アプリケーションの依存関係を信頼できる状態に保つうえで欠かせません。このシナリオでうまく機能している一般的な方法は、新たに取得した成果物をチームが「隔離」リポジトリにインポートし、セキュリティ面と機能面のテストで検証することです。その後、開発者やビルドシステムが通常アクセスできるリポジトリへ移します。もちろん、この検証はチームが迅速に動く必要性とのバランスを取る必要があります。そのため、業務の状況に合わせてガードレールとしてプロセスを設計しましょう。また、成果物の脆弱性スキャンも必要です。可能な限りIaC構成ファイルも対象に含めてください。新たな脆弱性が見つかった場合に備え、定期的に再スキャンすることも重要です。Snykを使えば、脆弱性や設定ミスをスキャンして修正できます。
アプリケーションのソフトウェア部品表（SBoM）を導入しましょう。これは急速に発展している分野であり、ありがたいことに、2021年の米国大統領令で定められた義務によって大きな注目を集めています。
もう一つ注目すべきテーマは、署名付きGitコミットです。これにより、外部の未検証の関係者によるコード変更を検知できます。正直なところ、広く使われているのを見たことはありませんし、万能の解決策というわけでもありません。この分野の専門家であるDan Lorencは、2021年7月のブログ記事「Should You Sign Git Commits」で、そのメリットとデメリットをうまく解説しています。
DevSecOpsが鍵
ここで紹介したツールや実践方法が示す重要な事実は、サプライチェーンを守るには、開発者からSREまで、その間にいる全員を含むチーム全体の取り組みが必要だということです。開発者をただ制限したり管理したりするのではなく、開発者を巻き込み、ツールやプロセスを提供して力を引き出すほど、アプリケーションの保護はうまくいきます。SnykのようなツールをSDLCに統合すれば、開発者はリリース前に、自分の作業に潜むセキュリティ脆弱性を簡単に見つけられます。これがシフトレフトとDevSecOpsの本質です。Argo CDチームがセキュリティを重視していたというDanの言葉を思い出します。チームの運営方法を詳しく知っているわけではありませんが、迅速な対応と脆弱性に関する透明性の高い議論が、修正までの速さに直接つながったことは明らかです。
2021 State of Cloud Native Application Security Reportでは、SDLCのテストを高度に自動化している企業は、セキュリティテストを実施している割合が2倍高いことがわかりました。また、72%以上が脆弱性の平均修正時間は1週間未満と回答し、36%は平均1日以下でした。Argoプロジェクトのドキュメントによると、同プロジェクトは明らかにこうした実践に取り組んでおり、今回の問題への迅速な対応がそれを裏付けています。
さらに読む
ここで取り上げたテーマについて、さらに詳しく知るためのリソースをご紹介します。
ソースコードの段階からインフラを保護
Snykはワークフロー内のIaCセキュリティとコンプライアンスを自動化し、構成ドリフトや不足しているリソースを検出します。