全Wi-Fi機器に影響する脆弱性「FragAttack」の仕組みとは？

　Mathy Vanhoef氏は、「FragAttack（Fragmentation and aggregation Attacks）」と名付けた今回の脆弱性の詳細について、関係当局に連絡を行った後に一定の猶予期間を経てfragattack.comsのウェブサイトで公開している。

　その原理について解説したドキュメント「Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation」（PDF）や、以下の動画も既に公開されている。

脆弱性3つのうち、「Frame Aggregation」が1つ、「Frame Fragmentation」が2つに起因

　FragAttackは大別して2種類3パターンの脆弱性から構成される。「Frame Aggregation」に起因するものが1つ、「Frame Fragmentation」に起因するものが2つである。

　前者のFrame Aggregationとは、複数の小さなパケットを個別ではなく、まとめて1つの大きなパケットにして送り出す方法である。

「Frame Aggregation」の原理。「USENIX Security '21」におけるプレゼンテーションより。右上は脆弱性発見者のMathy Vanhoef氏。出典は""FragAttacks: Presentation at USENIX Security '21"（YouTube）

　要するに、小さいパケットを大量に送ると、それぞれにヘッダーが付いたり、あるいはSend→ACKのやり取りが頻繁に発生したりするので、そのオーバーヘッドが馬鹿にならない。複数のパケットをまとめて1つにすることで、こうしたオーバーヘッドを大幅に軽減するというものだ。これはIEEE 802.11の当初から実装されていた機能である。

　そして、その逆が、後者Frame Fragmentationである。要するに、大き過ぎるデータパケットは送ることができないため、データを適正なサイズへと分割し、複数のパケットで送り出すことで対応するというものだ。

こちらは「Frame Fragmentation」の原理。両者とも、データを適切なフレームサイズに合わせるという意味では同じような機能。出典は""FragAttacks: Presentation at USENIX Security '21"（YouTube）

Frame Aggregation/Fragmentationを悪用!?する「FragAttack」

　このFrame Fragmentationも、やはりIEEE 802.11の当初から実装されていた。そして、FragAttackは、Frame AggregationとFrame Fragmentationについて、IEEE 802.11の仕様では想定されていなかった使い方（つまり仕様上の漏れ）をした場合に脆弱性が露呈する、というものだ。

　まずFrame Aggregationについて。簡単にまとめると、Frame Header内にある未認証フラグ（Unauthenticated Flag）を立てた際、暗号化された認証済みのpayloadは、通常のネットワークパケットではなく1つ以上の複数のパケットが含まれるAggregate Frameとして扱われることになる。

　これを利用して任意のフレームを注入し、悪意のあるDNSサーバーを利用させることで、第三者の通信が傍受可能となるというものだ。とはいえ、この説明は少し簡略化し過ぎているので、もう少しきちんと説明しよう。

　次は、標準的なIEEE 802.11のフレームの構造である。先頭がFC（Frame Control）である。受信者・送信者・宛先または送信元に続いて、Fragment No.とSequence No.が続き、QoS Control（QoS用の優先順位を定めるフィールド）、PN（Packet Number）が入った後で、データを格納するpayloadが続く格好になる。ちなみに、payloadは暗号化されていることが前提だ。

　厳密に言えば、Sequence No.の後にAddress 4が追加されていて、それぞれ「SA（Source Address）」、「DA（Destination Address）」、「TA（Transmitting STA address）」、「RA（Receiving STA address）」となっている。しかし、例えば直接通信であれば、SAが宛先、DAがBSSID、TAが送信元、RAは未使用などとなる。今回、RAは使われない場合を想定しているので、その点は流して欲しい。

赤はFrame Fragmentation Attackで、青はFrame Aggregation Attackで改変する部分。出典は"Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation"（PDF）

　上図の先頭にあるFCは、以下のような構造となっている。

FCの構造は、これ以外に、Frame Typeが1かつSubtypeが6の場合もあるが、今回の話には関係ないので割愛。出典は「IEEE Std 802.11-2016」のFigure 9-2

　FCそのもののサイズは2Bytes（16bit）だが、11bit目（B10）には"More Fragments"というフィールドがある。定義によれば「More Fragmentsサブフィールドは1ビット長で、現在のMSDUまたは現在のMMPDUに続く別のフラグメントを持つ全てのデータまたは管理フレームで1に、それ以外のフレームでは0に設定される」となっている。要するに、このbitが1であれば、複数のpayloadを詰め込んだFragmented Frameであると認識されるわけだ。

　一方のQoSはやや複雑だ。QoS Controlも同じく2Bytesのサイズだが、先頭4bitがTID（Traffic Identifier）に、6～7bit目がAck Policyに固定されているものの、これ以外はフィールドの意味やサイズがケースに応じて変わってくる。

ほかに、DMG PPDU（Directional Multi-Gigabit PHY Protocol Data Unit）のケースが2つほどあるが、これはIEEE 802.11adで追加されたDMG、要するに1Gbpsを超える通信の場合なので、ここでは置いておく。出典は「IEEE Std 802.11-2016」のFigure 9-2

複数のpayloadをつないで1フレームとして送りだす「A-MSDU」の仕組みを悪用

　ここでポイントとなるのは8bit目（Bit 7）のフィールドで、ここにA-MSDU（Aggregate MAC Service Data Unit）というbitが立つかどうかが重要になる。

　A-MSDUは、要するに複数のpayloadをつなぎあわせて1つのフレーム（最大8KB）として送り出すという技法だ。ほかに、payloadだけでなくMACフレームまでを連結してしまい、最大64KBまでにまとめて送る「A-MPDU（Aggregation-MAC Protocol Data Unit）」という方式もあるが、今回は考慮の対象外だ。

　以下がA-MSDUの模式図である。上段のNormalが標準的なIEEE 802.11のフレーム構造で言うところのpayloadにあたる。先頭のLLC/SNAP Headerに続いてIP Header、TCP Headerが付き、最後にデータ本体が格納される。

　このNormalの部分の前に、宛先と送信元、サイズを付加した1つ分のpayloadとして格納しものが、A-MSDU Subframeとなる。あとはこれを最大8KBまで繰り返すという仕組みだ。

ちなみに、繰り返し数は1以上なので、payloadは1つだけでも問題はない。出典は"Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation"

　さて、このフレームを受け取った受信者は、QoSフィールドにA-MSDUフラグが設定されていた場合、全てのA-MSDU Subframeを抜き出し、Subframeで指定された送信先と送信元のアドレスを持つEthernet Frameへと変換する。

　ここで問題となるのは、QoSフィールドは認証されているもののデフォルトではA-MSDUフラグは0にマスクされており、実際には認証されていないということだ。A-MSDUフラグを改変することで、受信者はpayloadにA-MSDUが含まれると誤った解釈をしてしまうため、これを悪用すれば、第三者が通常のフレームを傍受できてしまうわけだ。

偽のDNSサーバーへアクセスさせる2つの事例

　具体的に攻撃を行うには、まず前提として攻撃対象のクライアントのIPアドレスが既知になっている必要がある。これは、例えばダミーのウェブページへあらかじめ誘導しておいたり、ウェブ広告を悪用したりするなど、いくつかの手法が考えられる（これを知る方法そのものは、今回の話には含まれていない）。

　フレームが暗号化されたpayloadをどのように解析するかを受信者に通知しているA-MSDUフラグは、上で書いた通り認証の対象とはならない。厳密に言えば、SPP（Signaling and Payload Protected） A-MSDUをサポートすれば認証の対象になるはずだが、Vanhoef氏が調査した機器でこれを行っているものはなかったという。

　その結果、A-MSDUをサポートする全ての機器は、通常のFrameをA-MSDUとして処理することも、その逆も可能ということになる。そして、攻撃者は、通常のFrameにA-MSDUフラグを立てて、わざとA-MSDUとして被害者に送り出すわけだ。

　以下のA-MSDUの模式図は、上が通常のIPv4パケットとして認識される場合、下側がA-MSDUとして認識される場合を示している。最初のA-MSDU Subframeは（Source/Destinationが出鱈目だから）、もちろん意味をなさないが、これは犠牲者の側で単に破棄されて終わりである。

赤は固定値（LLC/SNAPやIP Header）、緑は攻撃者が完全に制御可能、黄色は部分的に制御可能なフィールドの各部分。出典は"Fragment and Forge: Breaking Wi-Fi Through Frame Aggregation and Fragmentation"（PDF）

　問題は、IDというかLength fieldを書き換えられることで、これにより攻撃者は2つ目のSubframeをこの後に追加できることになる。これにより、悪意を持った攻撃者が、任意のパケットを被害者に処理させることが可能となるわけだ。

　具体的な攻撃例としてVanhoef氏が示したのは、IPv4/v6 Stackを搭載したクライアントに対し、不正なICMPv6 RA（Router Advertisement）を注入して、偽のDNSサーバーにアクセスさせるという事例と、アクセスポイントに対して細工を施したEAPOL（EAP over LAN）フレームを送り付け、結果的にクライアントに偽のDNSサーバーへのアクセスを誘導するという事例の2つだ。

クライアントの場合（上）と、アクセスポイントの場合（下）の攻撃例。出典は""FragAttacks: Presentation at USENIX Security '21"（YouTube）