このプロジェクトには、クライアントまたはアクセスポイント（AP）がWPA2に対するKRACK攻撃の影響を受けるかどうかをテストするスクリプトが含まれています。この攻撃の詳細については私たちのWebサイトと研究論文を参照してください。

私たちのスクリプトは攻撃スクリプトではないことに注意してください！アクセスポイントまたはクライアントがKRACK攻撃の影響を受けるかどうかをテストするには、適切なネットワーク認証情報が必要です。

2024年12月: 7番目のテスト ./krack-test-client.py --gtkinit のバグが修正されました。このバグ修正以前は、このテストの(出力)は信頼できないと述べられていましたが、新しい手順に従えば、現在は出力は信頼できるはずです。つまり、このテストがデバイスが脆弱であると示す場合、実際に脆弱である可能性が高いです。

2021年1月: スクリプトはPython3と互換性を持たせ、新しいLinuxディストリビューションをより適切にサポートするように更新されました。旧バージョンに戻したい場合は、リポジトリをクローンした後に git fetch --tags && git checkout v1 を実行してください（最新バージョンに戻すには git checkout research を使用します）。

前提条件

私たちのスクリプトはKali Linuxでテストされました。Kaliで必要な依存関係をインストールするには、次を実行します:

sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw

次に、修正したhostapdインスタンスをコンパイルし、Python仮想環境を作成します。これにより、互換性のあるPythonライブラリ（krackattack/requirements.txt にリストされているもの）を使用できます:

git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh

次に、最適な結果を得るためにハードウェア暗号化を無効にします:

cd krackattack
sudo ./disable-hwcrypto.sh

必要に応じて、後でスクリプト sudo ./reenable-hwcrypto.sh を使用してハードウェア暗号化を再び有効にできます。ハードウェア暗号化を無効にした後は、再起動することをお勧めします。私たちはKali Linux上でIntel Dual Band Wireless-AC 7260とTP-Link TL-WN722N v1を使用してスクリプトをテストしました。

使用前の毎回の操作

スクリプトを使用するたびに、ネットワークマネージャーでWi-Fiを無効にする必要があります。その後、次を実行します:

sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate

この操作後、ターミナルを閉じない限り、スクリプトを複数回実行できます。

disable-hwcrypto.sh の効果を取り消したい場合は、ファイル /etc/modprobe.d/nohwcrypt.conf を削除してください。

クライアントのテスト

まず hostapd/hostapd.conf を変更し、テストを実行するために使用するWi-Fiインターフェースを指定するために interface= の行を編集します。すべてのテストで、スクリプトが実行されたら、テスト対象のデバイスをパスワード abcdefgh を使用してSSID testnetworkに接続させる必要があります。hostapd/hostapd.conf を変更することでAPの設定を変更できます。すべてのテストで、クライアントはWi-Fiネットワークに接続した後、DHCPを使用してIPを取得する必要があります。これは、一部のテストがクライアントがDHCPを使用してIPを要求した後にのみ開始されるためです！

krackattacks/ ディレクトリにある以下のテストを実行する必要があります:

1. ./krack-test-client.py --replay-broadcast。これは、クライアントが再生されたブロードキャストフレームを受け入れるかどうかをテストします。クライアントが再生されたブロードキャストフレームを受け入れる場合、これは最初に修正する必要があります。クライアントを修正しない場合、スクリプトはグループキーが再インストールされているかどうかを判断できません（その場合、スクリプトは常にグループキーが再インストールされていると述べるため）。

2. ./krack-test-client.py --group --gtkinit。これは、指定された受信シーケンスカウンタ（RSC）を使用して、クライアントがグループキーハンドシェイクでグループキーをインストールするかどうかをテストします。この脆弱性の詳細については、フォローアップ研究論文のセクション6.4を参照してください。

3. ./krack-test-client.py --group。これは、クライアントがグループキーハンドシェイクでグループキーを再インストールするかどうかをテストします。言い換えれば、クライアントがCVE-2017-13080に対して脆弱かどうかをテストします。このスクリプトは、既に使用された（再生された）パケット番号（ここではパケット番号 = nonce = IV）を使用してブロードキャストARP要求をクライアントに送信することにより、グループキーの再インストールをテストします。クライアントが常に再生されたブロードキャストフレームを受け入れる場合（--replay-broadcast を参照）、このテストはグループキーが再インストールされていると誤って結論付ける可能性があることに注意してください。

4. ./krack-test-client.py。これは、暗号化されたメッセージ3をクライアントに繰り返し送信することにより、4ウェイハンドシェイクでのキーの再インストールをテストします。言い換えれば、これはCVE-2017-13077（最も影響の大きい脆弱性）とCVE-2017-13078をテストします。 このスクリプトは、クライアントが送信するトラフィックを監視して、ペアワイズキーが再インストールされているかどうかを確認します。これは実質的に2つのテストを実行することに注意してください: ペアワイズキーが再インストールされるかどうか、およびグループキーが再インストールされるかどうか。グループキー再インストールテストを開始するには、クライアントがDHCPを使用してIPを要求するようにしてください。クライアントが十分なユニキャストフレームを送信していることを確認するには、任意でAPにpingを実行できます: ping 192.168.100.254。

5. ./krack-test-client.py --tptk。テスト4と同じですが、暗号化されたメッセージ3を送信する前に偽造メッセージ1が注入される点が異なります。このテストの変形は重要です。一部のクライアント（例: wpa_supplicant v2.6）は、再送信されたメッセージ3の前に偽造メッセージ1が注入された場合にのみ、4ウェイハンドシェイクでのペアワイズキー再インストールに対して脆弱であるためです。

いくつかの追加の注意事項:

• 最も重要なテストは ./krack-test-client で、4ウェイハンドシェイクでの通常のキー再インストールをテストします。

• これらのテストは、干渉が少ない部屋で実行してください。パケットロスが多いと、このスクリプトの信頼性が低下します！

• オプションで、ネットワークトラフィックを手動で検査してスクリプトの出力を確認できます（一部のWi-Fi NICはスクリプトに干渉する可能性があります）:

  • モニターモードの追加のWi-Fi NICを使用して、スクリプト（AP）が適切なパケット番号（IV）を使用してフレームを送信していることを確認します。特に、再生されたブロードキャストフレームが実際に既に使用されたパケット番号（IV）を使用して送信されているかどうかを確認します。

  • モニターモードの追加のWi-Fi NICを使用して、クライアントが送信するフレームのIVを監視し、ペアワイズキーの再インストールを確認します。

  • クライアントでトラフィックをキャプチャして、再生されたブロードキャストARP要求が受け入れられるかどうかを確認します。

• クライアントが複数のWi-Fi無線/NICを使用できる場合は、複数のWi-Fi NICを使用してテストを実行してください。

• デバッグ出力を増やすには、--debug パラメータを追加できます。

• 認識されないパラメータはすべてhostapdに渡されるため、-dd -K のようなものを含めて、hostapdにすべてのデバッグ情報を出力させることができます。

Wi-Fi Allianceテストとの対応

Wi-Fi Allianceは、私たちのスクリプトに基づいたカスタム脆弱性検出ツールを作成しました。 執筆時点では、このツールはWi-Fi Allianceメンバーのみがアクセスできます。 彼らのツールはいくつかの異なるテストをサポートしており、これらのテストは次のように私たちのスクリプトの機能に対応しています:

• 4.1.1 (EAPOLメッセージ3の平文再送信)。現在、このテストはサポートしていません。このテストはとにかく必要ありません。テスト対象のデバイスがテスト4.1.3に合格することを確認すれば、このテストにも合格します。

• 4.1.2 (平文でのEAPOL M3の即時再送信)。現在、このテストはサポートしていません。繰り返しますが、テスト対象のデバイスがテスト4.1.3に合格することを確認すれば、このテストにも合格します。

• 4.1.3 (ペアワイズ再キーイングハンドシェイク中の暗号化EAPOL M3の即時再送信)。これは ./krack-test-client.py に対応しますが、暗号化されたEAPOL M3が即時ではなく定期的に送信される点が異なります。

• 4.1.5 (STAがTemporal PTK構築を使用する場合の4ウェイハンドシェイクでのPTK再インストール、同じANonce)。このテストは ./krack-test-client.py --tptk を使用して実行してください。

• 4.1.6 (STAがTemporal PTK構築を使用する場合の4ウェイハンドシェイクでのPTK再インストール、ランダムANonce)。このテストは ./krack-test-client.py --tptk-rand を使用して実行してください。

• 4.2.1 (STA上のグループキーハンドシェイク脆弱性テスト)。このテストは ./krack-test-client.py --group を使用して実行してください。

• 4.3.1 (WNMスリープモードをサポートするSTAでのGTKおよびIGTKの再インストール)。現在、このテストはサポートしていません（実際にはWi-Fi Allianceもサポートしていません！）。

アクセスポイントのテスト: 脆弱なFTハンドシェイクの検出 (802.11r)

1. ネットワークに接続するために使用できるwpa_supplicant設定ファイルを作成します。基本的な例は次のとおりです:

   root@kitploit:~

    ctrl_interface=/var/run/wpa_supplicant
    network={
      ssid="testnet"
      key_mgmt=FT-PSK
      psk="password"
    }
   

   "FT-PSK" の使用に注意してください。network.conf または同様の名前で保存します。詳細については wpa_supplicant.conf を参照してください。

2. プラットフォームのwpa_supplicantを使用してネットワークに接続してみます。これにはおそらく次のようなコマンドが必要です:

   root@kitploit:~

    sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   これが失敗した場合、APがFTをサポートしていないか、ステップ1で誤ったネットワーク設定オプションを指定した可能性があります。APがFTをサポートしていない場合、この脆弱性の影響を受けないことに注意してください。

3. このスクリプトを前のwpa_supplicantコマンドのラッパーとして使用します:

   root@kitploit:~

    sudo su
    source venv/bin/activate
    ./krack-ft-test.py wpa_supplicant -D nl80211 -i wlan0 -c network.conf
   

   これにより、指定されたパラメータを使用してwpa_supplicantコマンドが実行され、攻撃テストを実行する仮想モニターインターフェースが追加されます。まずrootになり、その後Python仮想環境をロードすることが重要です（この仮想環境の作成方法については上記を参照してください）。

4. wpa_cliを使用して、同じネットワークの別のAPにローミングします。例:

   root@kitploit:~

    wpa_cli -i wlan0
    > status
    bssid=c4:e9:84:db:fb:7b
    ssid=testnet
    ...
    > scan_results 
    bssid / frequency / signal level / flags / ssid
    c4:e9:84:db:fb:7b	2412  -21  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    c4:e9:84:1d:a5:bc	2412  -31  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
    ...
    > roam c4:e9:84:1d:a5:bc
    ...
   

   この例では、testnet のAP c4:e9:84:db:fb:7b に接続していました（statusコマンドを参照）。scan_resultsコマンドは、このネットワークにMAC c4:e9:84:1d:a5:bc の2番目のAPもあることを示しています。次に、この2番目のAPにローミングします。

5. APとクライアントの間でトラフィックを生成します。例:

   root@kitploit:~

    arping -I wlan0 192.168.1.10
   

追加: ハードウェア復号

ハードウェア復号が無効になっていることを確認するには、Wi-Fi NICを接続した後、systool -vm ath9k_htc または同様のコマンドを実行して、nohwcript/swcrypto/hwcryptoパラメータが設定されていることを確認します。ath9k_htc はワイヤレスネットワークカードのカーネルモジュールに置き換える必要があることに注意してください。

追加: 5 GHzはサポートされていません

5 GHz帯でのデバイステストの公式サポートはありません。

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

Linuxカーネルは、通常のフレームの送信が許可されていても、フレームの注入を許可しない場合があることに注意してください。これは、関数 ieee80211_monitor_start_xmit で、cfg80211_reg_can_beacon がfalseを返すとカーネルがフレームの注入を拒否するためです。その結果、Linuxは実際には許可されているにもかかわらず、フレームの注入を拒否する場合があります。正しい（またはすべての）条件下で cfg80211_reg_can_beacon がtrueを返すようにすると、このバグを防ぐことができます。したがって、たとえば packport driver コードを手動でパッチするなどして、cfg80211_reg_can_beacon が常にtrueを返すようにLinuxドライバーをパッチする必要があります。

追加: 手動テスト

hostap gitリポジトリをクローンして、（より詳細な）テストを手動で実行することも可能です:

git clone git://w1.fi/srv/git/hostap.git

そして、tests/cipher-and-key-mgmt-testing.txt の指示に従ってください。