特別編（7）Wi-Fiの脆弱性「FragAttack」を悪用した攻撃への対策とは？

　【光Ethernetの歴史と発展】編も、そろそろ終盤に差し掛かったところではあるが、既報の通り、ニューヨーク大学アブダビ校のMathy Vanhoef氏が発見した、Wi-Fiのプロトコルそのものに起因する脆弱性の仕組みや対処法について、解説していきたい。
　ちなみに、今回の脆弱性は、2017年に11月に「WPA2/WPA」の脆弱性を発見して公表したMathy Vanhoef氏が、オープンソースのWi-Fiスタックを分析し、IEEE 802.11の規格を体系的に調査していく中で新たに発見したものだそうだ。 「利便性を向上するWi-Fi規格」記事一覧Wi-Fiにおけるメッシュネットワークの必要性Wi-Fiメッシュ標準「IEEE 802.11s」策定の流れと採用技術Wi-Fiメッシュで通信コストを最小化する仕組みとは？「IEEE 802.11s」策定までの流れと採用技術11s非準拠のQualcomm「Wi-Fi SON」がWi-Fiメッシュの主流に「Wi-Fi SON」製品は相互非互換、Wi-Fi Allianceは「EasyMesh」発表最初のWi-Fi暗号化規格「WEP」、当初の目論見は“有線LAN同等のセキュリティ”Wi-Fi暗号化は「WPA」から「802.11i」を経て「WPA2」へより強固になった「WPA」で採用された「TKIP」の4つの特徴「AES」採用の「IEEE 802.11i」「WPA2」、11n普及で浸透WPA/WPA2の脆弱性“KRACKs”、悪用のハードルは？4-way Handshake廃止で「SAE」採用の「WPA3」、登場は2018年末？SSID＆パスフレーズをボタンを押してやり取りする標準規格「WPS」ボタンを押してSSID＆パスフレーズをやり取りする「WPS」の接続手順WPSのPIN認証における脆弱性を解消した「WPS 2.0」フリーWi-Fi向け「Wi-Fi CERTIFIED Enhanced Open」で傍受が不可能に暗号鍵を安全に共有する「Wi-Fi CERTIFIED Enhanced Open」「IEEE 802.11u」がPasspoint仕様である「Hotspot 2.0」のベースに国内キャリアも採用のホットスポット提供指標「WISPr」ホットスポットでの認証の問題を解消した「HotSpot 2.0」【特別編1】全Wi-Fi機器に影響、脆弱性「FragAttack」の仕組みは？【特別編2】脆弱性「FragAttack」悪用した攻撃手法とは？【特別編3】脆弱性「FragAttack」を悪用する3つ目の攻撃シナリオとその手法【特別編4】A-MSDUを悪用する「Frame Aggregation」を利用した攻撃の流れ【特別編5】「Mixed Key Attack」を利用した攻撃シナリオとその手法【特別編6】「FragAttack」を悪用した攻撃の足掛かりとなる脆弱性【特別編7】Wi-Fiの脆弱性「FragAttack」を悪用した攻撃への対策とは？#series-contents .current-page { font-weight: bold; }
　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自身の問題ではない）としながら、最新バージョンのドライバーおよびファームウェアへの更新を推奨している。
　設計側の不備に対応して実装を行ったことで、実装上の不備に対しての対応も行われた、ということだと思うが、こうしたセキュリティ対策が行われたベンダーの機器を使うのが、現時点でユーザーに可能な事実上唯一の対策と言うことになる。
　国内メーカーの機器の場合、筆者が探した限りでは現時点でこれに対応したファームウェアなりドライバを提供しているベンダーが見当たらないので、このあたりは今後の速やかな対応に期待したいところだ。
大原 雄介
フリーのテクニカルライター。CPUやメモリ、チップセットから通信関係、OS、データベース、医療関係まで得意分野は多岐に渡る。ホームページはhttp://www.yusuke-ohara.com/