Wi-Fiの脆弱性「FragAttack」を悪用した攻撃への対策とは？

　FragAttackの攻撃手法と実際の攻撃手順、その結果は、前回までに説明し終えているので、今回は最後に、その対策についてまとめてみたい。

Frame Aggregation Attackへの対策はベンダー側の対応待ち

　まず、Frame Aggregation Attackについて。4回目にも書いたが、Frame Aggregation自体はA-MSDUを足掛かりにすることで容易になる。

　これは、以下表の結果で、A-MSDUをサポートしないNetBSD（とOpenBSD）が、Frame Aggregation Attackの影響をまるで受けないのに対し、サポートするWindowsやLinux、FreeBSDが影響を受けることを見れば明白である。つまり、対策はA-MSDUを無効化するか、SPP A-MSDUを使う、ということになる。

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

　「SPP（Signaling and Payload Protected） A-MSDU」、は要するに認証付きのA-MSDUだが、これは第1回で触れたように、Vanhoef氏が「調査した機器でこれを行っているものはなかった」としていた。

　つまり、少なくとも5月の時点でこれを実装した機器が皆無だった状況では、現実問題としてSPP A-MSDUを利用することは難しい。現実問題としてはOSの側でA-MSDUのサポートを外す（か、ドライバー側で外す）しかないだろう。

　ただ、ドライバーのプロパティでA-MSDUをオン／オフできるような製品は余りなさそう（本稿の執筆にあたり、Windowsで動作する手持ちのWi-Fiカード5枚のプロパティを確認してみたが、A-MSDUの設定が可能なものは1つもなかった）なので、ユーザーにできることはなく、ベンダー側の対応を待つしかない。

Mixed Key Attackへの対策では、全てのFragmentが同じ鍵で暗号化されているか要確認

　次が、Mixed Key Attackについて。これを防ぐには、受信者は全てのFragmentが同じ鍵で暗号化されているかを確認する必要があるのだが、残念ながらこれは現時点でIEEE 802.11に規定されていない。

　Vanhoef氏は、仕様と実装の両方が、これを確認するように改定されるべきである（"The standard and all implementations should be updated to include this check."）と、強い調子で提言を行っている。

　仕様の改定はともかく、実装を効率的に行う方法として、復号されたFragmentにインクリメンタルな鍵識別子を割り当て、これを新しい鍵が使われるたびに増やすことで、全てのFragmentが鍵識別子を使って復号されたかどうかを確認（新しい鍵が使われなければ、鍵識別子の値は最初と変わらないままだから、鍵識別子の初期値と比較するだけでいい）。ここで新しい鍵が使われていた場合は、そのFragmentを含むFrame全体を破棄するという方法を提案している。

　ちなみに、Fragmentationそのものをサポートしない、という実装もあり得る。これは最も簡単に実装ができる効果的な対処方法なのだが、その一方でFragmentがもともとデータサイズが大きい場合への対応策であることを考えると、Fragmentを無効化すると1つのFrameで扱えるデータサイズを小さく抑えざるを得なくなる。

　これは当然通信効率を下げることになり、電波の伝搬状況が悪い場所では通信の信頼性を下げることにもつながる。これは特に高速なIEEE 802.11acやIEEE 802.11axでは顕著だろう。また、Fragmentを無効化することには、こうした副作用があることに注意が必要だし、完全にMixed Key Attackが防げるわけでもない。そういう意味では、効果の割に副作用が大きいことになる。

　なお、ほかの実装方法として、新しい鍵がインストールされたらFragment Cacheをクリアする、という方法も考えられるが、そもそも複数の鍵がサポートされている場合にはMixed Key Attackそのものを防ぐことはできないため、余り意味がないとされている。

Fragment Cache Poisoning対策はネットワークへの接続やアソシエーション時のFragment Cacheクリア

　最後のFragment Cache Poisoningに関して言えば、クライアントがネットワークに対して再接続、あるいは再アソシエーションを行う際にFragment Cacheをクリアすれば対応できる。

　同様にアクセスポイントは、特定のクライアントがネットワークに接続／再接続、あるいはアソシエーションを行った際に、そのクライアントから受信したFragment Cacheの内容をクリアすることで回避できる。

　これは、実装はやや面倒かもしれないが、特に副作用もない方法だ。問題があるとすれば、そうした仕様が現在のIEEE 802.11は含まれていないことで、こちらについても仕様を改定すべき、としている。

脆弱性に起因する4つの問題を引き起こす実装上の不備にはベンダーの対応が必要」

　これとは別に6回目で紹介した4つの問題（Non-Con/Plain. frag./Bcast. frag./Fake eapol）に関しては、そこでも書いたように全てが脆弱性としてデータベースへ登録されている状態だ。

設計上の不備
• CVE-2020-24586：ネットワークの再接続時にメモリからフラグメントのキャッシュがクリアされないことにより、特定の状況下において攻撃者にパケットの内容を窃取される
• CVE-2020-24587：異なる鍵で暗号化されたフラグメントをリアセンブルしてしまうことにより、特定の状況下において攻撃者にパケットの内容を窃取される
• CVE-2020-24588：ヘッダ中のフレームアグリゲーションフラグが保護されていないため、攻撃者によりヘッダ情報を書き換えられ、不正なパケットが挿入される

実装上の不備
• CVE-2020-26139：送信者が認証されていない場合でもEAPOLフレームを転送してしまう
• CVE-2020-26140：保護されたネットワークにおいて、平文のデータフレームを受け入れてしまう
• CVE-2020-26141：フラグメント化されたフレームのTKIP MICが検証されない
• CVE-2020-26142：フラグメント化されたフレームをフルフレームとして処理してしまう
• CVE-2020-26143：保護されたネットワークにおいて、フラグメント化された平文のデータフレームを受け入れてしまう
• CVE-2020-26144：暗号化されたネットワークにおいて、EtherTypeにEAPOLが指定されたRFC1042ヘッダを持つ、平文のA-MSDUフレームを受け入れてしまう
• CVE-2020-26145：暗号化されたネットワークにおいて、平文のブロードキャストフラグメントをフルフレームとして受け入れてしまう
• CVE-2020-26146：連続しないパケット番号を持つ暗号化されたフラグメントをリアセンブルしてしまう
• CVE-2020-26147：暗号化されたフラグメントと平文のフラグメントを混合してリアセンブルしてしまう

　上記のうち設計上の不備については、IEEE 802.11そのものへの改定となるのでとりあえずおいて、実装上の不備として挙げられている9項目については、クライアントなりアクセスポイントなりが対応を行えば、直近でのFragAttackへの対応には十分である。問題は、ベンダーがどの程度迅速に対応するかだ。

　一つ例をあげれば、Intelの場合、CVE-2020-24586/24587/24588（つまり設計上の不備）に対し、Non-Intel issue（Intel自身の問題ではない）としながら、最新バージョンのドライバーおよびファームウェアへの更新を推奨している。

　設計側の不備に対応して実装を行ったことで、実装上の不備に対しての対応も行われた、ということだと思うが、こうしたセキュリティ対策が行われたベンダーの機器を使うのが、現時点でユーザーに可能な事実上唯一の対策と言うことになる。

　国内メーカーの機器の場合、筆者が探した限りでは現時点でこれに対応したファームウェアなりドライバを提供しているベンダーが見当たらないので、このあたりは今後の速やかな対応に期待したいところだ。