影の脆弱性に光を当てる

設計上の脆弱性：影の脆弱性を理解する

2024年3月、CISAはSecure By Design（設計段階からのセキュリティ）誓約を開始しました。これは、製品がどのように開発・展開されるかというプロセスのセキュリティを改善する取り組みです。今年のBlack Hatで、業界の不足点について参加者に語った同庁のディレクター、ジェン・イースタリー氏は「私たちが抱えているのはサイバーセキュリティの問題ではありません。ソフトウェア品質の問題です」と指摘しました。

彼女が言うほど単純に白黒つけられる話ではないかもしれませんが、彼女は妥当で力強い指摘をしています。Common Vulnerabilities and Exposures（CVE）の数は増え続けており、2023年は合計28,961件（2022年の25,059件から増加）となりました。これは、組織で使用するソフトウェアが脆弱性を生まないようにするために、セキュリティ担当者が厳しい戦いを強いられていることを示しています。 

CVEはセキュリティチームにとって非常に有用な仕組みであり、どの依存関係が脆弱かを確認できるようにしてくれます。依存関係の一覧を、CVEが付与された脆弱バージョンの一覧と照合するだけで、セキュリティ上の指摘事項が得られます。それに対処すれば安全、ですよね？

そう急がないでください。CVEは方程式の一部にすぎません。 すべての脆弱性が――脅威アクターによって現在実際に悪用されている脆弱性でさえ――CVEを受け取るわけではありません。これは、ソフトウェアライブラリやプロジェクトが意図的に脅威を隠すことを選ぶ場合もあれば、単に「ライブラリの意図された挙動の一部」と判断している場合もあります。たとえ不適切に使われれば組織を危険にさらし得るとしても、です。

CVEのない脆弱性の問題はこうです。依存関係の脆弱性をチェックするスキャナーが見ているのはCVEだけです。CVEがなければ検出結果もない――たとえ組織での依存関係の使い方が、リモートコード実行（RCE）攻撃を含む悪用に対して脆弱な状態を生んでいたとしても、です。

Oligoでは、こうした脆弱性に特に関心を持っています。調査を始めた当初、私たちはそれらを、スキャナーからは見えない一方で潜在的な脅威として影に潜むものだと捉えました。私たちはこれを「影の脆弱性（shadow vulnerabilities）」と呼んでいます。この用語は業界で急速に採用され、ソフトウェアがしばしば設計上脆弱であることを示す脅威群を指すようになりました。しかし、影の脆弱性はどこから来るのでしょうか――そして、カタログ化されていないリスクに対して何ができるのでしょうか？
それでは、影の中へ踏み込みましょう。

影の脆弱性とは？

官僚的な手続きの煩雑さに苛立った従業員が標準プロセスを迂回すると、「シャドーIT」システムが生まれます。インターンが未承認のクラウドストレージに保存すれば、ITから見えない「シャドーデータ」を作ったことになります。従業員が生産性向上のために、職場で使うSaaSツールを個人アカウントで利用しようとすれば、「シャドーSaaS」を作ったことになります。

‍テックの世界で「シャドー」とは、既知・承認・監視された組織のポリシーや実務の外側で、たいてい監督なしに機能することを意味します。多くの場合、こうしたシャドーは他の問題よりも大きなセキュリティリスクとなります。未知の脅威は対処も緩和もできないからです。
影の脆弱性の前提条件はシンプルに2つです：

1. 脆弱性であること――アプリケーションの不正または意図しない利用を可能にする問題であること。
2. CVEがないこと。

最初の点は非常に重要です。影の脆弱性は理論上の脅威ではありません。現実世界での影響があります。

Oligo Securityの研究者による最近の発見により、Ray、TorchServe、TensorFlow、SnakeYAMLなど、広く使われているソフトウェアプロジェクトに影の脆弱性が存在することが明らかになりました。これらの脆弱性は――人気ライブラリの誤用に起因し――組織をRCEなどのリスクにさらし、場合によっては攻撃者により実際に悪用されていました。

なぜ影の脆弱性はカタログ化されないのか？

短い答え：複雑だからです。 
CVEの多くは、単純なコーディングミス、または設定・実装上の問題に起因します。影の脆弱性は異なります。複雑な設計判断の結果として生じるのです。 通常のレビューで見つかる分かりやすいコーディングエラーとは違い、これらの脆弱性は微妙で見落とされがちです。異なるコンポーネント同士の相互作用から生まれます。 あるユースケースを可能にする設計選択が、別のユースケースではリスクになります。一般に、簡単にパッチで消せるものではなく、より広範なシステム的課題を反映しています。 

その課題の一つが、重要な問いへの答えを決めることです。そもそも「脆弱性」とは何でしょうか？上では私たちなりの簡潔な定義（「アプリケーションの不正または意図しない利用を可能にする問題」）を示しました。しかし、誰もが同じ見方をしているわけではありません。多くのオープンソースプロジェクトのメンテナーの目には、脆弱性とは意図しない、または文書化されていない挙動から生じるものでなければなりません。

ソフトウェア工学の古典的なジョークがあります。ドキュメントに書いてしまえば、それはバグではなく機能だ、と。では、意図された挙動はどこで終わり、脆弱性はどこから始まるのでしょうか？ 
ここでの定義や境界は、立場によって変わります。たとえば、無償で多くの時間を注いでいるオープンソースプロジェクトのメンテナーだとしましょう。あなたが意図的で十分に文書化されていると考える挙動を、誰かが脆弱性として特徴づけようとすることを快く思わないかもしれません。

攻撃者から身を守ろうとしている側から見ると、状況は違って見えます。データを盗まれたりシステムを停止させられたりした攻撃者が、CVEを使ったのか、開発者が意図して文書化した挙動を使ったのかで、損益に違いは出るでしょうか？いいえ、実際にはほとんど違いはありません――むしろ、攻撃の影響に苦しんでいる最中に、プロジェクトがそのような挙動を含み、それを「意図的」と呼ぶことに腹立たしさを覚えるかもしれません。
では、何にCVEが付与され、何が影に隠れるのかを誰が決めるのでしょうか？ここからは責任ある開示（responsible disclosure）の領域に入ります。

影の脆弱性とベンダー間の争い

脆弱性の開示には、負の影響が生じる可能性がつきまといます。パッチがないまま早すぎる開示が行われれば、誰もアプリケーションを安全にできないうちに攻撃者が大きく先行してしまいます。遅すぎる（あるいは全く行われない）場合、スキャナーは脆弱性を検出できません。
適切なタイミングを実現するため、業界は責任ある開示とCVE付与を受けるための標準手順を作りました。
プロセスは次のように進みます――そして、ここで影の脆弱性がどのように関わるかが見えてきます：

1. 発見と初期分析
2. 脆弱性の報告 

—-影の脆弱性はここで発生する—-

3. ベンダー（メンテナー）による受領確認
4. ベンダー評価と対応
5. 開示タイムラインの調整
6. パッチ開発とテスト
7. 修正のリリース
8. 公開開示

プロセスのかなり早い段階で、メンテナーは脆弱性を相互に合意するのではなく、争うことを選ぶ場合があります。メンテナーは、再現可能で悪用可能――あるいは実際に悪用されている――脆弱性であっても争うことができます。

争いの解決には長い時間がかかることがあり、その間に攻撃者候補にとって決定的な好機が生まれます。組織側は存在を検知できないまま、問題が悪用され得るのです。 

メンテナーの視点では、これらの脆弱性はユーザーがライブラリのセキュリティベストプラクティスに従っていないことから生じる場合が多いとされます。しかし、それらはしばしばドキュメントの中に埋もれており、開発者が誤解したり（あるいは完全に見落としたり）しやすい形になっています。開発者は、デフォルト設定を使い、一般的な使い方をしていれば、重大なリスク露出にはならないと考えがちです。

メンテナーは問題を認識しているものの、行動する予定はなく、意図しない挙動の結果だとは見なさない、という立場を取ることがあります。たとえその挙動がシステムを危険にさらすとしてもです。脆弱性の存在を認めつつも、対処しないことを選ぶ場合があります。 
メンテナーはそれぞれ独自の利害や意見（時に型破りなもの）を持つ個人であり、「修正しない（no fix）」という判断で問題を退ける力を持っています。
動機はさまざまです。リソースの制約、リスクは最小だという信念、あるいは単に他の作業を優先すること。メンテナーにはやることが多く、その多くは報われにくい作業であり、意図された挙動だと考えるものの修正は、他のタスクほど重要に見えないかもしれません。

攻撃下の影：ShadowRayの継続的な悪用

2023年3月、Oligo Securityは、私たちがShadowRayと名付けた攻撃キャンペーンを発見しました。
この攻撃キャンペーンは、広く使われているオープンソースAIフレームワークRayにおける、争いのある脆弱性（CVE-2023-48022）を標的にしていました。 

少なくとも直近7か月の間、この問題は攻撃者によって積極的に悪用され、暗号資産マイニングのための計算資源の窃取や、クラウド認証情報、AIモデル、データセットなどの機微なデータの大量窃取に利用されてきました。影響を受けた組織には、世界でも最も著名な大学、バイオ医薬品企業などが含まれます。

CVE-2023-48022は争いがあったため、多くの開発チーム（および大半の静的スキャンツール）は検出できませんでした。Rayのドキュメントを見ていない開発者もいたかもしれず、その結果、数百万ドル相当の計算資源が盗まれました。  

ソフトウェアライブラリ全体が、設計上安全でない形でアーキテクトされている場合があり、無邪気な誤用がセキュリティ脆弱性を持ち込むことがあります。OSSライブラリは、開発者体験の観点では理にかなった形で一般的な作業を簡素化・自動化することがありますが、新たに生じ得るセキュリティリスクへの配慮が欠けていることがあります。こうした場合、特定の機能を想定外の方法で使うことが、悪意ある活動への道を開き得ます。 

本質的に、影の脆弱性とは、強力な機能を提供することとセキュリティ制御を確保することの間で妥協した結果がもたらす影響です。これらの脆弱性は、開発者や悪意ある行為者が偶然または意図的にトリガーするまで、気づかれないまま隠れ続けます。
[xkcd](https://xkcd.com/)の言葉を借りれば、「いくつかの脆弱性は、システムのバグであるだけではない。システムそのものなのだ。」

責任の押し付け合い：最終責任はどこにあるのか？

ソフトウェアアプリケーションのセキュリティを確保する最終責任は誰にあるのでしょうか？開発者でしょうか？ユーザーでしょうか？オープンソースライブラリのメンテナーでしょうか？
現実には、責任はしばしばグレーゾーンです。オープンソースライブラリの作成者はユーザーがベストプラクティスに従うことを期待しますが、プロジェクトメンテナー（継続的なオープンソースプロジェクトの運営・保守という容易ではない作業に追われる中で）は根本的な問題のパッチ適用を優先しないことがあります。その結果、ユーザーは自分が直面しているリスクに気づかないまま、脆弱な状態に置かれます。

責任の所在は割り当てにくいとしても、結果は圧倒的に、開発者やメンテナーではなく、オープンソースライブラリを利用する組織に降りかかります。
では、列挙されておらず、スキャンツールから見えないものを、組織はどうやって把握すればよいのでしょうか？

影を見抜き、反撃する

攻撃者が影の脆弱性を使っている場合でも、アプリケーションが悪用されていることを把握する方法はあるのでしょうか？Oligoでは、攻撃者にとって、CVEで組織を侵害するか影の脆弱性で侵害するかは重要ではないと気づきました。ならば、監視ツールにとってなぜそれが重要であるべきでしょうか？私たちは、組織がソフトウェア脆弱性の全体像を明らかにし、行動できるようにする、これまでとは異なるものを作ろうとしました。

Oligo ADR（Application Detection & Response）は、進行中のアプリケーション攻撃を検知できる世界初のソリューションです。深いランタイム検査により、Oligo ADRは、構築・購入・利用するあらゆるアプリケーションにおけるすべての依存関係の挙動を可視化し、挙動パターンが攻撃開始を示すときにそれを特定します。 
Oligo ADRにより、セキュリティチームは数か月ではなく数瞬でアプリケーション侵害を検知でき、CVEが割り当てられているかどうかに関係なく脅威を検知できます。Oligo ADRは、技術的オーバーヘッドが小さく数時間で導入できるソリューションで、サプライチェーン侵害やゼロデイのアクティブな悪用を検知できます。

Oligoの使命は、あらゆる脆弱性を影から光の下へ引き出し、次世代のアプリケーションセキュリティを切り拓くことです。
攻撃者の皆さん、注意してください。隠れ場所はもう残り少なくなっています。