A-MSDUを悪用する「Frame Aggregation」を利用した攻撃の流れ

Frame Aggregationを利用した攻撃の流れIPv4/v6クライアントのトラフィックを事実上全て傍受可能

　前回までに3種類の攻撃手法を紹介し、最後に実証テストの結果だけをまとめて示したが、攻撃手法に関する話を、もう少し具体的に解説したい。

　まず初回のFrame Aggregationを利用した攻撃について、その際にも掲載した以下の図にも少し出てくる攻撃の流れについて、細かく見ていこう。

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

　まず、IPv4およびIPv6ホストに対しては、ポートスキャンを行い、暗号化されたTCP SYN/ACK応答の長さに基づいてオープンポートを検出した。一方、IPv4/v6のDual Stack構成のクライアントには、ICMPv6ルーターのアドバタイズメントを注入し、被害者を騙して攻撃者の管理下によるDNSサーバーを使用させることができる。

　もう少し正確に言えば、IPv6のステートレスアドレス自動設定を悪用して、悪意のあるDNSサーバーを含むICMPv6ルーターのアドバタイズメントを注入する。これにより、Windows 10、macOS 10.15.4、Linux、Android 8.1およびiOS 13.4.1において、OSが利用しているDNSサーバーを「毒殺」できることが確認されている。

　この方式では、被害者が一度でも攻撃者の設置した悪意のあるDNSサーバーを使用すると、攻撃者は全てのトラフィックを自身の管理する悪意のあるサーバーにリダイレクトできるので、事実上クライアントのIPベースのトラフィックを全て傍受できることになる。

　ちなみに上では、IPv6ベースで悪意のあるDNSサーバーをホストするとしたが、必要ならばIPv4アドレスでDNS要求に応答させることも可能だ。

IPv4クライアントはトランザクション識別子を取得できれば同様に攻撃可能

　一方、IPv4のみのクライアントに対しては、そのクライアントがDHCPの検出と要求に含める4バイトのトランザクション識別子を取得できれば、同様の方法で攻撃が可能である。ただ、このトランザクション識別子は「RFC2131」で定義される“xid（transaction ID）”であり、通常は予測不可能だ。

　ところがiOSとmacOSでは、まず起動時にトランザクション識別子を生成した後は、DHCPリクエストを出すたびに、そのトランザクション識別子をインクリメントするという振る舞いが発見されている。また、MacOS Xではそもそもトランザクション識別子が予測可能であることが、「Cryptanalysis of IEEE 802.11i TKIP」という論文として既に発表されている。

　あるいは、Xiaomiのセキュリティカメラなどでは、トランザクション識別子は電源投入時にランダムに生成されるが、全てのDHCPリクエストの際、このトランザクション識別子が再利用される問題もある。

　そんなわけで、トランザクション識別子を何らかの方法で入手できたり、あるいはブルートフォースアタック（総当たり攻撃）によって力づくで見付けてしまえば、DHCPv4メッセージの偽造が可能となり、被害者に悪意のあるDHCPサーバーを使わせることができるわけだ。

　ついでに言えば、Vanhoef氏が手持ちのWi-Fiモジュール「ESP-12F」（Raspberry PiやArduinoでも利用でき、Amazon.co.jpでも購入可能）の場合、再起動されても同じトランザクション識別子を使っているそうで、もうこうなると、トランザクション識別子を推測するのは極めて容易と言わざるを得ない。

A-MSDUが積極的に使われる11ad対応機器は市場に存在せず

　もう1つ、特別編の第1回『全Wi-Fi機器に影響する脆弱性「FragAttack」の仕組みとは？』で、Frame AggregationではA-MSDUが悪用されやすいことを説明したが、「DMG（Directional Multi-Gigabit） Network」、要するに「IEEE 802.11ad」では、A-MSDUが積極的に使われる。

　その際には、Subframeがデータ長＋データのみで構成される「Short A-MSDU」の利用も可能だ。Short A-MSDU FlagはQoSフィールド内に定義されているため、Short A-MSDUは、DMG Frame内でのみカプセル化が可能であり、DMG Network内でのみ利用可能となっている。その結果、Short A-MSDU Flagは常に認証された状態で利用されることになるので、攻撃に用いることはできない。

　ただし、これは仕様上の話で、実際には脆弱性を含む可能性がある。具体的には、ハードウェアとしてはShort A-MSDU Flagをサポートして認証も行っているが、ソフトウェアというかネットワークスタック側がShort A-MSDU Flagをサポートしていない（あるいはサポートし忘れた、などの）場合があり得る。

　幸いというか不幸にもというか、「IEEE 802.11ad」は、2018年に公開した『60GHz帯の「IEEE 802.11ad」は普及進まず、「IEEE 802.11ax」の標準化進む』の段階でほとんど普及していないというか、普及に失敗していた規格だ。

　現時点では、IEEE 802.11ad対応機器は市場に存在していないというのが正確なところで、購入するのは大変に難しい。このため、上の懸念が実際に脆弱性として存在し得るかどうかは、確認できていないという話だった。

　一方、A-MSDU Frameを通常のFrameとして処理するよう、被害者を騙すという攻撃も理屈では考えられる。ただ、この場合、最初のA-MSDU Subframeの宛先MACアドレスがLLC/SNAPヘッダーの先頭として処理される関係上、宛先MACアドレスが「AA:AA:03:00:00:00」でないとLLC/SNAPヘッダーとしておかしくなるため、破棄されてしまうことになる。こうした制限が付く関係上、この攻撃が実際に行われる可能性は低いと判断できる。

　さて、実際の攻撃を行ったデモの様子をVanhoef氏がYouTubeで公開している。その18秒～3分28秒までが、Frame Aggregationを悪用した攻撃例だ。実際Vanhoef氏がニューヨーク大学アブダビ校のサイトにログインしようとした際のユーザー名とパスワードが盗み出せる様子が順を追って示される。

　この攻撃に対して脆弱性を持つのは、右表のA-MSDUの列に示された製品で、要するに試した全製品に脆弱性があったわけだ。コンシューマー向けのみならず、Aruba「AP-305」やCisco「Catalyst 9130」のような法人向けのアクセスポイントも例外ではない。

　唯一この脆弱性と無縁だったのは、表で示されているように、NetBSD（と、表に示されてないがOpenBSD）であった。なぜかと言えば、そもそもA-MSDUに対応していないというのがその理由である。

　テストは、TP-LinkのUSB Wi-Fiアダプター「TL-WN722N」2つでMulti-Channel MitM（Man-in-the-Middle）を実施している。説明によれば、「poc-aggregation.py」と言うツールでChannel Switchのアナウンスを偽造したそうで、動画で言えば59秒あたりからになる。

　その直後に起動したOutlookでメールをチェックした状況で、既にダミーのウェブページへ誘導するためのhtmlコードがインラインで埋め込まれている様子が示されている。後はもう手順通りである。

　ちなみに、これをFreeBSDおよびLinux 4.9以降でテストしたところ、A-MSDU Frameの先頭8Bytesが削除されていた。これは先頭8BytesをLLC/SNAPヘッダーと仮定し、これを削って残りを処理するという実装を行っていたためで、IEEE 802.11に規定されている処理としては正しくない。

　なお、こうした処理を実行してしまうと、最初のA-MSDU Subframeの長さフィールドは、ソースIPアドレスの最初の2Bytesに対応することになる。もちろんこれはイレギュラーなので、結局Frameが破棄されて終わりということになってしまう。

　また、被害者がファイアウォールを利用していない場合、IPv4パケットのソースIPアドレスを偽装することで、注入されたパケットが再び2番目のA-MSDU Subframeに含まれるようになる。

　もし、被害者が偽装されたIPアドレスをブロックした場合、攻撃者はAmazon AWSのサーバーを借りて「3.5.0.0/16」のIPアドレスを利用することで、これを回避できるとしている。この場合、最初のA-MSDU Subframeの長さは733Bytesとなり、悪意のあるパケットを注入するのに十分なスペースがあるとのことだった。