「FragAttack」を悪用した攻撃の足掛かりとなる脆弱性

Non-Con

　まずNon-Conは、「CVE-2020-26146」として認識されているが、要するにFragmentのパケット番号が連続しているかどうかのチェックをしないという脆弱性だ。

　受信側がこれを行わないと、受信したFragmentが同じFrameに属しているかどうかが確認できないことになる。今回のテストで言えば、Fragmentをサポートする68台の機器の内、実に52台がこの脆弱性を内包していた。この脆弱性を突いて、異なるパケットのFragmentを混ぜることでユーザーデータを流出させる攻撃が可能としている。

　この脆弱性は、CCMPとGCMP、それと再構成されたFrameが検証されていない場合にはTKIPにも影響を与える。面白いのは、2013年に導入されたGCMPでは暗号化されたFragmentが連続したPNを持たなければならない、とはSpecificationで要求されていなかったことだ。

　2015年にIEEE 802.11のWorkgroupがこの問題に気付き、GCMPでもPNのチェックを行うようSpecificationが改定された。ただ、これが理由で、LinuxのVersion 4.0～4.4でGCMPを利用すると、Fragmentを再構成する際にPNのチェックが行われないままとなっている。

Plain. frag.

　次のPlain. fragは、「CVE-2020-26147」として認識されており、暗号化されたFragmentと暗号化されない平文のままのFragmentを再構成してしまう、という脆弱性だ。これを悪用すると、攻撃者は暗号化されたFragmentを平文のFragmentへと置き換えられてしまう。以下がそのテストだ。

左が黒、右が白の丸：最初のFragmentが暗号化されていることを要求、21台
左が白、右が黒の丸：最後のFragmentが暗号化されていることを要求、9台
黒の丸　：Fragmentの1つが暗号化されていることを要求、3台

　ほかに11台は平文だけのFrameも受け付けているが、これは「CVE-2020-26140」として認識されている脆弱性だ。また、9台が、平文のFragment Frameは受け付けるものの、Fragmentされていない平文のFrameは受け付けないという問題（CVE-2020-26143）を抱えており、前者は雷の、後者は「◎」のマークで示されている。68台のデバイスのうち53台が、このように何らかの脆弱性を抱えているわけだ。

　ちなみに、LinuxにおけるDefragmentationのインプリメントでは、FragmentのPNが連続しているかどうかをチェックすることでFragmentが暗号化されているかを確認する仕組みを採用している。

　ただ、その実装を見ると、Frameの復号後にPNをセッション変数に格納して、FragmentのPNと比較する仕組みになっているが、結果として（2つ目の）平文Fragmentを受信した際に、単に前のFragmentのPNと番号が連続しているかどうかだけをチェックしており、それが平文か暗号化されているかまでチェックしていない。

　このため、連続したPNを持つが異なるシーケンス番号の、有効な暗号化Fragmentをまず転送し、その後で正しいシーケンス番号を持つ平文Fragmentを注入するという手順で、このPNチェックを回避できるとしている。

Bcast. frag.

　Bcast. frag.は、本来FragmentされないBroadcast FrameをFragmentして送り付けた場合に、これを受け取ってしまうという問題である。実際、いくつかのデバイスは、このFragmentされたFrameを、FragmentしていないFrameとみなして処理してしまう。

　また、セキュアなネットワークで暗号化されていないBroadcast Fragmentが送信された際に、2回目以降のBroadcast Fragment Frameを受け入れてしまう機器も存在する。これは「CVE-2020-26145」として認識されている脆弱性でもある。

　これを悪用し、2つ目のFragment化されたFrameにパケットをカプセル化して注入することが可能だ。こちらの影響を受ける機種はそれほど多くはないが、それでも影響を受ける機種があることが、結果から確認できる。

　なお、先の表における「TWFM-B003D」に記された上が白で下が黒の丸は、4-way Handshakeの実行中にのみ、この問題の影響を受けるということを示している。

Fake eapol

　Fake eapolのうち、まずCloaking A-MSDUs as handshake framesについて。クライアントはネットワークに接続する際に平文の4-way Handshakeを受け入れるが、この際に実装を誤ると、平文のA-MSDUを注入できてしまう。これは「CVE-2020-26144」として認識されている脆弱性である。これを悪用して、4-way Handshakeを実行中に平文のA-MSDUを注入できるというものだ。

　実際、「AWUS036ACH」をWindows 10で利用している環境に対して、これを悪用した攻撃を行うと、BSOD（Blue Screen of Death）が発生した。さらに、一部製品の実装には、A-MSDUの最初の8Bytesが有効なLLC/SNAPヘッダーと一致する場合、それを削除して取り扱うというものがある。これはSpecificationにそぐわない実装で、攻撃を防ぐことができない。

　次がFake eapolのうちEAPOL forwarding & fragmentationだ。クライアントはネットワークに接続する際に、平文の4-way Handshakeを受け入れる必要がある。ただ、一部機種では、そのHandshakeのFrameが、ネットワーク上のほかのクライアントに宛てたものだったとき、送信側の認証が済んでいなくても、これを転送してしまうという脆弱性「CVE-2020-26139」がある。

　このFake eapolに関する2つの問題を抱えているのは、FreeBSDとNetBSD AP、ASUS「RT-N10」、Linksys「WAG320N」など特定の家庭向けアクセスポイントである。攻撃者はこれを悪用し、マルチチャネルのMitM（Man-in-the-Middle）ポジションを利用してA-MSDU攻撃を行える。

　WindowsやmacOSでの影響はないが、家庭用ルーター（と業務用でもLANCOM「LN-1700f」）では影響があるほか、FreeBSDも全滅に近い。また、Windowsでもドライバーの作り次第ではBSODが発生するため、問題は決して軽微と言えるものではない。