ワイヤレスKRACK攻撃クライアント側の回避策と検出

概要

10月16日、WiFiネットワークで使用されるさまざまなプロトコルに影響を与えるKRACKとして広く知られている一連の脆弱性が公開されました。これらは、WPA/WPA2ネットワークで使用されるセキュリティプロトコルに影響を与えます。これにより、ワイヤレス接続を介して送信される際に、データプライバシーや整合性が損なわれる可能性があります。

実際の影響のレベルは各シナリオによって大きく異なります。また、クライアント側のすべての実装が同じ方法で影響を受けるわけではありません。
この攻撃では、「ネガティブテスト」の様々な巧妙なシナリオを使用します。このシナリオでは、無線規格で正しく定義されていない状態の遷移が試行され、ほとんどの場合、該当デバイスで正しく処理されません。これは、WPA2を保護するために使用される暗号化アルゴリズムではなく、ワイヤレス接続のセキュリティ保護の際に認証とプロトコルのネゴシエーションがどのように行われるかについての問題です。

脆弱性のシナリオのほとんどはクライアントで報告されています。この場合、一般的な攻撃では、クライアントと実際のAP間のセキュリティネゴシエーション中に偽のApを「man in the middle」として傍受し、特定のフレームを挿入します(CVE-2017-13、CVE-200) 17-13079、CVE-2017-13080、CVE-2017-13081)。 このドキュメントの焦点は次のとおりです

802.11r(FT)高速ローミングサービス(CVE-2017-1382)を提供するAPインフラストラクチャに対する攻撃について説明しました。これは、最近リリースされたAireOSコードで修正されています

クライアント固有のプロトコルに対する攻撃は残り4つあります。STK、TDLS、WNM。AireOSインフラストラクチャでは直接サポートされません(CVE-2017-13084 CVE-2017-13086 CVE-2017-13087 CVE-20) 17-13088)を参照してください。

実際には、攻撃者は該当セッションのトラフィックを復号化したり、1方向または2方向(RFC 1223)にフレームを挿入したりできます。攻撃の前に既存のトラフィックをデコードする方法はなく、特定のSSID、PSK、または802.1xパスワードのすべてのデバイスの暗号化キーを「取得」するメカニズムも提供しません 

この脆弱性は実際に存在し、重大な影響を与えますが、WPA2保護ネットワークが「永続的に影響を受ける」という意味ではありません。クライアントとAPの両方の実装を改善することで問題を解決できます

お客様が行うべきこと：

• AP側の脆弱性の場合：FTを使用する場合は、アップグレードを推奨します。音声/ビデオサービスにFTが必要ない場合は、固定コードへのアップグレードが完了するまでFT機能を無効にするかどうかを評価します。音声を使用している場合は、CCKMが実行可能かどうか（クライアント側でサポートが必要）を評価するか、固定コードにアップグレードします。FT/802.11rが使用されていない場合、現時点でアップグレードする必要はありません
• クライアント側の脆弱性に対しては、可視性を向上させます。不正検出が有効になっており、すべてのチャネルをカバーしていること、および「managed SSID」を悪意のあるユーザとして報告するルールが作成されていることを確認します。さらに、このドキュメントで説明されているように、実行する攻撃を制限または完全にブロックできるEAPoL再試行設定変更を実装します

主なリファレンス・アドバイザリは、https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20171016-wpaにあります。T

使用するコンポーネント

このドキュメントでは、リリース8.0以降を実行するワイヤレスコントローラについて説明します。

要件

上記のセキュリティアドバイザリの内容に関する知識が必要です。

WPA KRACK攻撃では、まだパッチが適用されていないクライアントを保護するために実行できる2つの主なアクションがあります。

1. EAPoL(EAP over LAN)再試行保護

2.不正検出およびアクセスポイント(AP)の偽装機能。攻撃ツールが使用されているかどうかを検出

EAPoL攻撃防御

脆弱性–2017-13077 ～ 81の場合、EAPoL再試行カウンタをゼロに設定して、クライアントが影響を受けないようにすることは比較的簡単です。  この設定は、すべてのWLCバージョンで使用できます

この機能の理由

この攻撃では、4ウェイハンドシェイク中(EAP-TLS)またはブロードキャストキーローテーション中にオーセンティケータによって少なくとも1回の追加EAPoL再試行が必要です。再試行の生成をブロックすると、Pairwise Transient Key(PTK)/Groupwise Transient Key(GTK)に対して攻撃を適用できません。

影響の可能性

1. EAPoL M1の初期処理が遅い、またはドロップする可能性があるクライアント（つまり、4方向キー交換の最初のメッセージ）。 これは、一部の小規模なクライアントまたは一部の電話機で発生します。M1を受信し、dot1x認証フェーズの後に処理する準備ができていないか、短い再送信タイマーを満たすために時間がかかりすぎています

2.不適切なRF環境、またはAPとWLCの間のWAN接続が存在し、クライアントへの送信時にパケットがドロップする可能性があるシナリオ。

どちらのシナリオでも、EAPoL交換の失敗が報告され、クライアントの認証が解除され、アソシエーションと認証のプロセスを再起動する必要があります。

この問題が発生する可能性を減らすには、遅いクライアントが応答するまでの時間を長くするために、より長いタイムアウト（1000ミリ秒）を使用する必要があります。デフォルトは1000ミリ秒ですが、手動で低い値に変更されている可能性があるため、確認する必要があります。

コンフィギュレーション

この変更を設定するには、2つのメカニズムがあります。

• グローバル、すべてのリリースで利用可能
• WLANあたり、7.6から最新のバージョンまで利用可能

グローバルオプションはよりシンプルで、すべてのリリースで実行できます。WLCのすべてのWLANに影響します。

WLAN単位の設定を使用すると、影響を受けるSSIDを制限でき、特定のWLANにグループ化されている場合は、デバイスタイプごとに変更を適用できます。これはバージョン7.6から利用可能です

たとえば、一般的な802.1x WLANには適用できますが、音声固有のWLANには適用できません。この場合、大きな影響を与える可能性があります

#1グローバル設定：

config advanced eap eapol-key-retries 0

（CLIのみのオプション）

この値は次の方法で検証できます。

(2500-1-ipv6) >show advanced eap

EAP-Identity-Request Timeout (seconds)........... 30

EAP-Identity-Request Max Retries................. 2

EAP Key-Index for Dynamic WEP.................... 0

EAP Max-Login Ignore Identity Response........... enable

EAP-Request Timeout (seconds).................... 30

EAP-Request Max Retries.......................... 2

EAPOL-Key Timeout (milliseconds)................. 1000

EAPOL-Key Max Retries............................ 0

EAP-Broadcast Key Interval....................... 3600

#2 WLANごとの設定

X=WLAN ID

config wlan security eap-params enable X

config wlan security eap-params eapol-key-retries 0 X

再送信がゼロになったためにクライアントが削除されたかどうかを確認する方法

クライアントは、最大EAPoL再試行に到達し、認証を解除したために削除されます。最初のフレームがカウントされるため、再送信カウントは1です

 *Dot1x_NW_MsgTask_6: Oct 19 12:44:13.524: 28:34:a2:82:41:f6 Sending EAPOL-Key Message to mobile 28:34:a2:82:41:f6
 state PTKINITNEGOTIATING (message 3), replay counter 00.00.00.00.00.00.00.01
..
*osapiBsnTimer: Oct 19 12:44:14.042: 28:34:a2:82:41:f6 802.1x 'timeoutEvt' Timer expired for station 28:34:a2:82:41:f6 and for message = M3
*Dot1x_NW_MsgTask_6: Oct 19 12:44:14.042: 28:34:a2:82:41:f6 Retransmit failure for EAPOL-Key M3 to mobile 28:34:a2:82:41:f6, retransmit count 1, mscb deauth count 0
..
*Dot1x_NW_MsgTask_6: Oct 19 12:44:14.043: 28:34:a2:82:41:f6 Sent Deauthenticate to mobile on BSSID 58:ac:78:89:b4:19 slot 1(caller 1x_ptsm.c:602)

不正検出

クライアントPMK/GTK暗号化に対する脆弱性に対するいくつかの攻撃手法では、インフラストラクチャAPと同じSSIDを持つ疑似APを「提示」する必要がありますが、異なるチャネルで動作する必要があります。これは簡単に検出でき、ネットワーク管理者は目に見えるアクティビティであるため、それに基づいて物理的なアクションを実行できます。

EAPoL攻撃を行うために、これまでに提案された2つの方法があります（EAPoL攻撃を行う方法は次のとおりです）。

• つまり、同じMACアドレスを使用して、実際のAPの不正なAPとして機能し、別のチャネルで動作するインフラストラクチャAP。攻撃者に対して簡単に実行できるが、見える
• 有効な接続にフレームを挿入し、クライアントに強制的に反応させます。これは非常に目に見えませんが、ある条件下で検出できます。成功するには非常に慎重なタイミングが必要になる場合があります 

AP偽装機能と不正検出の組み合わせは、「偽のAP」がネットワークに配置されているかどうかを検出できます。

コンフィギュレーション

• アクセスポイントで不正検出が有効になっていることを確認します。これはデフォルトで有効になっていますが、管理者が手動で無効にしている可能性があるため、確認する必要があります。
  

• 「管理対象SSID」を悪意のあるユーザとして使用して、不正にフラグを付けるルールを作成します。

• 両方の802.11a/bネットワークのチャネルモニタリングが「すべてのチャネル」に設定されていることを確認します。ベース攻撃は、RFの観点から見ると、クライアントが、インフラストラクチャAPで使用されるものとは異なるチャネルに近くなるように設計されています。そのため、すべての可能なチャネルを確実にスキャンすることが重要です。

AP偽装

デフォルト設定では、インフラストラクチャは攻撃ツールがAPのMACアドレスの1つを使用しているかどうかを検出できます。これはSNMPトラップとして報告され、攻撃が行われていることを示します。

Impersonation of AP with Base Radio MAC bc:16:65:13:a0:40 using source address of bc:16:65:13:a0:40 has been detected by the AP with MAC Address: bc:16:65:13:a0:40 on its 802.11b/g radio whose slot ID is 0  

    

参考資料

セキュリティアドバイザリ通知

v7.4を使用したUnified Wireless Networkでの不正管理：シスコ

CiscoワイヤレスLANコントローラ設定のベストプラクティス – Cisco

Unified Wireless Networkでの不正検出：シスコ