SO-AND-SO による報告:

wpa_supplicantがEAPOL-Keyフレームを処理する方法に脆弱性が見つかりました。攻撃者が、フレーム内で有効なMIC値を必要とせずに（つまりフレームを認証せずに）、wpa_supplicantにKey Dataフィールドを復号させる方法で、フレームを変更する可能性があります。この場合、WPA2/RSNスタイルのEAPOL-Key構造がペアワイズ暗号としてネゴシエートされたTKIPで使用される際に、潜在的な問題があります。注意：WPA2は、TKIPとともにペアワイズ暗号として使用されることは想定されていません。代わりに、CCMPが使用されることが想定されており、そのペアワイズ暗号では、この脆弱性は実際には適用されません。

TKIPがペアワイズ暗号としてネゴシエートされる場合、EAPOL-Key Key DataフィールドはRC4を使用して暗号化されます。この脆弱性により、認証されていないEAPOL-Keyフレームが処理される可能性があります。またRC4の設計により、攻撃者がコンテンツを知らなくてもビット単位のXOR操作で平文バージョンのKey Dataフィールドを変更する可能性があります。これは、（攻撃者がキーを学習せずに）ステーションでGTK/IGTKを変更することで、サービス拒否攻撃を引き起こすために利用される可能性があります。これにより、受信したグループアドレスフレームをステーションが受け入れることができなくなります。さらに、wpa_supplicantを復号化オラクルとして機能させ、Key Dataペイロード（GTK/IGTK）の一部を復元してグループ暗号化キーの知識を取得させることで、これが悪用される可能性があります。

グループ暗号化キーを完全に復元するには、複数の試行（オクテットあたり128回の接続試行）が必要ですが、4ウェイハンドシェイクの完了に失敗するため、試行ごとに接続が切断されます。これらの失敗により、AP/ネットワークが一時的にまたは永続的に無効になり（再び有効にするためにはユーザーアクションが必要）、APがグループキーを変更する前にキーを復元する攻撃を実行することが困難になる可能性があります。デフォルトでは、wpa_supplicantは、失敗した各接続試行の間に少なくとも10秒の待機時間を強制しています。つまり、TKIPを使用する場合、hostapd APの実装がGTKキー再生成に対して10分のデフォルトを使用するのに対して、各オクテットの回復を20分以上待機します。このようなタイミングの動作により、実際の攻撃では、変更前にキーを判断できる十分な情報をGTKから復元できるようにするために、影響を受ける多数のステーションが同じAPへの接続を試行する必要があります。

検出

FreeBSD : wpa_supplicant -- 認証されていない暗号化 EAPOL-Key データ (6bedc863-9fbe-11e8-945f-206a8a720317)

high Nessus プラグイン ID 111720

依存が見つかりません