本記事の要約

株式会社 ONE COMPATHの並木です。

自宅のWi-Fiに見ず知らずのデバイスが勝手に接続してきました (と勘違いした)
自宅のWi-Fiに勝手に接続してきたデバイスを特定しました
勝手に接続してきたデバイスがどんな通信をしているのか確認しました

はじめに

先日、自宅のWi-Fiに突然見知らぬデバイスが接続をしてきました。
「第三者が勝手に自宅のWi-Fiに接続しているのでは」という恐怖に苛まれつつ、問題のデバイスを特定する迄の経緯を記事にさせて頂きます。
又、記事後半ではWi-Fiフレームのキャプチャから復号化迄の手順についてカロリー低めに記載をさせて頂きます。

事の始まり

自宅にてWi-Fiの検証をしていたある日、見知らぬデバイスが検証用AccessPoint(以下、検証用AP)に接続している事に気が付きました。

検証用APに接続する為にはパスフレーズ(WPA2-PSK)が必要です。
検証用APのパスフレーズを登録しているデバイスは自身のiPhoneのみであり、第三者にパスフレーズが漏洩していない限り(又は4way-handshakeをキャプチャされaircrack-ngやhashcatで解析されなければ)自身のiPhone以外、デバイスが検証用APに接続をするという事は出来ません。

パスフレーズが"password"や"12345678"のような酷い物の場合を除きます。

inSSIDerというアプリケーションで確認すると問題のデバイスが検証用APと通信をしている様子が表示されます。

このデバイスは一体何者なのか、調査を開始しました。

調査の開始

問題のデバイスの情報を確認する

まず、inSSIDerを用いて問題のデバイスのMACアドレス、IPアドレスを確認します。
inSSIDerはデバイスのMACアドレスやIPアドレス、使用チャンネルやRSSI、チャンネル使用率やフレーム数等の情報を視覚的に確認する事が出来る非常に有益なツールです。

問題のデバイスの電波状況は

使用周波数帯：5GHz
受信感度(RSSI)：-48dBm

と確認する事が出来ます。

5GHzの周波数帯は減衰が激しく、離れた場所まで届きにくい特徴があります。
その5GHzでありながら受信感度は-48dBmという強めの値が出ている事より、問題のデバイスはお隣の家や自宅近辺にあるのではなく自室の何処かに問題のデバイスがあると推測しました。

MACアドレスからベンダーを調査する

MACアドレスからベンダーを調査し問題のデバイスの特定を試みました。

問題のデバイスはランダムMACアドレスを利用している様子で、該当するベンダーは見当たらずデバイスを特定する事は出来ませんでした。残念・・・

Pingを送信してみる

問題のデバイスにIPアドレスが割り当たっている様子の為、Pingを送信してみました。

なんかPingが通ったり通らなかったりする・・・

APのログファイルを確認してみる

望み薄ですが検証用APのログファイルから何か情報が無いか確認をしてみました。

3:57:04	Client	Deauthenticated:Client MAC:46:65:43:xx:xx:xx, IpAddress:(192.168.0.11)
3:55:40	Client	Associated:Assigning Ip Address:(192.168.0.11) to Client MAC:46:65:43:xx:xx:xx.	
3:55:38	Client	Association:Client MAC:46:65:43:xx:xx:xx
1:15:18	Client	Deauthenticated:Client MAC:46:65:43:xx:xx:xx, Ip Address:(192.168.0.11)
1:13:13	Client	Associated:Assigning Ip Address:(192.168.0.11) to Client MAC:46:65:43:xx:xx:xx.
1:13:13	Client	Association:Client	MAC	46:65:43:xx:xx:xx
0:31:17	Client	Deauthenticated:Client	MAC:46:65:43:xx:xx:xx, Ip Address:(192.168.0.11)

検証用APのログファイルを確認して分かった事は

日中に検証APへの接続は無い
夜中に検証APへの接続がある

という2点だけでした。

APからデバイスの切断を試みる

検証用APから問題のデバイスに対して切断要求(Deauthentication)のフレームを送信し強制的に切断を試みました。
問題のデバイスは検証用APから切断されたものの、数秒後に再接続してきました

iPhoneのWi-FiをOFFにしてみる

「検証用APにはiPhoneしか接続できない」=「iPhoneのWi-FiをOFFにしたら何か改善するかも」と思いiPhoneのWi-FiをOFFにしてみました。

しかしながら問題のデバイスは検証用APに接続された状態を維持しています。

inSSIDerからもiPhoneの表示は消えましたが問題のデバイスは検証用APに絶賛接続中のまま変わらず。。。

犯人を発見

問題のデバイスが見つからず~~検証用APのパスフレーズを変更して現実から目をそらそうと~~半ば諦めかけた時、ふとiPhoneの接続先SSIDを別のSSID(別のAP)に変更してみました。

すると問題のデバイスが切断された様子をinSSIDerから確認する事が出来ました。

「奴が切断された！」

上記の動作からiPhoneとペアリングをしている機器が怪しいと考え、充電中のApple WatchのMACアドレスを確認した所、問題のデバイスのMACアドレスと合致しました。

iPhoneのWi-Fiネットワーク情報がApple Watchにも同期される事はApple Watchを使用していて何となく把握しておりました。

しかし「iPhone側でWi-FiをOFF」にすれば「Apple Watch側もWi-FiがOFF」になると勝手に思い込み、問題のデバイスがApple Watchであるという事は全く予想していませんでした。

興味深いのは

iPhone側でWi-FiをOFFにすればApple Watch側もWi-FiがOFFになる
という事は無く
iPhone側でWi-FiをOFFにしてもApple Watch側はWi-FiがONのままである

という動作をする点です。

Apple Watchの動作仕様に詳しい方であればすぐに解決出来た問題かと思いますが、自身の知識不足と思い込みで解決までに時間を要してしまいました。

最終的に「もしや第三者が自宅のWi-Fi環境に接続しているのでは」という夜眠れず、昼寝する日々から解放されました。

Apple Watchは何を送信していたのか

問題のデバイスはApple Watchである事が特定出来ました。
しかしApple Watchが検証用APにどんなデータを送信していたのか気になりApple Watch⇔検証用AP間のWi-Fiをキャプチャしてみました。

Wi-Fiのフレームをキャプチャして復号化する場合、必ず自身が管理運用しているWi-Fiネットワークで且つ自身のデバイス間の通信のみを対象として下さい。

キャプチャの実施

Wi-Fiのフレームをキャプチャするには以下の2つの方法があります。

WindowsOSの場合：対応するネットワークインターフェイスアダプタを用いる
MacOSの場合：標準搭載のスニファ機能を用いる

今回はASUS USB-AX56というアダプタとCommView for WiFiというアプリケーションを用いてWindowsOSでキャプチャしました。

具体的な手順は以下の通りです。

inSSIDerを用いてキャプチャしたいデバイスが使用しているチャンネルを確認する
WindowsOS端末とASUS USB-AX56をUSB接続する
CommView for WiFiを起動しキャプチャしたいチャンネルを選択する(マルチチャンネルを使用している場合は使用中のプライマリチャンネルを選択して下さい)
「キャプチャの開始」ボタンを押下する

MacOSでのキャプチャ方法は以下のURLをご参考下さい。

Wiresharkで確認

キャプチャしたWi-FiフレームをWiresharkで確認します。
更にApple Watchから検証APに送信されたWi-Fiフレームだけを抽出して表示します。

WPA2-PSKの場合、パスフレーズとSSIDからPMKを生成し、PMKとNonceの値からPTKを生成、PTKに含まれるTKでフレームのデータ部分を暗号化します。Nonceの値は4way-handshake時にAPとSTAとで交換し合う為、4way-handshakeをキャプチャ出来ていないと復号化する事は出来ません。

具体的な手順は以下の通りです。

CommView for WiFiからpcapng形式でエクスポート
Wiresharkにpcapngファイルをドラッグ＆ドロップ
Wiresharkにデータフレームと送信元デバイスだけが表示されるようフィルタを設定
```
wlan.fc.type == 2 and wlan.ta == 46:65:43:xx:xx:xx
```

metageek社から公開されているWireshark用のプロファイルを使用するとフレームの種類毎に色分けをしてくれて視認性が高まるのでお勧めです。

https://support.metageek.com/hc/en-us/articles/115013527388-Wireshark-Configuration-Profile

Wi-FiフレームをWiresharkで見ると様々なデータが見えてきます。

Radiotop Header：L1の情報を符号化したフィールド
802.11 radio information：L1やRadiotop Headerを簡潔に纏めたフィールド
IEEE 802.11 QoS Data：IEEE 802.11フレームのヘッダ情報のフィールド
Data：IEEE 802.11フレームに含まれるデータ

Wiresharkで復号

キャプチャしたWi-Fiフレームは(オープンWi-Fiのような暗号化されていない場合を除き)データの部分が暗号化されておりそのままでは内容を確認する事が出来ません。

Wiresharkで暗号化されたデータ部分を復号化する具体的な手順は以下の通りです。

Wiresharkでデータフレームを選択する
IEEE 802.11フレームのヘッダを選択する
右クリック＞プロトコル設定を選択＞IEEE 802.11 wireless LAN設定を開く＞Decryption keys　を選択する
Decryption keys＞編集　を選択する
Key Typeを「wpa-pwd」、Keyに「パスフレーズ:SSID」のフォーマットで入力、OKを押下する

今回はWPA2-PSKで暗号化されたデータの復号化を行っています。WPA3で暗号化されたデータは復号化出来ない事に注意して下さい。WPA3 はパスフレーズを認証にのみ使用する為、復号化する事は出来ません。

内容を確認

復号化に成功するとWi-Fiフレームのデータ部分を確認する事が出来ます。
データフレームとヌルデータフレームが繰り返し検証用APに送信され続けている様子が分かります。

復号化前は「Data」としか表示されなかった部分が「Logical-Link Control」と「Address Resolution Protocol」になっている事が分かります。デフォルトゲートウェイへのARPである事が確認出来ます。

Logical-Link ControlはIEEE 802.2LLCヘッダです。LLCヘッダの中にL2より上位のL3に関するプロトコルの情報(IPパケットの種類や情報)が付与されます。
LLCはWi-Fiフレーム(802.11)特有の物で、有線(EthernetⅡ)ネットワークではEhternetフィールドで上位プロトコルの情報を付与する為、LLCは存在しません。

ヌルデータフレームに関してはApple Watchと検証用AP間とで通信が完結しており、wlan.fc.pwrmgtフィールドに1と0を交互に設定したヌルフレームが繰り返し検証用APに送信され続けていました。

更にこれらのフレームがApple Watchから検証APに送信されるタイミングやシチュエーションを検証してみました。結果、Apple Watchが充電中で且つスリープ状態となった際に、これらのフレームが送信されている様子を確認しました。

この結果から

Apple Watchが充電中で且つスリープ状態となった
検証用APとの接続を維持する為、キープアライブの目的でデータフレームとヌルデータフレームを送信した

と考えられます。

おわりに

Wi-Fiフレームの流れや構造をWiresharkで眺めているとたった1つのデータを送信するだけでもデータ以外の様々なフレームが流れている事が見えてきます。
「玄関開けたら2分でご飯」のように「Wi-Fiを繋げたら即データ送信」とならないのがWi-Fiの難しい所と感じます。あと"当たり前を疑おう"。

参考