「Mixed Key Attack」を利用した攻撃シナリオとその手法

　今回は『【特別編2】脆弱性「FragAttack」悪用した攻撃手法とは？』で紹介した「Mixed Key Attack」を利用した攻撃について詳しく解説しよう。

　ちなみにこの攻撃、脆弱なアクセスポイントに対する攻撃手法とされるが、技術的に言えば、脆弱なクライアントに対しても同様の手法で攻撃可能だ。ただ、パケットを偽造した場合、そのTCPなりUDPのチェックサムが（偽造前と）一致する確率は「2^-16」と非常に低く、あまり効果的ではない。

Unicast Frameを2つのキーで暗号化するオプションと組み合わせれば、脆弱性の悪用が容易に

　ただ、通常のTCPなりUDPではなく、UDP-Liteで動作するマルチメディアのストリーミングパケットの場合、UDP-Liteのチェックサムはパケットの一部に対してしか適用されない（これは全部に対して適用すると、その処理のオーバーヘッドが馬鹿にならず、リアルタイムストリーミングがリアルタイムでなくなってしまう、という懸念によるもの）ため、結果としてチェックサムを有効にしたままでもデータの改ざんが可能（というか現実的）ではあるが、適用範囲はかなり限られてしまう。

　現実的にクライアントへ攻撃を行う場合には、『【特別編3】脆弱性「FragAttack」を悪用する3つ目の攻撃シナリオとその手法』で解説したFragment Cacheへの攻撃と組み合わせることになるだろう。

　IEEE 802.11には、送信側がUnicast Frameを暗号化するために、2つのキーを選ぶことが可能なオプション機能が含まれている。このキーは有効期限が決まっているので、例えば、現在進行中の送信に使っているキーが、次に始める送信の途中で有効期限を迎えてしまいそうな場合、現在利用しているキーとは別に新しいキーを生成し、これを利用できるというもので、IEEE 802.11の12.6.21（RSNA Rekeying）で規定されている方式である。

　これは、セッションキーをスムーズに切り替えるには便利な規定で、利用するキーを識別するキーIDをヘッダーに含めることで可能となる。これを悪用すると、異なるキーで暗号化された2つのFragmentを被害者に送り付けるという攻撃が可能だ。特にターゲットが一定時間を経過してタイムアウトした後に、Fragmentをキャッシュから削除した場合、あるいはFragmentの間に送られたFrameが、被害者側でのFragment再構築を妨害した場合など、攻撃がより容易になるとされる。

脆弱性は「WEP」や「TKIP」にも、1997年のWi-Fi登場時から内包

　さらに余談だが、今回発見された欠陥は、「WEP」や「TKIP」にも当てはまるもので、Linuxを利用して動作を確認している際に、経験的に確認されたという。ということはこの欠陥は、1997年にWi-Fiが世の中に登場したときから内包されていたという話にもなる。

　さらに、WEPを利用した場合、Fragmentに連続したパケット番号（＝初期化Vector）を必要としないため、同じキーで暗号化された2つのFrameのFragmentを混在させることすら可能だ。

　一方、TKIPはCCMPやGCMPと異なり、Authenticity checkを個々のFragment単位ではなくFrame全体に対して行うため、これが正しく実装されていれば本来は影響を受けない。ところが実際には、これが行われていない機種が少なからずあったという。

　具体的に言えば、ALFAの「AWUS036H」や「AWUS036ACH」、TP-Linkの「TL-WN725N」は、Windows用ドライバーでAuthenticity checkを行われていなかったそうだ。AWUS036ACHとZyxelの「NWD6505」のLinux用ドライバーも同様だったという。そんなわけで、仕様上はともかく実際は影響を受けるケースがあるようだ。

ALFAの「AWUS036H」

TP-Linkの「TL-WN725N」

特定のFragment番号とシーケンス番号を持つFrameを注入

　この攻撃を実際に行う場合、特定のFragment番号とシーケンス番号を持つFrameを注入することになる。ただ、これを標準ドライバーで実施した場合、これらのフィールドが上書きされてしまったり、異なる優先度を持つFrameを並べ替えてしまったりする危険性があり、このままだと攻撃の妨げになる。

　そこでVanhoef氏は、Wi-Fiアダプターへパッチを当ててこれを回避したという。Intel製カードはドライバーに、Atheros製カードはドライバーとファームウェアの両方にパッチを適用したとの話だった。

　最初のテストでも利用したTP-LinkのTL-WN722Nの場合で言えば、テストツールが対応しているLinuxの仮想インターフェースを利用したが、複数を使用した際にカーネル関数「ieee80211_tx_h_sequence」がシーケンス番号を上書きしないようにするため、「0」以外のシーケンス番号は変更しないというパッチを適用したという。

　また、ファームウェアがシーケンス番号やFragment番号を上書きするのを防ぐため、「ath_tgt_tx_seqno_normal」が「wh->i_seq」および「wh->i_seq[0]」を修正しないようなパッチを当てたという。さらに、異なる優先度を持つ注入されたFrameが（QoSの仕組みで）並び替えられないようにするため、フレームの優先度に関係なく「tx_hdr.tidno」をゼロに設定するよう「ath9k_htc_tx_data」を修正したそうだ。これらに加え、そのほかのカード用のパッチを含むソース、および関連資料はGithub上で公開されている。

一部の業務用アクセスポイントを除き、全Wi-Fi製品がMixed Key Attackの攻撃対象に

言うまでもなく赤が問題あり、緑が問題なし

　さて、デモ動画「FragAttacks: Presentation at USENIX Security '21」（YouTube）では、こうした手順は示されていないので、結果だけを見ていこう。右や下の表で「Mixed Key」と書かれている項目が、このMixed Key Attackの結果を示している。

　まずデバイスで言えば、全てのクライアントと家庭用アクセスポイントは全滅である。Aruba「AP-305」とCisco「Catalyst 9130」は、業務用アクセスポイントとあって影響を受けていない。AP-305はFragmentの間に送られたFrameは再構築の対象から外しているし、Catalyst 9130ではPairwise Session KeyのRekeyingそのものをサポートしていない。このためMixed Key Attackそのものが不成立となっている。ただ、同じく業務用のLANCOM「LN-1700」では成立してしまっている。

A-MSDUはLinuxが見事に全滅なので、Windowsの方が問題が多いとも一概には言いにくい。出典は"Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation"

FreeBSDやNetBSDは、そもそも対応ドライバーのある製品が減っている。ちなみに上の7つはClient Mode、下の4つはAccess Point Modeでの振る舞い

　FreeBSDおよびNetBSDの結果には少し説明が必要だ。シナリオ通りのMixed Key Attack、およびFragment Cache Poisoningは、基本的にFreeBSDおよびNetBSDに対しては無効だった。これは、FragmentとFragmentの間に、同じ送信者から送られる無関係なFrameを受信した場合、そのFragmentを拒否するためである。

　ただ、FreeBSDはBroadcast Frameに関しては関係なくDefragmentationを行う。これを利用し、Broadcast受信者のアドレスを持つA-MSDU Frame内に4-way Handshake Frameをカプセル化することで、Defragmentationに影響を与えずに転送可能である。この場合、A-MSDU Subframe内の宛先MACアドレスは、受信者（＝被害者）のUnicastアドレスと等しくなる。

　ただ、これを実行するには、通信相手が平文で4-way Handshakeを行う必要がある。通常、Mixed Key Attackの際のRekeying Handshakeでは平文の4-way Handshakeにはならないのだが、RT-AC51U APはRekey時に平文で4-way Handshake Frameを行うことが発見された。

　そこで、FreeBSD Clientがこうしたアクセスポイントへ接続されている場合、攻撃者は平文の4-way Handshakeのメッセージをキャプチャし、それをブロードキャストA-MSDUフレームにカプセルすることで、送り付けることができる。これにより、Defragmentation処理へ影響を与えずにFreeBSDがRekeyingを行うため、結果として攻撃者はFreeBSDに対してMixed Key Attackが実行できたという。

　また、これは次回に詳しく解説するが、TL-WN725Nをネットワークカードとして使用している場合は、Fragment Cache Poisoningも可能になるという。要するに、OSレベルではある程度の防御ができていても、ドライバーの作り方次第では脆弱性が発生するということある。