企業ネットワークを守るために作られたネットワークエッジセキュリティデバイスが、今や負債となりつつあります。専門家が基本的な脆弱性と呼ぶゼロデイ攻撃の急増が懸念されています。セキュリティデバイス業界は軌道修正できるのでしょうか？
企業は長年、ファイアウォール、ルーター、VPNサーバー、メールゲートウェイに頼ってネットワークを攻撃から守ってきました。しかし、これらのネットワークエッジデバイス自体がセキュリティ上の負債となりつつあります。
数週間ごとに新たな危機が発生します。セキュリティチームは、また新たなゼロデイ攻撃が報告されるたびに、ネットワーク機器のパッチ適用やマルウェア埋め込みのスキャンに奔走します。ベンダーは、これらの攻撃は高度な国家支援型攻撃者によるものだと強調しますが、批評家はなぜバッファオーバーフローやコマンドインジェクション、SQLインジェクションといった基本的な脆弱性が、サイバーセキュリティを本業とする企業のミッションクリティカルなコードベースに依然として残っているのか疑問視しています。
攻撃者は常に手法を進化させています。セキュリティエンジニアリングは本質的に難しく、すべてを修正できるわけではありません。すべてのソフトウェア製品には脆弱性があり、セキュリティツールも例外ではありません。もし複雑な脆弱性の話であれば、これらは妥当な反論でしょうと、サイバーセキュリティおよびペネトレーションテスト企業watchTowrのCEO、ベンジャミン・ハリス氏は言います。「しかし、これらは1990年代から存在する脆弱性クラスであり、それを防ぐ、または特定するためのセキュリティコントロールは長い間存在しています。言い訳の余地はありません。」
ネットワークエッジデバイス：新たな戦場
Googleの脅威インテリジェンスグループは、2024年に75件のゼロデイ脆弱性が悪用されたことを追跡しました。そのうち約3分の1がネットワークおよびセキュリティ機器を標的としており、攻撃者が悪用可能なITシステムの範囲を考えると非常に高い割合です。この傾向は今年も続いており、2025年の最初の10か月でも同様の数値が報告され、Citrix NetScaler、Ivanti、Fortinet、Palo Alto Networks、Cisco、SonicWall、Juniperなどのベンダーが標的となっています。
ネットワークエッジデバイスは、リモートからアクセス可能であり、エンドポイント保護の監視対象外であり、横方向移動用の特権認証情報を含み、集中型ログソリューションに統合されていないため、魅力的な標的となっています。しかし、研究者たちは10年以上前からこれらのシステムの脆弱性を報告してきましたが、孤立した事例を除き、攻撃者の関心はあまりありませんでした。
しかし、ここ数年で攻撃が急増し、侵害されたネットワークエッジデバイスは、国家支援型サイバースパイグループやランサムウェア集団による企業ネットワークへの主要な初期侵入経路の一つとなりました。
この変化にはCOVID-19パンデミックも影響しています。組織はリモートワーク対応のため、VPNゲートウェイやファイアウォール、安全なWeb・メールゲートウェイの導入を急速に拡大しました。
フィッシングの成功率低下も要因の一つです。かつては主要な初期侵入経路だったフィッシングは、過去10年間の防御努力により効果が薄れています。2024年には、Mandiantの報告によると、侵入の33％が脆弱性の悪用、16％が盗まれたまたは弱い認証情報、フィッシングはわずか14％でした。
「攻撃者は毎日新しくて最高のことをしようとしているわけではありません」とwatchTowrのハリス氏は説明します。「彼らはスケールでうまくいくことをやります。そして今や、フィッシングはスケールで考えると客観的にコストが高すぎるか、成功率が低すぎて、メールインフラの展開やドメイン・送信プロトコルの整備、EDRやAV、サンドボックス、メールフィルターを回避する方法を見つけるための時間投資に見合わなくなっています。今はEDRが通常導入されていない境界デバイスで1990年代レベルの脆弱性を見つけて悪用し、そこから横展開する方が簡単です。」
また、ネットワークエッジデバイスへの攻撃キャンペーンが、セキュリティチームによってこれまで以上に可視化されている可能性もあります。彼らがこれらの機器で何が起きているかを以前より詳しく調査するようになったためです。
「10年前、私はこの種のルーター向けのエクスプロイト開発を職業としてやっていました」と脆弱性インテリジェンス企業VulnCheckのCTO兼リサーチ責任者ジェイコブ・ベインズ氏はCSOに語ります。「当時も多くのグループが関心を持っていましたが、セキュリティ業界自体はデスクトップエンドポイントにより関心がありました。そして業界はその種のエンドポイント保護が上手くなりました。フィッシング対策も強化され、今はこの分野が次の改善対象となっています。セキュリティ分野からの注目は増えましたが、攻撃者が増えたわけではありません。彼らはずっと存在していたと思います。」
2024年のネットワーク・セキュリティデバイスのゼロデイ脆弱性
ネットワークデバイスのコードベースに基本的な脆弱性が残存
watchTowrのハリス氏は、安全なシステムを構築するためのエンジニアリング努力を軽視するつもりはありません。しかし、ここ2年で発見された多くの脆弱性は、あまりにも基本的で、自動コード解析ツールやコードレビューで発見できたはずだと感じています。
「一部のVPNの脆弱性は、ベンダーにとって恥ずかしいほど単純なものでした」と彼は言います。複雑なものでも、製品セキュリティに真剣に投資している組織であれば発見できたはずです。
それでも、これらの脆弱性の多くは基本的なものであるにもかかわらず、攻撃者が直接、基盤となるOS上でroot権限で任意のコードやコマンドを実行できるわけではありません。攻撃者は通常、複数のコンポーネントにまたがる脆弱性を見つけて連鎖させる必要があり、それぞれのコンポーネントがどのように連携しているかを理解し、リモートコード実行への経路を特定する必要があります。
「私は必ずしもそれらを複雑なエクスプロイトチェーンと呼ぶつもりはありませんが、単純だと呼ぶのも少し不公平だと思います」とVulnCheckのベインズ氏は言います。「Cisco ASAルーターやPAN-OSシステムのようなものは非常に複雑なシステムです。それらのシステムでコードを書いたりバグを特定したりするには多くの知識が必要です。」
ケイレブ・グロス氏（オフェンシブセキュリティ企業Bishop Foxの能力開発ディレクター）も、これらのバグを見つけるためにはリバースエンジニアリングのスキルが必要だと指摘しています。これらのデバイスのファームウェアイメージはオープンソースアプリケーションのように容易に入手できず、ファイルシステムも暗号化されていることが多いからです。復号後も、研究者や攻撃者は各コンポーネントがどのように通信しているかを学ばなければなりません。
「CやC++コードでシステムにコマンド文字列が渡されるコマンドインジェクションを特定するのは、それほど難しいことではありません」とグロス氏は言います。「しかし、これらのセキュリティネットワーク機器のような非常に複雑なアプライアンスを理解するのは難しいのです。単なるWebアプリケーション一つというわけではありません。」
このことは、製品開発者自身が、全体の製品アーキテクチャを十分に理解していない場合、あるコンポーネントに新機能を追加した際のリスクを把握しにくくする要因にもなります。大規模な製品組織では、異なる開発チームが一つの製品システムの異なるコードベースを担当するのは珍しくありません。
しかしハリス氏は反論します。製品セキュリティチームは、セキュリティ上の影響がある可能性のあるコードバグを認識し修正すればよいのであって、攻撃者のように実際にエクスプロイトを開発する必要はありません。
「製品セキュリティチームの仕事は、実際にシェルを取るようなエクスプロイトを作ることではありません」と彼は言います。「あなたの目的は、特定した脆弱性のうち、どれが実際に悪用可能かを見極めることです。誰でも見つけられるような簡単なもの（ロー・ハンギング・フルーツ）を排除し、それからより複雑なものを見つけることに努力を注げばよいのです。」
ハリス氏はさらにこう付け加えます。「私たちの見解では、過去12か月間の状況を見る限り、ベンダーによるこうした努力が効果を上げている証拠はありません。」
2025年のネットワーク・セキュリティデバイスのゼロデイ脆弱性
セキュリティ負債と優先順位付けの課題
もう一つの問題は、これらの機器には10年以上前のレガシーコードが多く含まれていることです。さらに、買収によって引き継がれた製品やコードベースの場合、元の開発者がすでに退職していることも多いです。例えば、過去2年間で頻繁に標的となっているベンダーの一つIvantiは、2020年にPulse Secureを買収し、Pulse Connect Secure SSL VPNはその後Ivanti Connect Secureとなりました。
アプリケーションセキュリティテスト企業Veracodeの共同創業者兼チーフセキュリティエバンジェリストクリス・ワイソパル氏によると、古いコードの脆弱性、いわゆるセキュリティ負債への対処はコストも手間もかかります。特にCやC++コードにおけるバッファオーバーフローや整数オーバーフローなどの問題は、仕組みを完全に理解していない部分を壊してしまうリスクを恐れて、開発者が修正をためらう傾向があります。
「アプリケーションセキュリティテストの近代的なプロセスがあり、コードが書かれてすぐに脆弱性が検出されれば、開発者はすぐに修正できます」とワイソパル氏は言います。「しかし、レガシーコードを扱う場合—実際にC++アプリケーションで数千ものオーバーフロー問題があり、元の開発者はとっくにいなくなっているケースも見ています—新しい開発者がそのコードを見て修正するのは非常に困難で、誰も触りたがりません。最終的には『本当に悪用可能なのか証明してくれ、これは誰も理解していない重要な古いコードで、触るのは危険だ』という話になってしまいます。」
その結果、ある脆弱性は他のものよりも影響の証明が必要となり、バッファオーバーフローが任意コード実行につながることを証明するのは簡単ではありません。OSのASLR（アドレス空間配置のランダム化）などのエクスプロイト緩和策を回避する必要があるからです。一方で、コマンドインジェクションの問題は、ワイソパル氏によれば、古いコードベースでも比較的修正が容易です。認可バイパスは通常、手動のペネトレーションテストで発見されます。
「これらの脆弱性カテゴリはそれぞれ少しずつ異なっており、これがアプリケーションセキュリティが難しい理由です」と彼は言います。「しかし、これらはすべてトップ10の問題です。これらの組織は『自社製品からトップ10の脆弱性クラスを排除する』という計画を持つべきです。しかし、巨大なレガシーコードベースを抱えている場合、正直なところ、それを実現するのは高コストで困難です。」
ベンダーは自らにより高い基準を課す必要がある
本記事で取材したすべての研究者は、セキュリティ機器メーカーが安全な開発ライフサイクルプログラム、社内アプリケーションセキュリティテスト、コードレビュー、レガシーコードの書き換えにもっと真剣に取り組む必要があることに同意しています。しかし、そうした取り組みを促す財務的インセンティブが欠如しているため、状況が変わることにあまり期待していない研究者もいます。
古いコードをセキュア・バイ・デザインで書き直すには多くの開発時間が必要です。静的・動的スキャナーが検出したすべてのバグを修正するだけでも予算上の課題が生じ、優先順位付けが必要になります。
しかし、セキュリティベンダーはより高い基準で評価されるべきです。なぜなら、彼らは銀行や政府機関、重要インフラを守るための製品を販売しているからです。顧客にとって負債になってはなりません。ハリス氏の言葉を借りれば、「APT（高度持続的脅威）グループが我々の社内QAチームになることを期待しているのか？」ということです。
ワイソパル氏は、米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）が昨年開始した安全なソフトウェア開発証明書フォームやSecure by Design原則を、正しい方向への一歩と評価しています。CISAプログラムは、主要な設計者であるLauren Zabierek氏とBob Lord氏が4月にCISAを離れたことで一部後退していますが、今後他国政府が法規制を導入して市場に圧力をかける可能性も十分にあります。「これだけ多くの重大産業で、ミッションクリティカルな機器の脆弱性が原因で繰り返し侵害が発生し、その根本原因が疑問視されている今、規制についての議論が進まない方が驚きです」とwatchTowrのハリス氏は言います。「今や、企業が財布と予算で意思表示するのが先か、規制が先に導入されるのかの競争です。しかし、いずれにせよ何かを変えなければなりません。」
