WiFiの暗号化機構のバイパス｜ブログ(ほぼこもセキュリティニュース)

ほぼこもセキュリティニュース　By Terilogy Worx

実装における問題が原因で脆弱性として悪用ができるケースがありますが、実装ではなくプロトコルの仕様における問題が原因で脆弱性として悪用できるケースもあります。
今回の話は後者に相当します。

WiFiはいろいろな場面で利用されています。
そしていろいろな場面で有効に使用するため、様々な機構が規格化されています。
そういった規格の中に、スリープ状態のデバイス宛てのフレームの取り扱いに関する部分があります。
この部分の仕様を悪用する手法が発見されています。
どんな流れで作用するのでしょうか。

流れているWiFiパケットを受信する
WiFiは無線通信で物理的な線を流れているわけではありませんので、そのパケットの傍受は比較的容易です。
物理的な距離が近ければ傍受することができます。
受信したパケットからWiFiクライアントのMACアドレスを取り出す
対象のWiFiで実際に通信ができている機器の使用しているMACアドレスを取得します。
なりすましてパケットを送信する
WiFiクライアントのMACアドレスを使って、WiFiのアクセスポイントに対してパケットを送信します。
送信するパケットは省電力フレームです。
さらにパケットを送信する
省電力フレームを送り付けられたアクセスポイントはその機器に送信するはずだったパケットのキューキングを開始します。
そこにさらにパケットを送信します。
次のパケットはウェイクアップフレームです。
一緒に別のパケットも送信する
ウェイクアップするとキューイングされていたパケットを受け取ることができます。
ただしそのとき、WiFiセッションの接続状態を変更することができる余地があります。
ウェイクアップするタイミングで認証フレームとアソシエーションフレームをアクセスポイントに送信するのです。
この内容を工夫することで、それ以降のWiFiパケットの内容を変更してしまうことができます。
プレーンテキストで送信させたり、攻撃者が提供するキーで暗号化させたりできるのです。

この動きができる機構は概念実証のコードがすでに作成されており、GitHubで公開されています。

この問題は実装の問題ではなく仕様の問題がベースになっています。
そのため、複数の環境が影響を受けます。
多くのWiFiアクセスポイント機能を持つ製品は対象になりそうですし、そういった機器だけではなく、Linux、FreeBSD、iOS、AndroidなどのOSの搭載された機器も同じ仕様を基にした機能を持っています。
こういったOSも影響範囲にあります。
TCP接続をハイジャックしたり、クライアントやWebトラフィックを傍受したりするために使用できてしまいます。

これは仕様の話ですので、緊急的に何らかのパッチを適用したら回避できるといった類のものではないかもしれません。
仕様のさらなる改善の検討が進んだ際には、この問題が発現しないように工夫された仕様が公表され、それを基にした実装がでてくるということなのでしょう。

WiFiはよく練られたプロトコルになってきていると思っていましたが、こういったものがでてくるのですね。
改めて物理セキュリティの重要性を感じます。