1

そこで私は、airbase-ng にはないように見えるオプションである、WPA 暗号化を使用して偽の AP を作成する可能性についてブレインストーミングを試みて、WPA と 4 ウェイ ハンドシェイク メカニズムを調べてきました。これまでの私の考えは次のとおりです。WPA-PSK 暗号化フラグを使用して偽の AP を作成し、その ESSID をターゲット AP の ESSID に設定しました。ターゲット AP に接続されているクライアントの認証を解除することにより、通常の反応は WiFi リストで AP を検索することになります。彼らは、私が取得しようとしているパスワードを使用して、偽の AP に接続しようとします。

このウィキペディアの 4 ウェイ ハンドシェイクのデモによると: https://en.wikipedia.org/wiki/IEEE_802.11i-2004#Protocol_operation PTK は、AP とステーション (クライアント) の間でオンザフライで共有されることはありません。代わりに、MIC が比較されます。パケット 2/4 で、ステーションは MIC で署名された SNonce を送信します。このパケットを受信した後、偽の AP は PTK の構築をスキップし、ランダムに割り当てられた GTK と MIC を含むパケット 3/4 を送信します (この MIC がクライアントによって検証されているかどうかはわかりません)。

私の質問は次のとおりです。クライアントはハンドシェイクの 3 番目のパケットから MIC を確認しますか? そうでない場合、それはクライアントが正常に認証され、AP に接続されたことを意味しますか?

さらなる考察: AP 側の PTK がない場合、DNS スプーフィングの目的で暗号化されていない未加工のデータ パケットをクライアントに送信できますか? 生データ パケットがクライアントによって受け入れられない場合、 GTKが偽AP？

私の質問が理解できていることを願っています。さらに説明が必要な場合は、喜んで返信いたします。

4

1 に答える 1

1

さて、私はIEEE Std 802.11-2012のドキュメントを読み、次の理由により私の概念は無効であり、実現不可能であるという結論に達しました: IEEE Stdの
セクション11.6.2 、ページの下部にある1249、次のステートメントが表示されます。

GroupKey または SMK KDE がキー データ フィールドに含まれているが、キー データ フィールドが暗号化されていない場合、EAPOL キー フレームは無視されます。

これにより、暗号化されていない GTK をサプリカント (クライアント) に送信するオプションが除外されます。偽の AP は実際の (クライアント側) を生成できないため、暗号化された GTK をサプリカントに送信することもできないことがわかっています。フォーウェイ ハンドシェイクの 3 番目の EAPOL メッセージで、キー データ (GTK を含む) の暗号化に必要な PTK。
WPA2 CCMP のキー データ フィールドの暗号化は、通常、IEFT RFC 3394に記載されている NIST AES キー ラップ アルゴリズムによって実現されます。

(IEEE Std のそのセクションに到達する前に) GTK が暗号化されていないサプリカントに送信される可能性があるという私の仮定も、完全な失敗に終わりました。1259 ページの IEEE Std 802.11-2012 のセクション 11.6.6.4 でさらに説明されています。

メッセージ 3 を受信すると、サプリカントは次のことも行います。
...
b) メッセージ 3 の MIC を確認します。計算された MIC が、Authenticator が EAPOL-Key フレームに含めた MIC と一致しない場合、サプリカントはメッセージ 3 を黙って破棄します。

ここでも、偽の AP は有効な PTK を生成できないため、メッセージ 3 の有効な MIC を計算できず、メッセージが破棄され、操作が失敗します。

于 2013-07-31T05:12:11.570 に答える