FragAttacks: 断片化および集約攻撃

1. はじめに

このリポジトリには FragAttacks ツールが含まれています。これは、Wi-Fi クライアントとアクセスポイントを、fragmentation（断片化）および aggregation（集約）**attacks（攻撃）**に対してテストできます。これらの脆弱性は、すべての 保護された Wi-Fi ネットワークに影響します。これらの脆弱性の詳細については、fragattacks.com を参照してください。

以下の追加リソースが利用可能です：

• USENIX Security のプレゼンテーション は、発見された脆弱性の概要を説明しています。
• すべての 割り当てられた CVE の概要が利用可能です。
• 各脆弱性の 根本原因と影響 をまとめたスライド。
• 結果として生じる攻撃と前提条件の 2ページの概要。
• 追加の背景を提供し、脆弱性をより詳細に説明する 配布資料。
• 3つの攻撃例の デモンストレーション。
• USENIX Security で公開された 研究論文。
• 一部の脆弱性を示す ネットワークキャプチャ の例。
• このツールと修正済みドライバーがプリインストールされた ライブUSBイメージ。
• 各社からの 既知のアドバイザリ のリスト

2020年8月11日以降に行われたツールの更新の詳細な概要については、変更ログ を参照してください。この変更ログには、FragAttacks ツールが基づいている hostap のバージョンに関する情報も含まれています。

WPA2 と WPA3 は CCMP および GCMP 暗号化アルゴリズムが同一であるため、これらの攻撃は両方に対して同じように適用されることに注意してください。古い WPA ネットワークはデフォルトで TKIP を使用して暗号化しており、TKIP に対する攻撃 の適用可能性は論文とウェブサイトで議論されています。Wi-Fi がその誕生以来脆弱であることを示すために、論文とウェブサイトでは WEP に対する攻撃 の適用可能性についても簡単に議論しています。

2. 対応ネットワークカード

特定のワイヤレスネットワークカードのみがサポートされています。これは、一部のネットワークカードが注入されたフレームのシーケンス番号やフラグメント番号を上書きしたり、異なる優先度のフレームを並べ替えたりする可能性があり、これがテストツールの妨げになるためです（つまり、実際には脆弱であるのに、ツールが安全であると表示する可能性があります）。以下のネットワークカードが正常に動作することを確認しています：

最後の2つの列は以下を意味します：

1. 混合モード：推奨される 混合モード でネットワークカードを使用できるかどうか。

2. インジェクションモード：インジェクションモード で、ネットワークカードを2番目のインターフェースとして使用してフレームを注入できるかどうか。

はい は、そのモードでカードがそのまま動作することを示します。修正済みドライバー/ファームウェア は、パッチが適用されたドライバーやファームウェアを使用すると互換性があることを意味します。いいえ は、そのモードがネットワークカードでサポートされていないことを意味します。テストツールは混合モードで使用することをお勧めします。

USBデバイスは仮想マシン内で使用でき、修正済みドライバーやファームウェアをこの仮想マシンにインストールできることに注意してください。ただし、仮想マシンの使用はネットワークカードの信頼性を低下させる可能性があることがわかりました。修正済みドライバー/ファームウェアをネイティブにインストールできない場合は、代わりにライブUSBイメージの使用をお勧めします。

上記のネットワークカードに関する私の経験は こちら にあります。要約すると：

• 混合モードの AWUS036ACM は、最新のドライバーで信頼性が高いようです。これが私が推奨するものです。より安価でほぼ同一のデバイスとして、MT7612U チップセット を搭載したものがあります。詳細は こちら を参照してください。

• 以前は混合モードで Technoethical N150 HGA を推奨していました。このドングルは TP-Link TL-WN722N v1.x と同一で、修正済みドライバーとファームウェアの使用が必要です。これは最もよくテストされたドングルの1つですが、入手が困難です。そのため、現在は代わりに AWUS036ACM を推奨しています。

• Intel 3160 と 8265 はサポートされており、広範囲にテストされています。時々ファームウェアがクラッシュしましたが、再起動するとネットワークカードが再び使用可能になります。Intel AX200 はこのテストツールと互換性がありません。

• WN111v2 はうまく動作するようです。ただし、広範囲にはテストしていません。

• AWUS036ACH 用のドライバーは Linux カーネルの一部ではなく、別のドライバーのインストールが必要です。Kali では、パッケージマネージャーを使用してこのドライバーをインストールできます。このカードは広範囲にはテストされていません。

上記のネットワークカードのいずれかを見つけられない場合は、動作する可能性が高い 代替ネットワークカード を探すことができます。明示的にサポートされていないネットワークカードを使用する場合は、使用する前に インジェクションテスト を最初に実行し、既知の脆弱な実装に対してツールを使用して、ツールが正しく動作することを確認することを強くお勧めします。

3. 前提条件

テストツールは、カーネル 5.8 を使用する Ubuntu 20.04 でテストされています。別の Linux ディストリビューションを使用する場合、5.12 以下のカーネルバージョンのみがサポートされる ことに注意してください。

Ubuntu 20.04 固有の手順

Ubuntu 20.04 を使用する場合、最初に以下のようにカーネル 5.8 をインストールする必要があります。既存のカーネルはインストールされたままになり、デフォルトで引き続き使用されることに注意してください：

sudo apt install linux-image-5.8.0-63-generic linux-headers-5.8.0-63-generic linux-hwe-5.8-headers-5.8.0-63 \
	linux-modules-5.8.0-63-generic linux-modules-extra-5.8.0-63-generic

Ubuntu を再起動し、起動中に Shift キーを押し続け、「Advanced options for Ubuntu」を選択し、「Ubuntu, with Linux 5.8.0-63-generic」を選択してカーネル 5.8 を起動します。GRUB の設定を編集 して、Ubuntu がこのカーネルバージョンをデフォルトで使用するようにできます。この実行中のカーネルで次の手順を続行してください。

一般的な手順

必要な依存関係をインストールします：

sudo apt-get update
sudo apt-get install libnl-3-dev libnl-genl-3-dev libnl-route-3-dev libssl-dev \
	libdbus-1-dev git pkg-config build-essential macchanger net-tools python3-venv \
	aircrack-ng rfkill firmware-ath9k-htc
# Note: on Kali linux use the package firmware-atheros instead of firmware-ath9k-htc

次に、このリポジトリをクローンし、ツールをビルドして、仮想 python3 環境を構成します：

git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research
./build.sh
./pysetup.sh

上記の手順は一度だけ実行すれば十分です。git を使用して新しいコードを取り込んだ後は、./build.sh と ./pysetup.sh を再度実行する必要があります。

4. 修正済みドライバー

修正済みドライバーを次のコマンドでインストールします：

sudo apt-get install bison flex linux-headers-$(uname -r)
git clone https://github.com/vanhoefm/fragattacks-drivers58.git fragattacks-drivers58
cd fragattacks-drivers58
make defconfig-wifi
make -j 4
sudo make install

これにより、Linux がサポートするほとんどのネットワークカード用のドライバーがコンパイルされます。私が明示的にテストしたネットワークカード用のドライバーのみをコンパイルしたい場合は、代わりに make defconfig-experiments を使用してください。次の警告が表示される可能性があります：

• make defconfig-wifi を実行すると、-Wyacc と -Wformat-overflow に関連する警告が表示される場合があります。ドライバーが正常にコンパイルされる限り、これらの警告は無視して構いません。
• インストールコマンドの実行中にも、次の警告が表示される場合があります：
  • .. needs unknown symbol .. を含むいくつかの警告。これらの警告は、ディレクトリ /lib/modules/*/updates/ を含まず、コンパイルされたドライバーが動作している限り無視して構いません。
  • SSL error と sign-file コマンドを含む繰り返しの警告。これは、カーネルモジュールのデジタル署名が失敗したことを意味します。通常は無視して構いません。
• 再起動後に cat /sys/module/mac80211/parameters/fragattack_version を実行することで、修正済みドライバーが配置されたことを確認できます。このファイルが存在する場合、修正済みドライバーは正常にインストールされています。

次に、修正済みの ath9k_htc ファームウェアをインストールします：

cd research/ath9k-firmware/
./install.sh
# Now reboot

./install.sh スクリプトは、ath9k_htc ファームウェアイメージがディレクトリ /lib/firmware/ath9k_htc にあることを前提としています。お使いのシステムでこれが当てはまらない場合は、htc_7010.fw と htc_9271.fw を適切なディレクトリに手動でコピーする必要があります。

修正済みドライバーとファームウェアをインストールした後、Wi-Fi ドングルを取り外し、システムを再起動 する必要があります。Linux カーネルが更新された場合や修正済みドライバーが更新された場合は、上記の手順を再度実行する必要があります。

デバイスがそのまま動作する場合でも、カーネルとドライバーのコードに予期しない回帰がないことを保証するため、修正済みドライバーのインストールを引き続きお勧めします。

修正済みドライバー/ファームウェアをネイティブにインストールできない場合は、修正済みドライバー/ファームウェアとテストツールが含まれる ライブUSBイメージ をダウンロードできます。あるいは、USB ネットワークカードを備えた仮想マシンを使用することもできますが、実際には仮想マシンの使用は信頼性が低いことがわかりました。

5. 使用前の準備

テストツールを使用するたびに、まず仮想 python 環境を root としてロードする必要があります。これには次のコマンドを使用します：

cd research
sudo su
source venv/bin/activate

次に、テストツールの妨げにならないように、ネットワークマネージャーで Wi-Fi を無効 にします。また、他のネットワークサービスが送信トラフィックを発生させていないことを確認してください。./droptraffic.sh を実行して iptables でトラフィックをブロックすることで確認できます（再起動すると元に戻せます）。必要に応じて sudo airmon-ng check を実行して、ワイヤレスネットワークカードを使用していてツールの妨げになる可能性のある他のプロセスを確認できます。

テストツールはクライアントと AP の両方をテストできます：

• AP をテストする場合：research/client.conf を編集して テスト対象の AP を設定 します。これは標準の wpa_supplicant 設定ファイルです。サポートされているすべてのオプションの概要については、hostap ドキュメント を参照してください。

• クライアントをテストする場合：--ap パラメータを指定してテストツールを実行する必要があります（後述参照）。これにより、ツールは名前 testnetwork、パスワード abcdefgh の AP を作成します。テストしたいクライアントでこのネットワークに接続してください。デフォルトでは、クライアントは DHCP を使用して IP を要求する必要があります。作成される AP のプロパティ（チャンネルなど）を編集するには、research/hostapd.conf を編集できます。

6. インターフェースモード

6.1. 混合モード

このモードではワイヤレスネットワークカードが1枚だけ必要ですが、通常は修正済みドライバーやファームウェアが必要です。修正済みドライバー/ファームウェアのインストール方法は 修正済みドライバー を、互換性のあるネットワークカードは 対応ネットワークカード を参照してください。このモードでは、テストツールを次のように実行します：

./fragattack.py wlan0 [--ap] $COMMAND

$COMMAND に指定できる値は 脆弱性のテスト と 拡張脆弱性テスト に記載されています。

このモードの利点の1つは、スリープ状態に入る可能性のあるクライアントをテストするときにもかなりうまく機能することです。それでも、可能であれば、テスト対象のクライアントのスリープ機能を無効にすることをお勧めします。スリープモードの処理 を参照してください。

6.2. インジェクションモード

このモードでは2枚のワイヤレスネットワークカードが必要です。1枚は AP またはクライアントとして動作し、もう1枚はフレームの注入に使用されます。利点は、このモードが修正済みドライバーを必要とせずに動作する可能性があることです。このモードでは、テストツールを次のように実行します：

./fragattack.py wlan0 --inject wlan1 [--ap] $COMMAND

ここで、インターフェース wlan0 は正当なクライアントまたは AP として動作し、wlan1 はフレームの注入に使用されます。wlan0 には、Linux で通常のクライアントまたは AP モードをサポートする任意のカードを使用できます。wlan1 には、対応ネットワークカード に従ってインジェクションモードをサポートするカードを使用する必要があります。

このモードでクライアントをテストする場合、クライアントがスリープ状態のときにフレームが注入される可能性があります。これにより攻撃が失敗するため、クライアントがスリープ状態にならないようにする必要があります。

6.3. Hwsim モード

このモードは実験的であり、研究目的のみです。詳細については hwsim モードの詳細 を参照してください。

7. 脆弱性のテスト

インターフェースモード で説明されているようにテストツールを実行し、$COMMAND を以下の表のコマンドのいずれかに置き換えてデバイスをテストできます。クライアントは DHCP を使用して IP を要求することを前提としています（そうでない場合は 静的 IP 設定 を参照）。特に記載がない限り、すべてのコマンドはクライアントと AP の両方に対して機能します。

ツールは、指定された $COMMAND に対応する攻撃に対してデバイスが脆弱な場合に TEST COMPLETED SUCCESSFULLY を出力し、脆弱でない場合に Test timed out! Retry to be sure, or manually check result を出力します。テストが完了したら、CTRL+C でテストツールを終了できます。ほとんどの攻撃には、異なる $COMMAND 値によって表されるいくつかのわずかなバリアントがあります。

一部のテストの結果を確認するには、テスト対象デバイスで tcpdump または wireshark を実行する必要があります（以下の表に tcpdump を使用する必要があるかどうかが示されています）。この tcpdump パケットキャプチャには、PHY および MAC レイヤーの処理を通過したパケットのみを含める必要があります。たとえば、Linux では、このキャプチャはワイヤレスインターフェースがモニターモードではなく「managed」または「ap」モードのときに作成する必要があります。つまり、キャプチャには Wi-Fi レイヤーでの処理を通過したパケットのみが含まれます。AP で tcpdump を実行しなくても一部のテストを実行できる方法については、AP での tcpdump の回避 を参照してください。

テスト環境を検証する ために、以下の表の最初のコマンドは成功するはずの通常の ping を送信します。2番目のコマンドは ping を2つの断片化された Wi-Fi フレームとして送信し、テスト対象デバイスがフラグメンテーションをサポートしていないという稀な場合にのみ失敗するはずです。これらのテストのいずれかが機能しない場合は、ネットワークカードのインジェクションテスト の手順に従って、ネットワークカードがフレームを正しく注入していることを確認してください。テスト対象のクライアントがスリープモードに入る可能性がある場合は、スリープモードの処理 を参照してください。

3番目、4番目、5番目のコマンドは攻撃ではなく、デバイスの基本的なデフラグメンテーション動作を検証するものであり、表の下でさらに説明します。

コマンドが CVE にどのように対応するかを以下に示します。実装の欠陥については参照 CVE 識別子を記載していますが、実装の脆弱性は通常、影響を受けるコードベースごとに固有の CVE を受け取るため、ベンダーが異なる CVE を使用する場合があることに注意してください。それでも、発見された実装の欠陥の各タイプを簡単に参照できるように、これらの参照 CVE を常に使用することをお勧めします。

7.1. 正常性チェック

• ping：このテストは常に成功する必要があります。失敗した場合、テスト環境に何か問題があります。- ping I,E,E: このテストは、最近のラップトップ、スマートフォン、APのすべてで成功するはずです。失敗した場合、テスト設定に問題がある可能性が高いです。修正として --icmp-size 100 パラメータを追加してみてください。この追加パラメータで動作する場合は、他のすべてのテストもこの追加パラメータを付けて実行する必要があります。このテストが正当な理由で失敗するのを見たのは、テスト対象デバイスがフラグメント化されたフレームの受信をサポートしていない場合だけです。これは、軽量なIoTデバイスや、例えばOpenBSDなどで発生し得ます。

7.2. 基本的なデバイスの動作

• ping I,E,E --delay 5: このテストは、2つのフラグメント間で許容される最大遅延を確認するために使われます。このテストが動作しない場合は、--delay 1.5 以下で再試行してください。例えば、Linuxは2秒後にフラグメントをメモリから削除するため、遅延1.8なら動作しますが、2.2では応答がありません。許容される最大遅延が小さい場合、他のテストで送信するすべてのフラグメントは、この最大許容遅延以内に送信する必要があります。そうしないと、テストは簡単に失敗し、デバイスが実際には脆弱であるにもかかわらず、攻撃に対して脆弱ではないと結論付けてしまう可能性があります。

• ping-frag-sep: このテストは、無関係なフレームによって分離されたフラグメント化されたWi-Fiフレームを送信します。つまり、最初のフラグメントを送信し、次に（通常の）無関係なWi-Fiフレームを送信し、最後に2番目のフラグメントを送信します。このテストが失敗する場合、（デフォルトの）混在鍵攻撃とキャッシュ攻撃もおそらく失敗します（これらは2つのフラグメントの間に他のフレームを送信する必要があるため）。このテストは、受信側がフラグメントのパケット番号が連続しているかどうかを確認する場合にも失敗します（次のテスト ping-frag-sep --pn-per-qos を参照）。

• ping-frag-sep --pn-per-qos: 上記と同じですが、--pn-per-qos パラメータを追加することで、ping要求の両方のフラグメントが連続したパケット番号（PN）を持つことが保証されます。これは、セキュリティ上、受信側が検証すべき事項です。残念ながら、私たちの結果の開示以前は、多くの実装がPNが連続しているかどうかを検証していませんでした。このテストは、受信側がQoS TIDごとの最新の受信パケットカウンタを追跡していない場合に失敗する可能性があります。その場合、--pn-per-qos パラメータを含む他のテストは無視して構いません。

7.3. A-MSDU攻撃テスト（§3 -- CVE-2020-24588）

ping I,E --amsdu テストは、実装が非SPP A-MSDUを サポートしているか を確認します（デバイスがCVE-2020-24588に対して脆弱かどうかは確認しません）。攻撃を防ぐには、理想的にはネットワークがSPP A-MSDUの使用を義務付け、すべての非SPP A-MSDUを破棄する必要があります。しかし、現在ほとんどのベンダーは、その代わりに場当たり的な緩和策を実装しています（論文のセクション7.2を参照）。このため、デバイスがアグリゲーション（A-MSDU）攻撃（CVE-2020-24588）に対して 脆弱かどうか を確認するには、次の2つのテストを使用する必要があります。

• amsdu-inject: このテストは、論文のセクション3.2で説明されているA-MSDU注入攻撃をシミュレートします。具体的には、先頭が有効なLLC/SNAPヘッダーでもあるA-MSDUフレームを送信します（これは私たちの参照攻撃でも起こることだからです）。このテストが成功した場合、デバイスはCVE-2020-24588に対して脆弱です。

• amsdu-inject-bad: 一部のデバイスは、有効なLLC/SNAPヘッダーで始まるA-MSDUフレームを誤って解析するため、上記のテストが失敗します。その場合は、代わりに amsdu-inject-bad を試してください（論文のセクション3.6を参照）。このテストが成功した場合、攻撃の影響は、そのようなフレームを正しく解析する実装と実質的に同じであり、デバイスがCVE-2020-24588に対して脆弱であることを意味します。

7.4. 混在鍵攻撃テスト（§4 -- CVE-2020-24587）

• APに対して混在鍵テストを実行する場合、APが新しい4ウェイハンドシェイクを実行してセッションキー（PTK）を定期的に（例えば毎分）更新するように設定する必要があります。ツールは、このPTK再鍵付けハンドシェイクを待っているときに Client cannot force rekey. Waiting on AP to start PTK rekey と表示します。一部のAPに対しては、テストツールは --rekey-req パラメータを追加してPTKの更新を要求することもできるため、APを定期的に鍵を更新するように設定する必要はありません。

• 一部のAPは、セッションキー（PTK）を定期的に更新するように設定できません。そのようなAPに対しては、代わりにキャッシュ攻撃テストを試すことができます。APがキャッシュ攻撃に対して脆弱な場合、混在鍵攻撃に対しても脆弱である可能性が高いです（これを矛盾する強い証拠がない限り、例えばコード監査が混在鍵攻撃が防止されていることを示す場合など）。APがキャッシュ攻撃に対して脆弱でない場合、混在鍵攻撃に対する感受性については何も言えません。その場合は、代わりにコード監査を行うことをお勧めします。

• ping I,F,BE,AE --pn-per-qos: 追加の --pn-per-qos パラメータにより、注入された両方のフラグメントが連続したパケット番号を持つことが保証されます。これは、特定のデバイス（例えばLinux）に対して混在鍵攻撃を成功させるために必要です。

• 一部のデバイスは4ウェイハンドシェイクの実装が異なるため、これらのテストが成功するかどうかに影響します。テストが失敗する場合は、拡張脆弱性テスト に記載されている混在鍵攻撃テストも実行することをお勧めします。

7.5. キャッシュ攻撃テスト（§5 -- CVE-2020-24586）

• APをテストする場合、ツールは最初のフラグメントを送信し、次にAPとの 再関連付け を試み、最後に2番目のフラグメントを送信します。ただし、すべてのAPが再関連付けプロセスを適切にサポートしているわけではありません。その場合は、表に示すように --full-reconnect オプションを追加してください。これにより、テストツールは最初のフラグメントを送信した後に 非認証 を行います。

• クライアントをテストする場合、ツールは最初のフラグメントを送信し、クライアントを 切断 し、クライアントが再接続したら2番目のフラグメントを送信します。理想的には、クライアントは切断フレームを送信した後すぐに再接続します。これには、テスト中のクライアントで他のすべてのネットワークを無効にする必要があるかもしれません。また、一部のクライアントは切断を適切に処理していないように見えることも分かりました。その場合は、表に示すように --full-reconnect オプションを追加して、代わりに非認証フレームを送信できます。

• キャッシュ攻撃テストは各テストを数回実行するのが最善だと分かりました。実装が 脆弱である にもかかわらず、キャッシュ攻撃テストが失敗することがあります。これは、背景ノイズや、他のデバイスがテスト対象デバイスにフレームを送信することなどが原因である可能性があります。

• ping I,E,R,AE [--full-recon]: ここでは、テスト対象デバイスとの再接続直後に2番目のフラグメントが送信されます。これは、デバイスが短時間後にフラグメントをメモリからクリアする場合に重要です。full-recon は full-reconnect の短縮形であることに注意してください。

• ping I,E,R,E [--full-recon]: ここでは、テスト対象デバイスとの再接続から1秒後に2番目のフラグメントが送信されます。これは、ハンドシェイクの完了とネゴシエートされた鍵のインストールの間にわずかな遅延がある場合に役立ちます。

• 全体的に、デバイスがキャッシュ攻撃に対して脆弱かどうかをテストするのは面倒な場合があります。そのため、ネットワークから切断または非認証した後、または再関連付けした後に、フラグメントがメモリに残るかどうかを確認するコード監査も行うことをお勧めします（これはデバッグ出力を使って動的に確認することもできます）。フラグメントがメモリに残る場合、それが悪用可能かどうかが不明であっても、リスクとして考慮する必要があります。これは、実装にバッファオーバーフローがあることを知っているが、まだその悪用方法を知らないのと似ています。

7.6. 非連続PN攻撃（§6.2 -- CVE-2020-26146）

私たちの実験では、このテストはLinuxと、フラグメンテーションをサポートしないデバイスに対してのみ失敗しました。

7.7. 平文/暗号化混在攻撃（§6.3 -- CVE-2020-26147/26140/26143）

• ping I,E,P と linux-plain: このテストが成功した場合、結果として生じる攻撃は論文のセクション6.3で説明されています。要約すると、A-MSDUまたはキャッシュの脆弱性と組み合わせることで、パケットを注入するために悪用される可能性があります。他の脆弱性と組み合わせない場合、影響は実装固有です（CVE-2020-26147）。

• ping I,P,E: このテストが成功した場合、ネットワークがフラグメンテーションを使用している なら、デバイスに向けて平文フレームを注入するのは簡単です（CVE-2020-26147）。

• ping I,P: このテストが成功した場合、実装は保護されたWi-Fiネットワーク内で平文フレームを受け入れ、簡単なパケット注入を可能にします（CVE-2020-26140）。

• ping I,P,P: このテストが成功した場合、実装は保護されたWi-Fiネットワーク内で フラグメント化された 平文フレームを受け入れ、簡単なパケット注入を可能にします（CVE-2020-26143）。

7.8. ブロードキャストフラグメント攻撃テスト（§6.4 -- CVE-2020-26145）

次の2つのテストは、自動的に再送信されないブロードキャストフレームを送信するため、複数回実行する ことをお勧めします。これは、背景ノイズがテスト対象デバイスによる注入されたブロードキャストフレームの受信を妨げる可能性があるためです。私の実験では、主にクライアントが影響を受けました（テストしたAPのうち、Free/NetBSDのものだけが影響を受けました）。

• ping I,D,P --bcast-ra: 接続後に、平文でブロードキャストされる2番目のフラグメント内でユニキャストpingを送信します。この攻撃バリアントの結果は、テストツールによって自動的に確認されます。

• ping D,BP --bcast-ra: ここでは、ネットワークに接続している間（つまり4ウェイハンドシェイク中）に上記のフレームが送信されます。これは、一部のクライアントとAPが4ウェイハンドシェイクを完了する前にのみ脆弱であるため重要です。このテストの結果を確認するには、被害者上でwiresharkまたはtcpdumpを実行し、注入されたping要求が被害者によって受信されるかどうかを監視する必要があります。tcpdumpではフィルタ icmp を使用でき、wiresharkでもフィルタ frame contains "test_ping_icmp" を使用すると、このping要求をより簡単に検出できます。私の実験では、主にクライアントが影響を受けました。

7.9. A-MSDU EAPOL攻撃テスト（§6.5 -- CVE-2020-26144）

• eapol-amsdu I,P: これは、論文のセクション6.5で説明されている実装固有の脆弱性に対する標準テストです。クライアントとAPの両方が脆弱になる可能性があります。その結果はテストツールによって自動的に確認されます。

• BP で終わるテスト（eapol-amsdu BP と eapol-amsdu-bad BP）: これらのテストは、4ウェイハンドシェイクの実行中に悪意のあるフレームを注入します。このテストの結果を確認するには、被害者上でwiresharkまたはtcpdumpを実行し、注入されたping要求が被害者によって受信されるかどうかを監視する必要があります。tcpdumpではフィルタ icmp を使用でき、wiresharkでもフィルタ frame contains "test_ping_icmp" を使用すると、このping要求をより簡単に検出できます。

• eapol-amsdu-bad で始まるテスト（eapol-amsdu-bad BP と eapol-amsdu-bad I,P）: 一部の実装は、最初の6バイトがEAPOLの有効なRFC1042ヘッダーにも等しいA-MSDUフレームを誤って処理します。これらの実装をテストするには、eapol-amsdu-bad テストバリアントを使用する必要があります。このテストが成功した場合、攻撃の影響は、そのようなフレームを正しく解析する実装と同一であることに注意してください（詳細は論文のセクション3.6および6.6を参照）。

7.10. トラブルシューティングチェックリスト

テストツールが動作していないように見える場合は、以下を確認してください：

1. 他のプロセスがネットワークカードを使用していないことを確認してください（例：ネットワークマネージャを終了する）。

2. 以前はすべて動作していた場合は、Wi-Fiドングルを取り外し、コンピュータまたは仮想マシンを再起動してから、もう一度試してください。また、disable-hwcrypto.sh スクリプトを使用してハードウェア暗号化を無効にしてみてください（このスクリプトを実行した後、コンピュータを再起動してください）。

3. テスト対象デバイスがスリープ状態に入らないようにしてください（注入されたフレームを逃す原因になります）。スリープ状態に入る可能性のあるクライアントをより適切に処理できるため、混在モード でテストツールを実行することをお勧めします。

4. 注入テスト を実行して、注入が正しく機能していることを確認してください。また、20 MHzチャネルが使用されていることを確認してください。他のチャネルでの注入はテストされていません。

5. マシンがテストを妨害するバックグラウンドトラフィックを生成していないことを確認してください。特に、OSのネットワークを無効にし、DHCPクライアント/サーバーを手動で終了するなどしてください。使用前の注意 も参照してください。

6. 正しいネットワークに接続していることを確認してください。client.conf を再確認してください。

7. テスト対象のAPが暗号化アルゴリズムとして（AES-）CCMPを使用していることを確認してください。TKIPやGCMPなどの他の暗号化アルゴリズムはサポートされていません。

8. gitを使用してコードを更新した場合は、./build.sh と ./pysetup.sh を再度実行してください（前提条件 を参照）。パッチ適用済みドライバーが更新された場合は、それらも再コンパイルすることを忘れないでください。

9. 仮想マシンを使用している場合は、代わりにライブUSBイメージからテストツールを実行してみてください。

10. テスト対象デバイスがICMP ping要求をブロックしないことを確認してください。pingに応答しない場合は、デバイス上でtcpdumpまたはwiresharkを実行するか、ICMP非サポート に記載されている他の方法を試すことができます。

11. 追加パラメータ --debug 2 を指定してツールを実行し、wpa_supplicantまたはhostapdとテストツール自体から追加のデバッグ出力を取得してください。

12. 2つ目のモニターインターフェースを使用して、フラグメント間で他のフレームが送信されていないことを確認してください。例えば、私のIntelデバイスはフラグメント間にBlock Ack Response Actionフレームを送信することがあり、これがテスト対象デバイスのデフラグメンテーションプロセスに干渉しました。

13. ワイヤレスネットワークカードに必要な場合は、修正済みファームウェアを使用していることを再確認してください。テストツールは ath9k_htc デバイスに対してこれを自動的にチェックします。テストツールは修正済みドライバーを使用しているかどうかも自動的にチェックしますが、特定のLinuxディストリビューションで手動で再確認することをお勧めします。

8. 拡張脆弱性テスト

実装のバリエーションのため、特定の脆弱性、特に混在鍵攻撃とキャッシュ攻撃は、実際に確認することが簡単ではない場合があります。したがって、これらの攻撃を防ぐための明示的なチェックがコードにある場合にのみ、デバイスを安全と見なすことをお勧めします。さらに、時間が許せば、次のより高度なテストもお勧めします。これらは新しい脆弱性を発見する可能性は低いですが、通常のテストでは検出できない攻撃のバリアントや特定のデバイス動作を明らかにする可能性があります。

脆弱性のテスト の通常のテストで特定の脆弱性クラスの存在がすでに確認されている場合、その脆弱性の他の攻撃バリアントをテストする必要性はほとんどありません。特に注記がない限り、すべてのコマンドはクライアントとAPの両方に対して機能します。

8.1. A-MSDU攻撃テスト（§3 -- CVE-2020-24588）

これらの2つのテストを実行する価値があるのは、メインテスト ping I,E --amsdu が失敗し、テスト対象デバイスがA-MSDUフレームをどのように処理するかをよりよく理解したい場合のみです。

• ping I,E --amsdu-fake: このテストが成功した場合、受信側はすべてのフレームを通常のフレームとして扱います（つまり、A-MSDUフレームをサポートしていません）。この動作は理想的ではありませんが、攻撃者が実際にこれを悪用する可能性は低いです（論文のセクション3.5を参照）。

• ping I,E --amsdu-fake --amsdu-spp: このテストが成功した場合、受信側は受信したすべてのフレームのQoS A-MSDUフラグを認証します（つまり、受信時にそれをゼロにマスクしません）が、その後、受信したすべてのフレームを通常のフレームとして扱います（つまり、実際のA-MSDUフレームの受信をサポートしていません）。この動作は理想的ではありませんが、攻撃者が実際にこれを悪用する可能性は低いです（論文のセクション3.5を参照）。

8.2. 混在鍵攻撃テスト（§4 -- CVE-2020-24587）

私がテストしたほとんどのデバイスは混在鍵攻撃に対して脆弱です。通常の混在鍵攻撃テストがデバイスが脆弱ではないことを示しているが、ping-frag-sep テストは成功する場合、これらの代替混在鍵攻撃テストを試すことを強くお勧めします。As a general remark, when testing an AP, you can add the --rekey-req parameter to any of the mixed key attack tests to actively request a rekey handshake. A low number of APs will then perform the rekey handshake. Most APs will ignore this request though, and have to be explicitly configured to regularly renew the session key (PTK).

Some notes regarding the tests:

• ping I,F,BE,E and ping I,E,F,AE: These are fairly straightforward mixed key attack tests where both fragments are injected at different times.

• ping I,E,F,AE --rekey-plain: Some drivers (e.g. MediaTek) will perform the rekey handshake in plaintext. To test devices that use such a driver you must add the --rekey-plain parameter.

• ping I,E,F,AE --rekey-plain --rekey-req: This particular combination is useful to test routers that use a MediaTek driver. These routers perform the rekey handshake in plaintext, and the client can actively request a rekey handshake.

• ping I,E,F,AE --rekey-early-install: A low number of clients (incorrectly) install the key too early during a pairwise session rekey. To reliably test these clients, add the --rekey-early-install parameter. This test is not meaningfull against APs.

• ping I,E,F,E [--rekey-pl] [--rekey-req]: This test variant is the same as the previous ping I,E,F,AE * tests, except that the second fragment is send 1 second after the 4-way handshake. This can be important because in a low number of devices there is a small delay before the new key is installed. Note that is a shorthand of .

Finally, in case the test ping-frag-sep doesn't succeed, you should try the following mixed key attack test:

• ping I,F,BE,AE --freebsd: This essentially performs the rekey handshake against a FreeBSD implementation, or a driver that borrows code from FreeBSD, without affecting the defragmentation process of data frames. See Appendix E in the paper for details.

8.3. キャッシュ攻撃テスト (§5 -- CVE-2020-24586)

• ping I,E,R,AE --freebsd --full-reconnect: このテストは、FreeBSD AP、または FreeBSD からコードを借用したドライバーがキャッシュ攻撃に対して脆弱かどうかを確認するために使用できます。このテストがどのように機能するかの詳細は、論文の付録Eを参照してください。--full-reconnect パラメータなしでもこのテストを試す必要があります。このテストはクライアントに対しても機能しますが、クライアントが影響を受ける可能性は低いです。

• ping I,E,R,AP --freebsd --full-reconnect: このテストは、FreeBSD AP、または FreeBSD からコードを借用したドライバーに対するバリアントで、AP との再接続後に2番目のフラグメントが平文で送信されます。FreeBSD 上の一部のドングルでは、このテストの方が信頼性が高く、再接続後も古いフラグメントが AP のメモリに残ることを証明できます。--full-reconnect パラメータなしでもこのテストを試す必要があります。このテストはクライアントに対しても機能しますが、クライアントが影響を受ける可能性は低いです。

• ping I,E,R,AP [--full-reconnect]: このテストでは、2番目のフラグメントが平文で送信されます。これは、テスト対象のデバイスが4ウェイハンドシェイクの直後にキーをインストールしない場合に役立ちます。このテストが成功した場合、デバイスがネットワークに（再）接続した後もフラグメントをメモリに保持することを示しており、キャッシュ攻撃に対して脆弱であることを意味します。上記の2つのコマンドとは異なり、このテストはクライアント（およびAP）に対しても実行するのに役立ちます。

8.4. 混合平文/暗号化攻撃 (§6.3 -- CVE-2020-26147)

• ping I,E,E --amsdu: このテストは、断片化された A-MSDU フレームを送信しますが、すべてのデバイスが正しく受信できるわけではありません。これは脆弱性をテストするものではありません。代わりに、このテストは「混合平文/暗号化攻撃」の実際の悪用可能性を判断するために役立ちます。つまり、このテストが成功した場合、2番目のフラグメントを平文で送信できると（テスト ping I,E,P）、デバイスへの攻撃が容易になります。詳細は論文のセクション6.3を参照してください。

• ping I,E,P,E と linux-plain 3: 他のすべての混合平文/暗号化攻撃テストが成功しなかった場合は、これらの追加テストも試すことができます。これによって新しい脆弱性が明らかになる可能性はかなり低いと思います。

8.5. ブロードキャストフラグメント攻撃テスト (§6.4 の拡張)

以下のテストのほとんどはブロードキャストフレームを送信しますが、これらは自動的には再送信されないため、複数回実行することをお勧めします。これは、背景ノイズによってテスト対象デバイスが注入されたブロードキャストフレームを受信できない可能性があるためです。私の実験では、主にクライアントが影響を受けました。ほとんどのクライアントは、ネットワークに接続している間（つまり、4ウェイハンドシェイクの実行中）にのみ脆弱です。

• ping I,P --bcast-ra: これは、平文のブロードキャストWi-Fiフレーム内にユニキャストICMP ping要求を送信します (CVE-2020-26145)。このテストは、クライアントとAPの両方に対して実行できます。

• ping BP --bcast-ra: 上記のテスト ping I,P --bcast-ra と似ていますが、pingはクライアントがネットワークに認証される前、つまり4ウェイハンドシェイクの実行中に送信されます (CVE-2020-26145)。クライアントがフレームを受け入れるかどうかを確認するには、tcpdump または wireshark を実行する必要があります。tcpdump ではフィルター icmp を使用でき、wireshark でもフィルター frame contains "test_ping_icmp" を使用すると、このping要求をより簡単に検出できます。

• ping BP --bcast-ra --bcast-dst: このテストは前のものと同じですが、対象のAPで tcpdump を実行できない場合に役立ちます。このテストはAPに対してのみ意味があることに注意してください。このテストの追加の --bcast-dst パラメータにより、脆弱なAPが注入されたping要求を接続中のすべてのクライアントにブロードキャストします。言い換えれば、APが脆弱かどうかを確認するには、このコマンドを実行し、APに接続されている2台目のデバイスでフィルター icmp または frame contains "test_ping_icmp" を使用してブロードキャストWi-Fiフレームを監視します。

• ping BP [--bcast-dst]: これは、上記の2つのテスト ping BP --bcast-ra [--bcast-dst] のバリアントですが、ping要求がブロードキャストフレームではなく平文のユニキャストフレームで送信される点が異なります（CVEはまだ割り当てられていません - CVE-2020-26145に関連しています）。このテストはクライアントとAPの両方に対して実行する必要があります。pingはクライアントがネットワークに認証される前（つまり4ウェイハンドシェイクの実行中）に送信されるため、デバイスがこのフレームを受け入れるかどうかを確認するには tcpdump または wireshark を実行する必要があります。あるいは、APをテストする場合は、上記のテストと同様に --bcast-dst パラメータを追加し、APに接続されている2台目のデバイスで tcpdump または wireshark を使用して、フィルター icmp または frame contains "test_ping_icmp" を使用します。

• eapfrag BP,BP: これは、クライアントが認証される前に実行される、上記のブロードキャストフラグメントテストの特殊化です。これは、流出したコードの分析に基づく_非常に実験的な_攻撃です。まず、EAPOLヘッダーで始まる平文フラグメントを送信します。これは、4ウェイハンドシェイクがまだ実行中であるため受け入れられます。次に、同じシーケンス番号を持つ2番目のブロードキャストフラグメントを送信します。流出したコードの分析に基づくと、一部のデバイスは（前のフラグメントが許可されたため）このフラグメントを受け入れる可能性がありますが、その後のコードは（フラグメントがブロードキャストされているため）それを通常のフレームとして処理します。フレームが正しく受信されたかどうかを判断するには、被害者上で tcpdump または wireshark を使用する必要があります。たとえば、フィルター icmp または frame contains "test_ping_icmp" を使用します。通常のバリアントが機能しない場合の代替バリアントは eapfrag BP,AE です。

8.6. A-MSDU EAPOL攻撃テスト (§6.5 -- CVE-2020-26144)

このテストは、eapol-amsdu[-bad] BP テストを実行したいが、AP上で tcpdump または wireshark を実行できない場合に使用できます。このテストはAPに対してのみ意味があります。eapol-amsdu[-bad] BP --bcast-dst コマンドは、脆弱なAPが注入されたping要求を接続中のすべてのクライアントにブロードキャストさせます。言い換えれば、APが脆弱かどうかを確認するには、このコマンドを実行し、APに接続されている2台目のデバイスでフィルター icmp または frame contains "test_ping_icmp" を使用してブロードキャストWi-Fiフレームを監視します。

8.7. APがEAPOLを転送する攻撃テスト (§6.6 -- CVE-2020-26139)

• eapol-inject 00:11:22:33:44:55: このテストはAPに対してのみ意味があります。このテストを実行するには、2台目のデバイスを使用してネットワークに接続し、MACアドレス 00:11:22:33:44:55 をこの2台目のデバイスのMACアドレスに置き換える必要があります。認証される_前_に、テストツールは最終宛先をこの2台目のデバイスとするEAPOLフレームをAPに送信します。APがEAPOLフレームを2台目のデバイスに転送した場合、そのAPは脆弱と見なされます。APがEAPOLフレームを転送するかどうかを確認するには、2台目のデバイスで tcpdump または wireshark を実行する必要があります。2台目のデバイスの無線インターフェースで復号化されたトラフィックを監視する場合は、wireshark フィルター frame contains "forwarded_data" を使用できます（または、すべてのEAPOLフレームを監視するには tcpdump フィルター ether proto 0x888e を使用します）。詳細と影響については、論文のセクション6.6を参照してください。

• eapol-inject-lage 00:11:22:33:44:55: 上記の eapol-inject テストが成功した場合、eapol-inject-large も試して、この脆弱性を悪用して暗号化フラグメントの送信を強制できるかどうかを確認できます。これを確認するには、再び tcpdump または wireshark を使用する必要があります。wireshark または tshark フィルター (wlan.fc.frag == 1) || (wlan.frag > 0) を使用して、断片化されたフレームを検出します。この攻撃が成功することは非常に稀でした。

8.8. フラグメンテーション非サポート攻撃テスト (§6.8 -- CVE-2020-26142)

• ping I,D,E: このテストが成功した場合、クライアントまたはAPは（デ）フラグメンテーションをサポートしていませんが、攻撃に対しては依然として脆弱です。問題は、受信者が_最後の_フラグメントを完全なフレームとして扱うことです。詳細とこれを悪用する方法については、論文のセクション6.8を参照してください。

• ping I,E,D: このテストが成功した場合、クライアントまたはAPは_最初の_フラグメントを完全なフレームとして扱います。この動作は理想的ではありませんが、これだけで実際に悪用できるかどうかは現在のところ不明です。

9. 高度な使用法

9.1. ネットワークカード注入テスト

注入モード

スクリプト test-injection.py は、_注入モード_を使用するときにフレームが正しく注入されるかどうかをテストするために使用できます。

./test-injection.py wlan0 wlan1

ここでは、ネットワークカード wlan0 がフレームを正しく注入するかどうかをテストし、ネットワークカード wlan1 を使用してフレームが正しく注入されるかどうかを監視します。このテストスクリプトを機能させるには、両方のインターフェースがモニターモードをサポートしている必要があることに注意してください。

2台目のネットワークカードがない場合は、次のコマンドを使用して部分的な注入テストを実行できます。

./test-injection.py wlan0

残念ながら、上記のテストはカーネルが注入されたフレームのフィールドを上書きするかどうかのみをテストでき、ファームウェアやワイヤレスチップ自体がフィールドを上書きするかどうかはテストできません。

混合モード

_混合モード_でネットワークカードがフレームを正しく注入するかどうかをテストするには、私が推奨するモードですが、次の2つのコマンドを実行できます。

./fragattack.py wlan0 ping --inject-test wlan1
./fragattack.py wlan0 ping --inject-test wlan1 --ap

ここでは、2台目のネットワークカード wlan1 を使用して注入されたフレームを監視することにより、wlan0 がフレームを正しく注入するかどうかをテストします。1つ目のコマンドは、クライアントとして動作するときに混合モードを使用してフレームが正しく注入されるかどうかをテストし、2つ目のコマンドはAPとして動作するときに混合モードを使用してテストします。テストを開始するには、クライアントがネットワークに接続できる必要があり、APは注入テストを開始する前にクライアントが接続するのを待ちます（クライアントとAPの接続設定の構成については 使用前の準備 を参照してください）。

混合モードで wlan0 の再送信動作もテストしたい場合は、以下を実行できます。

./fragattack.py wlan0 ping --inject-test-postauth wlan1
./fragattack.py wlan0 ping --inject-test-postauth wlan1 --ap

2台目のネットワークカードがない場合は、次のコマンドを使用して部分的な混合モード注入テストを実行できます。

./fragattack.py wlan0 ping --inject-test[-postauth] self
./fragattack.py wlan0 ping --inject-test[-postauth] self --ap

残念ながら、上記のテストはカーネルが注入されたフレームのフィールドを上書きするかどうかのみをテストでき、ファームウェアやワイヤレスチップ自体がフィールドを上書きするかどうかはテストできません。

テスト結果の解釈

テストスクリプトは、どのテストが成功したか失敗したかについての詳細な出力を提供し、最後に ==> The most important tests have been passed successfully または、重要なテストが失敗したか、特定の注入フレームをキャプチャできなかったことを示すメッセージのいずれかを出力します。

注入スクリプトは最も重要な動作のみをテストすることに注意してください。注入が正しく機能していることを確認する最良の方法は、既知の脆弱なデバイスに対して脆弱性テストを実行し、ツールがそのデバイスを脆弱として正しく識別することを確認することです。

特定の注入フレームをキャプチャできなかった場合、その原因は背景ノイズ、またはテスト対象のネットワークカードが特定のフレームを正しく注入できないこと（例: Intel AX200 のファームウェアは断片化されたフレームを注入するときにクラッシュする）である可能性があります。また、フレームが実際には正しく注入されているが、フレームが正しく注入されているかどうかを監視するために使用されるネットワークカード（上記の例では wlan1）が信頼できず、たとえば背景ノイズのためにほとんどのフレームを欠落している可能性もあります。別のチャネルでもテストを実行してみてください。

注入テストが機能しているのに攻撃テストを確実に実行できない場合、テスト対象のデバイスがスリープモードに入っている可能性があります。この問題に関する追加の注意事項については、スリープモードの処理 を参照してください。

手動確認の注意事項

wireshark を使用してデバイスの注入動作を検査する場合は、モニターモードの2台目のデバイスを使用して、フレームがどのように注入されるかを確認することをお勧めします。

フレームの注入に使用されるインターフェースを開いた場合、注入されたフレームは2回表示されるはずです: (1) 最初に、送信しているツールによって注入されたフレームが表示され、次に (2) ドライバーによって注入された方法で2回目に表示されます。カーネルが特定のフィールドを上書きした場合、これら2つのフレームはわずかに異なる可能性があります。注入されたフレームが1回しか表示されない場合は、カーネルによってドロップされた可能性があります。

9.2. 静的IP構成

テスト対象のデバイスがDHCPをサポートしていない場合は、テストツールが使用するIPアドレスを手動で指定できます。例:

./fragattack.py wlan0 [--ap] ping --inject wlan1 --ip 192.168.100.10 --peerip 192.168.100.1

ここでは、テストツールはIPアドレス 192.168.100.10 を使用し、ピアIPアドレス 192.168.100.1 に対してping要求を注入します。

テストがDHCPを使用してIPアドレスを取得する前にIPパケットを送信する場合、デフォルトのIPアドレス 127.0.0.1 が使用されます。異なる（デフォルトの）IPアドレスを使用するには、--ip パラメータと -peerip パラメータを使用することもできます。

9.3. ICMP非サポート

ほとんどの攻撃テストは、特別な方法でICMP ping要求を送信し、ICMP ping応答を受信するかどうかを確認することで機能します。テスト対象のデバイスがICMP pingをサポートしていない場合は、すべてのテストに --arp パラメータを追加して、代わりにARP要求を使用できます。テストがARP要求の送信をサポートしていない場合、ツールはエラー Cannot override request type of the selected test を表示します。この場合、その特定のテストはICMP ping要求を使用してのみ実行できます。

TODO: クライアントとして動作する場合、代わりにDHCP要求を注入することもできます。

1. ath9k_htc を使用するネットワークカード

2. carl9170 を使用するネットワークカード

3. iwlmvm を使用するネットワークカード。

ath9k_htc ベースのカードを推奨します。iwlmvm を使用するすべてのカードが互換性があるわけではありません。代替ネットワークカードを使用する場合は、最初に注入テストを実行して、ネットワークカードに互換性があることを確認することを強くお勧めします。

9.5. 5 GHzサポート

5 GHzチャネルでテストツールを使用するには、使用するネットワークカードが5 GHzチャネルでのフレーム注入を許可している必要があります。残念ながら、規制上の制約により、これは常に可能であるとは限りません。どのチャネルでフレームを注入できるかを確認するには、iw list を実行し、Frequencies の下で、無効（disabled）、no IR、またはレーダー検出（radar detection）としてマークされ_ていない_チャネルを探します。これらの条件は、ネットワークカード、現在設定されている国、接続しているAPによって異なる場合があることに注意してください。詳細については、たとえば Arch Linuxドキュメント を参照してください。

デバイスは、2.4 GHz帯と5 GHz帯を処理するために異なるドライバーを使用する場合があることに注意してください。その結果、使用される周波数帯によってデバイスの動作が異なる可能性があるため、両方の帯域でデバイスをテストすることが重要です。

混合モードでは、Linuxカーネルが通常のフレームの送信を許可していても、フレームの注入を許可しない場合があることに注意してください。これは、関数 ieee80211_monitor_start_xmit 内で、cfg80211_reg_can_beacon が false を返すと、カーネルがフレームの注入を拒否するためです。その結果、Linuxは実際には許可されているにもかかわらず、フレームの注入を拒否する可能性があります。正しい条件下で cfg80211_reg_can_beacon が true を返すようにすることで、このバグを防ぐことができます。

実際には、まずワイヤレスネットワークカードをAPが動作している5GHzチャネルに手動で設定する必要があることが、一部の人々によって報告されています。詳細はこのGitHub issueを参照してください。

9.6. スリープモードの処理

スマートフォンやIoTガジェットなどのデバイスは、エネルギー消費を削減するためにWi-Fi無線をスリープモードにする場合があります。スリープモード中は、これらのデバイスはWi-Fiフレームを受信できないため、テストに干渉する可能性があります。この問題を軽減するために試せるいくつかのオプションがあります。

1. テスト対象のデバイスでスリープモードを無効にしてみてください。これが最も信頼性の高い解決策ですが、残念ながら常に可能であるとは限りません。

2. テストツールを混合モードで実行します。ほとんどのネットワークカードは、テスト対象のデバイスが再び起動するまで注入フレームをキューに入れます。

3. テストを実行するために別のネットワークカードを試してください。異なるネットワークカードは（わずかに）異なるタイミングでフレームを注入することがわかりました。これが、注入されたフレームが正しく到着するか、見逃されるかの違いになる可能性があります。たとえば、Pixel 4 XL に対しては、TL-WN722N を使用するとテストツールの信頼性が低かったですが、Intel 8265 では確実に機能しました。

4. テスト対象のデバイスに静的IPを割り当て、テストツールに静的IPを使用させます（静的IP構成 を参照）。多くのテストでは、テストツールが最初にDHCPを使用/待機する代わりに、テストフレームをすぐに送信できるため、これにより信頼性が向上します。

9.7. APでのtcpdumpの回避一部の脆弱性は、テスト対象デバイスがネットワークに接続している間、すなわち4ウェイハンドシェイクを実行している間にのみ悪用できます。このため、これらを自動的にテストすることは難しく、通常はテスト対象デバイス上でtcpdumpまたは類似のツールを使用する必要があります。ただし、APはtcpdumpを実行せずにテストできます。特に、ブロードキャストフラグメント攻撃テスト(CVE-2020-26145)とA-MSDU EAPOL攻撃テスト(CVE-2020-26144)は、テスト対象デバイス上でtcpdumpを実行せずに実施できます。その代わり、APに接続された別のクライアント上でtcpdumpを実行する必要があります。具体的には、次のコマンドを使用できます:

• ping I,P --bcast-ra --bcast-dst および ping BP --bcast-ra --bcast-dst

• eapol-amsdu BP --bcast-dst および eapol-amsdu-bad BP --bcast-dst

これらのコマンドを使用すると、APに接続されている別のクライアント上でping要求を監視できます。この独立したクライアントでping要求が受信された場合、テスト対象のAPは脆弱です。残念ながら、現時点では、クライアント上でtcpdumpを実行せずにこれらの攻撃バリアントに対してクライアントをテストすることは困難なようです。

9.8. デバイスサポートに関する注記

AWUS036ACM

何らかの理由でLinuxがこのドングルを自動的に認識しない場合は、sudo modprobe mt76x2u を実行してドライバを手動でロードしてください。このドングルは、当社の最新ドライバでは信頼性が高いと思われます。ドングルの動作が不安定な場合は、以下の内容で /etc/modprobe.d/mt76.conf ファイルを作成してください:``` options mt76_usb disable_usb_sg=1

その後、マシンを再起動してください。また、このドングルでは品質の良いUSBケーブルを使用してください！以前、このドングルで不安定な動作が発生しましたが、それは不良のUSB 3.0ケーブルが原因でした。問題が発生する場合は、ケーブルを使わずにドングルを直接差し込むと改善することがあります。

VirtualBoxを使用する場合は、ドングルが認識されるようにUSB3.0を有効にしてください。詳細は[このissue](https://github.com/vanhoefm/fragattacks/issues/22)を参照してください。

AWUS036ACMは内部でMT7612Uチップセットを使用しています。現在ではMT7612UNチップセットを搭載したドングルもあり、これらもテストツールで信頼性が高いことが確認されています。例としては、[CSL Wireless Network Adaptor](https://www.amazon.de/dp/B0873BNBD8?tag=modwiffir-20)があります。

### ath9k_htc

Technoethical N150 HGA、TP-Link TL-WN722N v1.x、Alfa AWUS036NHAはすべて`ath9k_htc`ドライバを使用しています。

これらのデバイスは仮想マシンでもかなり良好に動作しましたが、他のすべてのデバイスと同様に、ネイティブで使用した方が信頼性が高くなります。VMを使用する場合は、USB2.0コントローラを使用するようにVMを設定することをお勧めします。（少なくともVirtualBoxでは）その方がより安定していたためです。

最近のカーネルでは、`ath9k_htc`ドライバが動作しなくなる（[現在は修正済み](https://www.spinics.net/lists/linux-wireless/msg200825.html)の）リグレッションがありました。この問題を回避するには、最新のカーネルまたは修正済みドライバを使用してください。

#### AWUS036ACH

このデバイスは、ほとんどのLinuxディストリビューションではデフォルトでサポートされておらず、手動でのドライバインストールが必要です。Kali Linuxでは、`sudo apt install realtek-rtl88xxau-dkms`でドライバをインストールできます。他のディストリビューションにインストールするには、パッケージマネージャを確認するか、[GitHub](https://github.com/aircrack-ng/rtl8812au)のインストール手順に従ってください。デバイスを接続する前に、`modprobe 88XXau rtw_monitor_retransmit=1`を実行することをお勧めします。

残念ながら、このデバイスは推奨モードである混在モードでは動作せず、修正済みドライバとの組み合わせでの使用も困難です。実際には、修正済みドライバをアンインストールし、`--no-drivercheck`パラメータと`--inject wlan0`（wlan0はAWUS036ACHカードを指します）を使用してテストツールを実行する必要があります。これらの制限のため、このデバイスは推奨されません。

### Intel AX200

Intel AX200をテストしたところ、テストツールと_互換性がない_ことがわかりました。More Fragmentsフラグが設定されたフレームを注入すると、ファームウェアがクラッシュします。この文書を読んでいるIntelの開発者がいらっしゃいましたら、ファームウェアを更新して、断片化されたフレームの注入を可能にしてください。

### RT5572-based chips

このチップセットは、一般的な[CSL USB 2.0 WLAN Adapter 300Mbit adapter](http://www.amazon.de/dp/B00LLIOT34?tag=modwiffir-20)を使用してテストしました。`disable-hwcrypto.sh`スクリプトを実行してハードウェア復号化を無効にした後、基本的なpingテスト（`ping`）を実行できました。断片化されたpingテスト（`ping I,E,E`）は非常に不安定でしたが、時々動作しました。

現在の結論としては、RT5572チップはハードウェア暗号化を無効にすればテストツールで動作する_可能性がある_ということです。ただし、これを確認するには追加の実験が必要です（フィードバック歓迎）。

<a id="id-hwsim-details"></a>
## 9.9. Hwsimモードの詳細

**警告**: *これは現在実験的なモードであり、研究目的でのみ使用してください。*

このモードでは、モニターモードをサポートするネットワークカードが1枚だけ必要で、混在モードとは異なり、ネットワークカードが仮想インターフェースをサポートする必要はありません。欠点は、このモードではフレームの処理が少し遅くなり、ネットワークカードがフレームを確認応答しない場合に信頼性が低くなることです：

- コミット1672c0e31917（「mac80211: start auth/assoc timeout on frame status」）のため、クライアントとしての認証が即座にタイムアウトします。つまり、現在hwsimモードをクライアントとして使用することはできません。
  _TODO: このタイムアウトを回避するためにカーネルをパッチする必要があります。_

- コミット1672c0e31917（「mac80211: start auth/assoc timeout on frame status」）を使用するクライアントをテストする場合、私たち（APとして）は自分宛てに送信されたフレームを確認応答する必要があります。そうしないと、テスト対象のクライアントが接続できなくなります。
  _TODO: モニターモードでフレームを確認応答するデバイスをテストし、`iw set wlanX monitor active`をテストする。_

- 特定のAPは、認証フレームとアソシエーションフレームがクライアントによって確認応答されることも要求します。つまり、私たち（クライアントとして）も自分宛てに送信されたフレームを確認応答する必要があります。
  _TODO: モニターモードでフレームを確認応答するデバイスをテストし、`iw set wlanX monitor active`をテストする。_

- なぜか分かりませんが、Intel/mvmは4-wayハンドシェイク後にAndroid/iPhone/iPadからのデータフレームを受信できません？これは非常に奇妙なバグです。_TODO: さらに調査する。_

このモードを使用する前に、2つの仮想ネットワークカードを作成します：

	./hwsim.sh

これにより、作成された2つの仮想「hwsim」インターフェース（例：wlan1とwlan2）が出力されます。このモードでAPをテストする場合は、まずAPのチャンネルを検索し、実際のネットワークカードをこのチャンネルに設定する必要があります：

	./scan.sh wlan0
	ifconfig wlan0 down
	iw wlan0 set type monitor
	ifconfig wlan0 up
	# Pick the channel that the AP is on (in this example 11)
	iw wlan0 set channel 11

ここでwlan0は_実際の_ネットワークカード（`hwsim.sh`によって作成されたインターフェースではありません）を指します。クライアントをテストする場合、最初にチャンネルを設定する必要はありません（`hostapd.conf`から取得されます）。次のようにしてテストツールを起動できます：

	./fragattack.py	 wlan0 --hwsim wlan1,wlan2 [--ap] $COMMAND

ツールの実行後、新しい`$COMMAND`を指定して直接再度実行できます。

<a id="id-wpa3-sae"></a>
## 9.10. WPA3およびSAEデバイスのテスト

`client.conf`に次の2行を含めることで、WPA3/SAE APをテストできます：

	key_mgmt=SAE
	ieee80211w=1

WPA3/SAEクライアントをテストするには、`hostapd.conf`を変更して次のパラメータを設定します：

	wpa_key_mgmt=SAE
	ieee80211w=2

上記はIntel 8265、Intel 3160、Netgear WN111v2（`carl9170`）、TP-Link TL-WN722N（`ath9k_htc`）、WNDA3200（`ath9k_htc`）でテストしました。これらのデバイスでAPに接続していくつかのテストを実行できました。したがって、これはすでにサポートされているすべてのドングルで動作するはずです。詳細なテストは行っていないことに注意してください：デバイスがWPA2モードとWPA3モードのどちらで動作しているかはテスト結果に影響しないという前提で進めています。

提供されている`client.conf`は、デフォルトでhunting-and-pecking方式とhash-to-element方式の両方を有効にします。hash-to-elementをサポートするAPをセットアップするには（それにより最新のWPA3/SAEクライアントをテストできます）、`hostapd.conf`を変更して次のパラメータを設定します：

	sae_pwe=2

この値を設定することで、APはhunting-and-pecking方式とhash-to-element方式の両方を受け入れます。

<a id="id-live-image"></a>
## 9.11. ライブUSBイメージ

[ライブUSBイメージ](https://people.cs.kuleuven.be/~mathy.vanhoef/fragattacks/ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso)をダウンロードし、次のコマンドでUSBに書き込みます：

	# Unmount in case there's an old partition on the USB
	sudo umount /dev/sdb*
	# Copy the image
	sudo dd bs=4M if=ubuntu-20.04.2-fragattacks-1.3.3-amd64.iso of=/dev/sdb conv=fdatasync status=progress

イメージのsha256sumは`4b973452a08b981778285a33accfd4ce58625a91e8e0eab20941facf54904bba`です。`/dev/sdb`はお使いのUSBスティックに置き換えてください。Linuxを使用していない場合は、USBスティックへのISOイメージの書き込み方法をオンラインで検索してください。

ライブイメージを起動する際は、起動中に「Try Ubuntu」をクリックしてください。デスクトップを右クリックして「Open in Terminal」を選択してターミナルを起動し、次のコマンドを実行します：

	cd ~/fragattacks/research
	sudo su
	nmcli radio wifi off
	source venv/bin/activate

これで`./fragattacks.py`を実行し、このREADMEの通常の手順に従うことができます。上記のように`nmcli radio wifi off`でWi-Fiを無効にすることを忘れないでください。そうしないと、Ubuntuのネットワークマネージャがテストツールに干渉します。このREADMEはライブイメージ上の`~/fragattacks/README.md`にもあります。

ライブイメージではairmon-ngが信頼性の低い場合があるため、[iw](https://github.com/vanhoefm/fragattacks/issues/36)を使用することをお勧めします。

<a id="id-design-notes"></a>
# 10. 設計ノート

pingコマンドに与えられる引数は、テストツールがどのアクションをいつ実行するかを定義します。各アクションはカンマ（`,`）で区切られます。デフォルトでは、アクションはクライアントが接続した後に実行され、その場合、実行されるアクションは1文字で表されます。これは[`stract2action`](https://github.com/vanhoefm/fragattacks/blob/master/research/fragattack.py#L23)関数で実装されていることに注意してください。可能なアクションは次のとおりです：

- `I`：IPアドレスを取得します。デフォルトではDHCPを使用して行われます。ただし、IPアドレスが明示的に
       `--ip`引数と`--peerip`引数で提供されている場合は除き、その場合は何も行われません。
- `E`：pingリクエストの暗号化されたパケット/フラグメントを注入します。
- `P`：pingリクエストの平文パケット/フラグメントを注入します。
- `F`：4-wayハンドシェイクを開始する（APとして）か、4-wayハンドシェイクを待つ（クライアントとして）ことで、
       セッションキーを更新します。
- `R`：クライアントをネットワークに再接続させます。
- `D`：これは特別な「メタアクション」です。実際には送信されないpingリクエストの空のフラグメントのように
       扱います。

`E`または`P`アクションが1つだけの場合は、pingリクエストが単一のフレームとして注入されます。`E`、`P`アクションが複数ある場合は、pingリクエストが断片化され、フラグメント数は`E`または`P`アクションの数と等しくなります。特別な`D`アクションがある場合は、pingリクエストは残りの`E`または`P`アクションにわたって断片化されます（表の例を参照してください）。この断片化の動作は[PingTest](https://github.com/vanhoefm/fragattacks/blob/master/research/tests_common.py#L47)クラスで実装されています。

上記のアクションの前に文字を付けて、アクションを実行するタイミングを変更できます：

- `S`：アクションは4-wayハンドシェイクの1番目または2番目のメッセージで実行されます。
- `B`：アクションは4-wayハンドシェイクの3番目または4番目のメッセージで実行されます。
- `A`：アクションは4-wayハンドシェイクの完了直後に実行されます。
- `C`：アクションは4-wayハンドシェイクの完了1秒後に実行されます。待機時間（秒）は`--connected-delay`パラメータを使用して
       変更できます。

例については、上記の2つのコマンド表を参照してください。

<a id="id-change-log"></a>
# 11. 変更ログ

**バージョン1.3.4（進行中）:**:

- --rekey-plaintextを使用する場合でも、EAPOL（Rekey）Requestフレームを常に暗号化します。

- クライアントはリプレイされたEAPOLフレームを受け入れるようになりました。これにより、テスト対象のAPがリキーを誤って実装している場合でも、リキーが機能することが保証されます。

- MS-CHAPv2を使用するEnterpriseネットワークへの接続を再び有効にするようwpa_supplicantを更新しました。以前は、OSがOpenSSL 3.0以降を使用している場合、MD4がデフォルトで無効になっていたため、MS-CHAPv2を使用できませんでした。

- `--pre-test-delay`パラメータを追加しました。これにより、IPアドレスの取得と最初のフラグメント/フレームの送信の間に遅延が追加されます。Michael Trimarchi氏とAngelo Compagnucci氏による[pull request](https://github.com/vanhoefm/fragattacks/pull/44)を参照してください。
	
- 修正済みドライバをLinuxカーネル5.13でもコンパイルできるよう更新しました。これは実験的なものです。

- リオーダーテストでフレームをより長く待機するようにして、注入テストの信頼性を向上させました。

- 古いプラットフォーム（古いPythonバージョンとOpenSSLライブラリを搭載したもの）でコードをコンパイルしやすくするためのいくつかのマイナーな変更を行いました。

- Ubuntu 20.04にサポートされている古いカーネルをインストールする方法の例をREADMEに追加しました。設計ノートを追加しました。現在はAWUS036ACMを推奨しています。

**バージョン1.3.3（2021年5月11日）**:

- 修正済みドライバをLinuxカーネル5.10、5.11、5.12でコンパイルできるよう更新しました。

- `ath9k_htc`デバイス用のファームウェアを更新しました（テストには影響がないはずです）。

- 公開リリース用にリポジトリを再構成しました。内部ドキュメントとスライドを削除し、代わりにこれらのドキュメントの公開バージョンを参照するようにしました。

- 注入をテストするための`--inject-test[-postauth]`パラメータ使用時に、40 MHzチャンネルの基本的なサポートを追加しました。実際の脆弱性テストでは、40 MHzチャンネルの使用は未テストです（必要に応じて`client.conf`で`disable_ht40`を使用してください）。

**バージョン1.3.2（2021年3月8日）**:

- プレゼンテーションの[ハンドアウト](https://papers.mathyvanhoef.com/fragattacks-slides-2021-3-8.pdf)と、各脆弱性の根本原因と影響の[概要](https://papers.mathyvanhoef.com/fragattacks-overview.pdf)を追加しました。

- テスト対象デバイスが特定の最小サイズのフラグメントのみを受け入れる場合、断片化されたフレームを送信するすべてのテストに`--icmp-size 100`などのパラメータを追加できることを[説明](#id-test-sanity)するようREADMEを更新しました。

- このREADMEの軽微なタイプミスを修正しました。

**バージョン1.3.1（2021年3月1日）**:

- [`ping BP [--bcast-dst]`](#id-extended-bcast-check-ping-bp)テストをこのREADMEに追加しました。これは接続中（つまり4-wayハンドシェイク中）に平文のpingを注入します。クライアントとAPの両方がこの攻撃に対して脆弱になる可能性があります。

- パケット注入の脆弱性が実際に悪用される方法の新しい例で[攻撃の概要](#id-paper-clarifications)を更新しました。これには、IPv4のみのクライアントを騙して悪意のあるDNSサーバーを使用させる手法や、NAT/ファイアウォールの背後にあるデバイスと直接通信する手法（例えばローカルサービスを悪用するため）が含まれます。

- [ブロードキャストフラグメントテスト](#id-extended-bcast-check)がクライアントとAPの両方に対して実行できることを明確にしました。

- テストツールは、期待されるバージョンのPython Scapyライブラリがロードされたかどうかをチェックするようになりました。

- このREADMEの論文への参照のいくつかを修正しました（セクション6.4、6.6、6.8を適切に参照するようになりました）。

- 論文をドラフトバージョン3に更新しました。ドラフトバージョン2と比較して大きな変更はなく、軽微なテキストと構成の調整のみです。内容的には、これが論文の最終版です。

**バージョン1.3（2021年1月20日）**:

- このバージョンはhostapのコミット`a337c1d7c`（「New TWT operations and attributes to TWT Setup and Nudge」）に基づいています。

- 攻撃とその前提条件の[概要](https://github.com/vanhoefm/fragattacks/blob/HEAD/attacks.pdf)を追加し、アグリゲーション攻撃（CVE-2020-24588）が実際にどのように機能するかをよりわかりやすく説明する[これらのスライド](https://github.com/vanhoefm/fragattacks/blob/HEAD/amsduattack.pdf)を作成しました。

- hunting-and-pecking方式またはhash-to-element方式のいずれかを使用してWPA3/SAEデバイスをテストする方法の<a href="#id-wpa3-sae">手順</a>を追加しました。これは、テストツールがManagement Frame Protection（MFP）をサポートすることも意味します。

- 特定のテストの結果を検証するためのtcpdumpの使用方法について、このREADMEに明確化を追加しました。

- tcpdumpを実行できないAPに対してCVE-2020-26145をテストできるよう、追加テスト`ping BP --bcast-ra --bcast-dst`をこのREADMEに追加しました（このテストでは、独立した接続済みクライアントでtcpdumpを実行する必要があります）。

- 特定のデバイスで混合キー攻撃（CVE-2020-24587）をよりよく検出できるよう、追加テスト`ping I,E,F,E [--rekey-pl] [--rekey-req]`をこのREADMEに追加しました。

- ath9k_htcドングルと802.11nの組み合わせで使用する際の断片化フレームの注入を修正しました。

- Python仮想環境を作成するための`pysetup.sh`スクリプトが追加されました。このスクリプトは、Python 3.9で使用する際のscapyライブラリの[バグ](https://github.com/secdev/scapy/commit/46fa40fde4049ad7770481f8806c59640df24059)も修正します。

- パッチ済みドライバがLinux 5.9.0で正しくコンパイルできるよう更新されました。

- `ping-frag-sep`テストを修正しました。以前は`ping-frag-sep --pn-per-qos`のように動作していました。このテストは脆弱性の検出に使用されるのではなく、実装をよりよく理解するためだけに使用されることに注意してください。

**バージョン1.2（2020年11月15日）**:

- このバージョン（およびそれ以前）はhostapのコミット`1c67a0760`（「tests: Add basic power saving tests for ap_open」）に基づいています。

- テストが完了したかタイムアウトした後、ツールは自動的に終了します。

- 4-wayハンドシェイクがループしているかどうか、またはリキーリクエスト（`--rekey-req`）への応答がないかどうかをツールが検出します。

- 外部DHCPサーバーを使用する場合、ツールは現在、宛先アドレスをDHCPサーバーではなくAPとするEAPOLフレームを常に送信します。これは、外部DHCPサーバーを使用する際の混合キー攻撃およびキャッシュ攻撃テストで重要です。

- `--rekey-req`を使用してAPをテストする場合、ツールは現在、リプレイカウンタがゼロではなく1のEAPOL Rekey Requestを送信します。

- デバッグ出力は、ブロードキャスト/マルチキャストフレームの暗号化時に正しい（グループ）キーを表示するようになりました。これはテスト結果には影響せず、テストツールの出力のみを変更します。

- 特に記載がない限り、このREADMEのすべてのコマンドがクライアントとAPの両方をテストできることを明確にしました。

- このREADMEのキャッシュ攻撃、ブロードキャストフラグメント、A-MSDU EAPOL攻撃テストの説明を明確にしました。

- このREADMEで、2.4 GHz帯と5 GHz帯の両方をテストすることが重要であると明確にしました。

**バージョン1.1（2020年10月20日）**:

- `ping I,E,D`コマンドが通常の暗号化されたpingリクエストを送信していたバグを修正しました。現在は、ヘッダーにMore Fragmentsフラグが設定された暗号化されたpingリクエストを送信します。

- `amsdu-inject-[bad]`コマンドをこのREADMEのセクション7に移動しました。これらは実際の攻撃をシミュレートし、一時的な緩和策が機能しているかどうかを検証するために使用できます（論文のセクション7.2を参照してください）。

- このREADMEとテストツールでのA-MSDU SPPのスペルを修正しました。新しい引数`--amsdu-spp`は、以前の`--amsdu-ssp`引数の同義語になりました。

**バージョン1.0（2020年8月11日）**:

- エンバーゴ期間中の使用に向けて初期リリースを準備しました。