NatJack攻撃クラスが数十年来のネットワークインフラに潜む設計上の欠陥を露呈
ネットワークアドレス変換（NAT）は、IPv4アドレスの枯渇問題に対処する手段として、大規模ネットワーク内部にIPアドレスを割り当てる標準的な方法として何十年も使われてきました。
NATの基本的な前提は、プライベートアドレスがプライベートなまま保たれるというものですが、その前提は今や（そもそも本当に成り立っていたのかも疑わしいものの）完全には正しくないかもしれません。Black Hat USA 2026で、独立研究者でありSynack Red TeamのメンバーでもあるMalcolm Stagg氏は、NATのコネクション追跡テーブルを操作する攻撃クラス「NatJack」を公表しました。
被害者とNAT境界を共有する攻撃者は、従来のレイヤー2攻撃に必要だったIPスプーフィングやブロードキャストドメインへのアクセスなしに、アクティブな接続を乗っ取ったり、DNS応答を汚染したり、サービス拒否を引き起こしたりできます。13社のベンダーに通知が行われ、テストは95件の報告にわたり32の製品・構成を対象に実施されました。テストされた実装はすべて、NatJackの手法のいずれか、あるいはすべてに対して脆弱であることが判明しました。
Stagg氏はNATの欠陥を意図的に探していたわけではありませんが、結果的に発見することになりました。「まったくの偶然からこの攻撃に行き当たったんです」とStagg氏はNetwork Worldに語っています。「送信したパケットに対応しない応答を受け取ることがあると気づきました。それは、NATテーブルの内部で何らかの破損が起きていることを示していました」
NATの信頼モデルの何が破綻しているのか
NATはそもそもセキュリティ制御として設計されたものではありません。1990年代初頭にIPv4アドレスの枯渇に対する暫定策として登場し、ピア間の信頼を前提として複数のデバイスが1つのパブリックIPアドレスを共有できるようにしたものです。
「基本的には、一部のRFCの仕様が曖昧で、ピアが信頼できるネットワークにいるという前提に基づいた挙動を許容してしまっていることに起因していると思います」とStagg氏は述べています。
NATが攻撃を受けたのは今回が初めてではありません。セキュリティ研究者のSamy Kamkar氏は2010年のDEF CON 18およびBlack Hatで、NATのポート挙動を操作する初期の手法「NAT Pinning」を公表しました。同氏はその10年後にこの問題に再び取り組み、2020年に「NAT Slipstreaming」を公表、2021年にはArmisの研究者と共同でこれを拡張しました。この手法はアプリケーションレベルゲートウェイ（ALG）のコネクション追跡を悪用するもので、被害者が悪意あるWebサイトを訪問する必要がありました。これらの欠陥はいずれもすでにパッチが適用されています。
NatJackはこれらとは異なります。NATテーブルを直接操作し、ALGを必要とせず、同一NATを通じたアクティブな接続以外に被害者側の操作を一切必要としません。
この欠陥はレイヤー2にとどまりません。VLANによるセグメンテーションやスイッチポートの分離も役に立ちません。この攻撃はローカルのブロードキャストドメインではなく、レイヤー3およびレイヤー4で共有NATインフラそのものを標的とするためです。この欠陥はWindows、Linux、macOSのいずれでも確認されており、NATの実装コードベースを共有していないにもかかわらず起きていることから、個別のバグというよりも共通する設計上の前提に起因していることがうかがえます。
NatJackは4つの異なる手法から構成されており、いずれもNATテーブルが接続を追跡する仕組みに潜む同じ弱点を悪用しています。
- TCPコネクションハイジャック。攻撃者はスプーフィングしたパケットを使って被害者の接続をクローズ状態に強制的に移行させ、その結果生じたテーブルエントリを攻撃者を指すものに置き換えます。Stagg氏が特定したRFC 1337のTIME-WAIT Assassination機構により、これは通常の接続タイムアウトを待たずわずか数個のパケットで実現できます。
- DNS応答の汚染。NATを通過するUDPのDNS応答を傍受・改ざんし、被害者に気づかれることなく名前解決結果をリダイレクトする手法です。
- サービス拒否。攻撃者がNATテーブル自体を枯渇させ、同じNATを共有するすべてのデバイスの接続性を断ちます。
- 接続ポートの特定。攻撃者がアクティブな接続に対してNATが割り当てたポートを特定する手法で、この情報は他の3つの手法を支える材料となります。
開示と、まちまちだったベンダーの対応
Stagg氏はこの欠陥を責任ある形で開示しましたが、ベンダー側の反応は正式なパッチ提供から全面的な否定まで大きく分かれました。
Linuxカーネルのセキュリティチームは当初この報告を退け、あろうことか「まったくのでたらめ」とまで言い切りました。Stagg氏はこの反応に困惑したと言います。「かなり驚きました」とStagg氏は述べています。「そうした反応が返ってくるのはいささか予想外で、少し落胆させられました」
結局、Azure Kubernetes Serviceをサポートするためという名目でMicrosoftからの要請を受け、このカーネルにはパッチが適用され、CVE-2026-63913が割り当てられました。Microsoft自身のWindows NATの脆弱性（Hyper-Vに影響）にはCVE-2026-56181が割り当てられています。
一方、他のベンダーはこの発見を脆弱性として分類することを拒否しました。「これらの報告は、セキュリティ上の脆弱性というよりも設計レベルでのNATの制約です」とCisco PSIRTは述べています。「Cisco Secure FirewallおよびCisco IOS XE製品については、こうした問題のほとんど、あるいはすべてを防止できる文書化された緩和策が用意されています」
Appleも同様の立場を取りました。「この挙動は脆弱性ではなく、トランスポート層に存在する既知の制約を反映したものであると判断しています」とApple Product Securityは述べています。「現代のセキュリティモデルは、ローカルネットワークが悪意を持つ可能性があることを前提としています。だからこそ、私たちはTLSのようなエンドツーエンド暗号化に引き続き依拠しているのです」
Stagg氏は、暗号化によってNatJackがもたらす最悪の結果は和らぐものの、リスクそのものがなくなるわけではないと指摘しています。「暗号化は非常に有効です。というのも、攻撃者は接続を乗っ取ることはできても、暗号化されたデータをその接続上で送受信することはできないからです」とStagg氏は述べています。「それでも攻撃者は、そうした接続を標的にして切断することは依然として可能です」
検知と緩和策
完全なパッチがまだ提供されていない状況でも、ネットワーク管理者がリスクを抑えるために取れる対策はあります。Stagg氏は次のような対策を提案しています。
- 侵害の兆候を監視する。NATテーブルが満杯または満杯に近い状態、広範なポート範囲にわたるTCPまたはUDPパケットの大量発生、同一IPアドレスが2つの物理拠点に同時に現れる状況、異常なSYNまたはRSTパケットのシーケンスに注意してください。
- 送信元IP保護を有効にする。ルーターやファイアウォールでスプーフィングされたパケットをブロックするため、IP Source Guardなどの保護機能を有効にしてください。
- 信頼できないトラフィックをセグメント化する。信頼できないユーザーを別のサブネットまたはVLANに配置し、クライアントごとの接続数をおおむね1万未満に制限してください。
- 緩いコネクションモードを無効化する。対応している場合は、緩いコネクション追跡、ポート維持、エンドポイント非依存マッピングを無効にしてください。
- コンテナのネットワークアクセスを制限する。信頼できないコンテナやKubernetesワークロードのネットワークアクセスを無効化し、rootでの実行を避け、デフォルトのケーパビリティを削除してください。
- クラウドワークロードを分離する。信頼できないワークロードと信頼できるワークロードを同一のNATゲートウェイに配置しないようにし、サーバーレスワークロードには専用のIPを使用してください。
「攻撃バリエーションの一つは、攻撃者と被害者が異なるサブネットに存在する場合でも依然として機能します」とStagg氏は述べています。
Stagg氏は、NatJackが示す根本的な教訓は個々のパッチ適用にとどまらないと述べています。
「多くのネットワークがこの攻撃に対して脆弱であり、既存のレイヤー2による分離に常に頼れるとは限りません」とStagg氏は述べています。「過去の設計上の選択に依拠している場合、その脅威モデルは今も当時と同じままとは限りません。そうした設計上の前提を見直し、新しい脅威モデルに基づいて必要なアップデートがないかどうかを検討することが重要です」
