開発パイプラインに組み込まれた専用のアプリケーションセキュリティスキャニングツールは、コードを堅牢化しソフトウェアサプライチェーンのセキュリティを強化するうえで大きな効果を発揮します。しかし、開発チームが注意を怠れば、こうしたセキュリティスキャナー自体がサプライチェーンの奥深くに攻撃者を招き入れる入口になりかねません。
昨春、開発とセキュリティの両業界は、まさにそのシナリオが現実になる事態を目の当たりにしました。2つの異なるセキュリティ系オープンソースプロジェクトの開発環境が侵害され、サプライチェーン攻撃によって、疑いを持たないソフトウェア開発チームに向けて改ざん版のTrivyとKICSが配布されてしまったのです。この攻撃は、TeamPCPによる大規模な認証情報窃取と詐欺行為を目的とした、より広範なサプライチェーン攻撃の一環でした。
来週開催されるラスベガスのBlack Hat USAカンファレンスでは、別のセキュリティ研究者が、攻撃者がセキュリティツールを悪用する別の手口を実演する予定です。この攻撃はベンダーの開発環境を完全に侵害する必要がなく、手間もそれほどかかりません。ツールにスキャンを実行させ、巧妙に細工した悪意あるコードリポジトリを読み込ませるだけで済んでしまうのです。
この研究を行ったのはZeroPathのセキュリティチームです。同チームは、名前を伏せた20社のセキュリティベンダーを対象に脆弱性の有無を調査し、うち5社で重大な問題を確認しました。中には、研究者たちの発見に対して上限額のバグバウンティを支払ったベンダーもありました。
「発見された問題の大半は、クラウドの認証情報のような機密情報の漏えいに関するものでした。あるケースでは本番データベースが含まれており、別のケースではベンダーで実際に働く開発者のDockerおよびGitHubの個人アクセストークンが含まれていました」と、来週のセッションで詳細を説明する予定のZeroPath共同創業者兼CTO、ラファエル・カーガー氏は語ります。「こうした問題は、安全だと思い込んでいた顧客にまで影響が及びかねない状況でした」
怪しいプローブから始まった調査
この研究の発端は、昨年末にカーガー氏のチームが自社環境内で追跡したあるアラートでした。本番監視ソフトウェアの中に、スキャン失敗を示す不審な痕跡が記録されていたのです。
「そのアラートは、現在のリポジトリの範囲外にあるファイルを読み込もうとして失敗したことを示すものでした。読み込もうとしていたファイルには、センサーの認証情報などが含まれていた可能性がありました」と同氏は説明します。「私たちはこれを事前に検知し、そのリポジトリの調査を開始しました」
リポジトリのいくつかの痕跡を調べた結果、チームは攻撃者が同社のホスト型セキュリティ製品の攻撃対象領域を系統的に検査していたことを突き止めました。攻撃者は、ZeroPathのスキャニングツールが任意のファイルをどう処理するか、依存関係の扱い方、そして機密情報の取り扱い方法を調べていたのです。この調査があまりに興味深かったため、カーガー氏とチームはその場で、この探索的プローブの続きを行うツールを自ら構築し、攻撃者が関心を示していたのと同じ処理領域に自社環境の欠陥がないかテストすることを決めました。
チームは、リポジトリ解析が必ずしも読み取り専用の処理ではないという発想を出発点にしました。多くのスキャナーはコードを実行し、処理方法次第ではコード実行を強制されかねないファイルを解析します。これは、信頼できないコンテンツを実行してしまうという、AppSecにおける昔からの課題に行き着きます。スキャナーが分離環境なしにコンテンツを処理していれば、攻撃者が想定外のコンテンツを仕込むことで、スキャナーにファイルを読み込ませるだけでなく悪意あるコードを実行させることも可能になります。例えば、あるツールがクラウド構成ファイルのセキュリティ問題をスキャンし、チェック対象としてカスタムルールを格納したフォルダを指定できる仕組みだった場合、スキャン対象のリポジトリを制御する攻撃者は、実際にはルールではなく悪意あるプログラムであるものを「カスタムルール」として仕込める可能性があります。スキャナーがそれを読み込んだ瞬間に、そのプログラムが実行されてしまうのです。
スキャナーをスキャンする
自社製品についてこの観点からさらに掘り下げて調査した後、ZeroPathチームは、構築した実験的ツールがAppSecサプライチェーン全体にとってより広い価値を持ちうると判断しました。そこから彼らはツールを改良し、他のセキュリティベンダーのスキャナーがどの程度この種の攻撃に対して脆弱かを調べ始めました。
「私たちが構築したツールは一歩進んで、ベンダーのドキュメントをすべて読み込み、ペイロードを自動生成し、それらを動的にテストできる形で組み立てます。これにより、場合によっては特定ベンダー向けに調整された、拡張されたペイロード群を作り出せるのです」とカーガー氏は説明します。「つまり、このツールは基本的にあの攻撃者がやっていたことを、いわば大幅にパワーアップした形で行っていたわけです」
「Build Canaries」と名付けられたこのツールは、まずチームが選定した最初の20種類のスキャナーを対象にテストされました。選定したのは、営業担当者の対応やソーシャルエンジニアリングを経ずに登録できる無料版を提供しているセキュリティプラットフォームで、なおかつ「ウェブサイトに大手企業のロゴや導入事例が掲載され、資金調達の実績もうかがえる」ものでした。
Black Hatでの講演では、この研究の主要な発見内容が詳しく紹介される予定ですが、最大のポイントは、そのほとんどが顧客企業に重大な波及被害をもたらしかねないものだったという点です。対象にはフォーチュン1000企業、防衛関連企業、主要な政府機関も含まれていました。例えば、アクセスに成功した本番データベースには、大手顧客を攻撃するための材料が豊富に含まれていました。
「適切な権限が付与されていたため、これらの企業のコードを改ざんすることさえ可能だったでしょう」と同氏は言います。「また、これらの企業が抱える未修正の脆弱性をすべて閲覧することもできたはずです。そこには機密情報やポリシー違反に関する内容も含まれていました」
カーガー氏はBlack HatでBuild Canariesを初公開し、AppSecチームが自社のセキュリティスキャニング環境をテストするために使える349種類の検証済みペイロードとともに、オープンソースツールとして提供する予定です。あわせて、セキュリティチームが自社のパイプラインやベンダーとの関係を即座に監査できる「リポジトリ取り込み実行対象領域の分類法」も公開する計画です。より広い視点では、セキュリティチームに対し、他のビルドツールに向けるのと同じ厳しい問いを、自社が利用するセキュリティスキャニングベンダーにも投げかけるよう呼びかけていく考えです。
「AppSecは競争が非常に激しい市場として知られています。そのため、こうした小規模なチームの多くは、セキュリティへの投資よりも市場開拓機能への投資を優先しがちです」と同氏は警鐘を鳴らします。「こうした環境において、適切な分離とマルチテナント管理が確実に行われているかどうかを、しっかり確認する必要があります」
