A9: 既知の脆弱性を持つコンポーネントの使用 2017 OWASP

既知の脆弱性を持つコンポーネントとは？

OWASPトップ10では、コンポーネントという用語は非常に広い意味で使われています。例えば、貴社が利用する外部提供の身元確認アプリ「It's me」などのフルソフトや、どこかに潜んだ小さな依存関係を指すことがあります。

A9：既知の脆弱性を持つコンポーネントの使用について話す場合、古いソフトや積極的に更新されないソフトのことを指すことが多いです。通常、しっかり管理されたソフトは問題発生時に対処しますが、更新作業が煩雑なため、利用者が更新に消極的になることも多いです。

これらの問題は、人の怠慢さに依存しているため、根本から適切に修正するのは容易ではありません。原因を特定し、適切な更新戦略を実施することはコストがかかるため、多くの企業は必要なときだけ更新する選択をする傾向にあります。

Wallarmがコンポーネント提供者として利用者に更新を強制する戦略を取ることも可能ですが、その方法は利用者に優しいとは言えず、できるだけ避けられます。これは、倫理的ハッカーやペネトレーションテスターにとって、報告の材料となるという点で朗報です。

既知の脆弱性の特定方法

ペンテスト時のクライアントやバグバウンティの対象が利用している依存関係や、その中に含まれる依存まで十分理解していない場合、A9：既知の脆弱性を持つコンポーネントのリスクにさらされやすくなります。初めは判断が難しいかもしれませんが、テスト対象のアプリに時間をかけ、経験を積むことで知識は深まります。

これらの依存関係は、一般に想定される範囲を超えています。ソフトの設定ファイルに記述されるものだけでなく、データベースシステム、APIセキュリティ、さらにはオペレーティングシステム自体も含まれます。

A9：既知の脆弱性を持つコンポーネントの脆弱性を発見するために自動スキャナを使用することもできますが、調査範囲を越えないよう十分注意が必要です。Wallarmでは、要求を発生させないパッシブスキャンのみで、手動テストで発見した内容を解析する方法を採用しています。自動スキャナの使用については、貴社と十分に協議することが重要です。

可能な限りソフトのバージョン番号を探します。Jqueryのバージョン、データベースのバージョン、OSの表示など、見つけた情報は手動でチェックします。また、ハッキング中にはburpなどのMiTMプロキシを用いて、訪問中のサイトのソースコードを自動解析します。古いソフト検出用のプラグインは複数あり、中でもWallarmのお気に入りは retireJS です。

既知の脆弱性への露出を防ぐ方法

開発者は利用している依存関係を十分に把握し、その使用による影響を考慮する必要があります。さらに、すべての依存関係を一覧できるインベントリシステムに登録することで、全体像を管理することが重要です。これらの対策は自動化が望ましいですが、自動実行される内容を把握しておくことも必要です。

依存関係のバージョンが最新であるか確認するため、脆弱性スキャナの導入も求められます。脆弱性スキャナはインターネット上の最新CVE情報を収集し、貴社のインフラや依存コンポーネントを自動で検査します。

これらのスキャンは定期的かつ自動で実施し、忘れられることがないようにするべきです。外部の視点から検査を行うことで、実際の利用環境に近い形でチェックが可能になり、他のサーバへの影響も避けられます。

また、信頼できるソースからのみ依存関係を利用し、例えばオープンソースの依存コンポーネントをサードパーティが改変したものなどは使用しないようにする必要があります。採用中の依存関係を厳格に監視し、サードパーティや外部コンポーネントの採用可否をリスクベースで判断すること、そして更新戦略も十分に検討し、必要な場合はもちろん、少なくともセキュリティパッチごとに更新することが求められます。

これらすべては、明確で簡潔な計画にまとめ、関係者全員で共有することが必要です。

• 手動での更新

システムやコンポーネントを手動で更新する方法もありますが、管理が煩雑になる上、マイクロサービスの登場などで複雑さは増す一方です。手動更新を採用する場合、古い脆弱性を把握できる適切なインベントリ管理システムの構築が不可欠です。

また、更新が他の部分に予期せぬ影響を与える可能性もあるため、インフラ全体の理解が必要です。システム破壊を避けるため、開発者が修正し、テスターが互換性を確認できるようにすることが求められます。

• HDIVを利用

HDIVはWebおよびAPIセキュリティ向けの有用なツール群を提供します。これらのツールはソフト開発ライフサイクルに統合され、脆弱なコードや依存関係を早期に検出し、必要に応じた更新を促します。これにより、開発過程全体を守り、早期に脆弱性を把握できます。さらに、すべての脆弱性は一元管理されたダッシュボードで管理され、スキャン結果を容易に確認できます。

‍

世界における既知の脆弱性を持つコンポーネントの使用例

これらの脆弱性の深刻さを説明するためには、あらゆる角度から検証する必要があります。内部スキャナで発見された問題は修正するべきですが、理想的には古い依存関係をすべて更新すべきです。しかし、実際にはインフラに影響が認められないバグバウンティ報告の場合、支払いを渋ることもあります。

一見、古い依存関係をそのままにしておいても問題ないように思われますが、実際には大きな被害を招き、A9：既知の脆弱性を持つコンポーネントに晒されるリスクが高まります。あるハッカーが利用できなかった脆弱性でも、他のハッカーには狙われる可能性があります。

現実のターゲットでよく見られる例として、古いJSのバージョンがXSSの脆弱性を持つ場合があります。この場合、報告すべきか否かは状況次第です。理想的には、影響の大小に関わらず常に報告を受理すべきですが、今は問題なくとも、後に新機能追加時に大きな障害となる可能性があるからです。

ただし、リスク分析の結果、将来的に直接的な危険が認められない場合、報告を見送る理由も理解できます。影響がなく、今後も発生しないのであれば、修正に費用をかける意味はありません。

また、古いバージョンのlinuxも例として挙げられます。こちらも状況により利用可能性は異なります。対象で開いていないポートを利用する必要がある場合、実際の影響はほとんどなく、追加の影響が確認されるまでは報告を控えるべきです。

注目すべき報告として、Slackからのハクティビティレポートがあります。古いバージョンのjavascript使用が原因で、攻撃者がSlack所有でないドメインからフォームを読み込むことが可能となりました。

https://hackerone.com/reports/335339

脆弱性の分類方法

本トピックでは、脆弱性の分類先について考察します。一見当たり前に思えるものも、実際に問題を学ぶと複雑さが浮かび上がります。たとえば、依存関係のために2015年のXSSが見つかった場合や、サニタイズライブラリ起因で2019年のSQLインジェクションが発生した場合、これらはそれぞれの分類（XSSやインジェクション）に属するとも、また既知の脆弱性を持つコンポーネントとして分類するとも議論できます。場合によっては、両方に分類することも可能です。

OWASPトップ10で触れられるXSS、XXE、インジェクションなどの脆弱性は、利用されるコンポーネントが再利用されることで、最終的には既知の脆弱性を持つコンポーネントへと発展することがよくあります。例示のように明白でない場合もあり、たとえばXSSの問題を持つJQueryライブラリが含まれているものの、該当機能が使われていない場合もあります。しかし、後にその脆弱なコードに依存する機能を追加する際、JQueryコンポーネントの更新を忘れる可能性も生じます。こうしたケースは、XSSと既知の脆弱性を持つコンポーネントの両方に分類され得ます。 ‍

‍

結論

まとめると、これらの脆弱性の発見は可能な限り自動化することが望ましいものの、時折手動監査の重要性を見落としてはなりません。ハッカーの場合、影響を慎重に判断し、影響が明確になるまではこの種の脆弱性をバグバウンティとして報告しないことが推奨されます。ペネトレーションテスターについても、参考情報として報告するのが望ましいですが、可能であればさらに検証することが理想です。