既知の脆弱なライブラリの利用による問題#

1. 脆弱性の概要 / 影響#

一般的に、アプリケーションは複数のライブラリを組み合わせて構成されています。多くのライブラリでは新しいバージョンが定期的にリリースされており、新機能の追加だけでなく、脆弱性の修正を目的とした、適用が必須となるアップデートも含まれています。脆弱なライブラリを利用している場合、対象のアプリケーション自体に固有の脆弱性がなくても、そのライブラリの脆弱性を悪用した攻撃を受ける可能性があります。

ライブラリの脆弱性情報はNVD（National Vulnerability Database）などのデータベースで広く公開されており、攻撃に利用できるPoCコードが既に存在するケースも少なくありません。そのため、既知の脆弱性を抱えたライブラリをアプリケーション内で使用し続けることは、常に攻撃にさらされるリスクを伴います。セキュリティアップデートが公開された際は、速やかに影響範囲を確認したうえで適用することが求められます。

しかし、ライブラリ間の依存関係や適用するためのコードの修正が困難な場合など、アプリケーションの構成や環境によってはアップデートを即座に適用できないケースも存在します。

本ドキュメントは、こうした状況において根本対策が実施されるまでの間に講じるべき緩和策を示します。

2. 根本的な対策#

セキュリティの観点では、既知の脆弱性を持つライブラリやコードは速やかにアップデートして脆弱性を解消することが求められます。 特に近年はAIの進化により攻撃の高速化が進んでおり、既存の脆弱性をアプリケーション内に放置することはリスクを高める要因となります。

根本的な対策は以下のとおりです。

脆弱性の修正済みバージョンへのアップデート#

脆弱性情報が公開されているライブラリは、修正済みバージョンへアップデートし、脆弱性を解消しましょう。この対応をするには公開された脆弱性が自身のアプリケーションに影響するかどうかをまず特定する必要があります。このような場合にソフトウェアの部品表となるSBOM （Software Bill of Materials）などを利用して、自身のアプリケーションでどのライブラリのどのバージョンを利用しているかをしっかりと管理することが重要となってきます。また、平時から利用しているソフトウェアやライブラリの情報を適切に管理することはサプライチェーン攻撃のような迅速な対応が求められる際に利用箇所の特定や対応を円滑に進めるのに役立ちます。

ただし、最近ではリリース後、すぐに最新バージョンを適用するのは危険な場合があります。近年のサプライチェーン攻撃では正規のメンテナが乗っ取られ、悪意あるコードが含まれたバージョンが公開されてしまう場合があります。そのため、すぐに適用するとアプリケーション内に悪意あるコードが組み込まれてしまう恐れがあります。

したがって、リリース後、一定の検疫期間を設けるpnpmのminimumReleaseAgeのような設定を組み込んだり、バージョンタグを指定してインストールするのではなく、バージョンをハッシュで固定化してインストールするなどの仕組みを設けることが重要となってきています。

メンテナンス可能なライブラリへの差し替え#

何らかの理由でメンテナンスが困難またはサポートが終了しているライブラリは、継続的にメンテナンスが行われている代替ライブラリを探し、差し替えることを検討してください。特にサポートされていないライブラリの継続的な利用は、今後発見されるすべての脆弱性に対して自力で対処する義務を負うことを意味するため、 その保守コストは時間とともに増大し続けることになります。

定期的なリファクタリングの実施#

ライブラリのアップデートを行う上でコードが古い、またはドキュメントが不足しているなど、メンテナンス性に問題がある場合は、定期的にリファクタリングを行い、保守しやすい状態を組織内で維持してください。仕組みとしてリファクタのマイルストーンを配置して、実施するなど開発の計画に組み込むようにしましょう。また、リファクタリングとともにドキュメントを作成したり、見直すことはソフトウェアの保守性を担保することにつながります。

3. 緩和策#

1. 仮想パッチ（Virtual Patching）の導入#

仮想パッチとしてWAF（Web Application Firewall）やIPS（Intrusion Prevention System）を導入することで、脆弱性を狙う攻撃トラフィックが対象のアプリケーションに到達する前に遮断することができます。 仮想パッチの対応では、許可リストを用いる対応と拒否リストを用いる対応があります。

  • 許可リストによる対応: 自身が信頼しているアクセスリストや正常な入力パターンのみを許可し、それ以外を拒否する対応です。攻撃面の縮小効果が見込まれます。
  • 拒否リストによる対応: 既知の攻撃パターンを検出して、拒否する対応です。迅速に適用できる、一方で特定の攻撃のみしか防御できないため回避されるリスクが高いです。特に特定の攻撃ペイロードのみを遮断するルールは、攻撃者が容易に回避できる可能性があるため推奨できません。

また、仮想パッチに加えて対象アプリケーションを常に監視し、不審な動作が発生しないかを確認することも重要となってきます。

2. 独自でのパッチ適用や入力検証コードの実装#

ライブラリのアップデートが困難な場合、検出された脆弱性の種類（SQL Injection、XSS 等）に応じて、脆弱なコンポーネントへの入力・出力を保護するコードを独自に実装し、パッチや入力検証を行うコードを適用する方法があります。

ただし、独自のパッチ適用や入力検証コードの実装は不備が生じやすく、攻撃者によって回避される恐れもあるため、あくまで一時的な対策として位置づけてください。 実装にあたっては、対象アプリケーションの資産の重要度と今後の運用状況を十分に考慮することが重要です。重要度が低いアプリケーションかつ次回のアップデート予定が明確に決まっている場合にのみ、独自のパッチ適用などを検討してください。一方、重要度が高いアプリケーションに対しては独自でのパッチ適用などによる対処は推奨できません。

もし、今後メンテナンスが不可能と判断できるのであれば、経営判断を仰いだうえでアプリケーションの移行など別の手段を検討する必要があります。

また、独自で1からパッチを作成しなくてもソフトウェアやライブラリの提供元などが、アップデートが困難な場合の緩和策を提示していることがあります。 例えば、Apache Log4jの任意コード実行の脆弱性では、特定のクラスをロードしないことで問題を回避する手段が提供されました。 その他にも、GitHub Security Advisoriesなどにも緩和策に関する情報が提示されている場合がありますので確認することをお勧めします。

3. ネットワーク分離・アクセス制限を入れる#

アップデートが困難なアプリケーションに対しては、攻撃の到達を防ぐためにネットワーク分離やアクセス制限を導入するという手段もあります。インターネットからの直接アクセスを遮断し、内部ネットワークからのアクセスのみを許可することで、攻撃対象領域を狭めることができます。さらに、内部ネットワークからのアクセスについても特定のネットワークに限定したり、認証プロセスを追加したりすることで、アクセスできる人やシステムを必要最小限に絞ることができます。

4. 多層防御の構築#

単一の緩和策に依存せず、仮想パッチ・入力検証・ネットワーク分離やアクセス制限など、これまで挙げた対策を組み合わせて防御する多層防御という手段もあります。 多層防御を用いることで攻撃者がアプリケーションにある脆弱性を悪用するための難易度を高めることができます。仮にいずれかの層が突破された場合でも、攻撃に対する被害を最小限に抑えることが可能です。また、突破に要する労力が攻撃者にとってのメリットを上回ることで、攻撃自体を諦めさせる抑止効果も期待できます。

4. 緩和策実施後も残存するリスク#

緩和策を講じた場合でも、以下のリスクが残存する可能性があります。

1. 仮想パッチ（Virtual Patching）の導入#

WAFやIPSによる仮想パッチは有効な対策の1つですが、この対策の防御には限界があります。例えば、攻撃者が攻撃コードをエンコードや難読化することで設定されているルールを回避し、防御を突破される可能性があります。また、ルールの設定によっては正当な通信を誤って遮断する誤検知が発生し、サービスの運用自体に影響を与えるリスクもあります。

さらに、守るべきアプリケーションの脆弱性が増えるにつれて対応するルールを追加し続ける必要があり、設定が複雑化するとともに誤検知が増加する恐れがあります。結果として、仮想パッチの運用・維持に要する人的コストが増大していく可能性があります。

2. 独自でのパッチ適用や入力検証コードの実装#

手動で実装する検証ロジックは、パターンの考慮漏れや網羅性の不足が生じやすく、特定の攻撃パターンへの対処が不完全になる可能性があります。その結果、攻撃者に防御を回避されアプリケーションが攻撃されるリスクが残存します。また、実装の内容によってはそれ自体が新たな脆弱性を生み出したり、コードの継続的なメンテナンスコストが発生する可能性があります。そのため、独自のパッチや入力検証コードを実装した際は、網羅的なテストを実施するとともに、継続的に問題がないか見直せる体制を整えることが重要となります。

なお、近年はAIを活用したコーディングにより実装コストを削減することも可能です。ただし、AIはハルシネーションが発生する場合があるほか、網羅性やセキュリティ面で十分に考慮されていないコードが生成されることもあります。AIを活用する場合は、十分なコードレビューと検証を行ったうえでアプリケーションに適用するようにしてください。

3. ネットワーク分離・アクセス制限の導入#

ネットワーク分離やアクセス制限は、外部からの攻撃経路を遮断し、攻撃対象領域を狭めるという点では有効な対策です。 しかし、内部からの脅威や、攻撃者が内部ネットワークへの侵入に成功した場合には攻撃を防ぎきれず、十分な防御効果が得られません。また、ネットワーク設計やアクセス制限の設定自体に不備がある場合にも突破されるリスクがあるため、ネットワーク設計の十分な検証とアクセス制限の継続的な見直しが必要となります。

4. 多層防御の構築#

複数のセキュリティ対策を組み合わせる多層防御はアプリケーションの堅牢性を高める一方で、管理すべき仕組みが増えるため運用コストの増大を招くリスクがあります。また、各層の設定や運用プロセスが複雑化することで、攻撃の兆候の見落としや対応時の遅延が生じる恐れもあります。 さらに、誤検知によるアラートの増加はアラート疲れを引き起こしやすく、各層の定期的なメンテナンスも必要となります。その結果、多層防御の運用・維持に要する人的コストが継続的に高まっていく恐れがあります。

参考文献#