Go to Qiita Advent Calendar 2024 Top
LoginSignup
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@oc-namikiin株式会社ONE COMPATH

自宅Wi-Fiに接続してくるデバイスの調査

Last updated at Posted at 2024-07-01

本記事の要約

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

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

はじめに

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

事の始まり

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

image.png

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

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

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

image01.png

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

調査の開始

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

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

image0.png

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

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

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

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

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

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

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

Pingを送信してみる

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

image.png

なんか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から切断されたものの、数秒後に再接続してきました:thinking:

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

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

image.png

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

image03.png

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

犯人を発見

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

image.png

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

image00000000.png
「奴が切断された！」

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

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

image.png

しかし「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のままである

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

image.png

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でキャプチャしました。

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

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

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をキャプチャ出来ていないと復号化する事は出来ません。

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

  1. CommView for WiFiからpcapng形式でエクスポート

  2. Wiresharkにpcapngファイルをドラッグ＆ドロップ
    image000000000.png

  3. Wiresharkにデータフレームと送信元デバイスだけが表示されるようフィルタを設定

    wlan.fc.type == 2 and wlan.ta == 46:65:43:xx:xx:xx

    image00000.png

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

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

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

  • 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のような暗号化されていない場合を除き)データの部分が暗号化されておりそのままでは内容を確認する事が出来ません。

image000000.png

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

  1. Wiresharkでデータフレームを選択する

  2. IEEE 802.11フレームのヘッダを選択する

  3. 右クリック＞プロトコル設定 を選択＞IEEE 802.11 wireless LAN設定を開く＞Decryption keys　を選択する
    image0000000.png

  4. Decryption keys＞編集　を選択する
    image.png

  5. Key Typeを「wpa-pwd」、Keyに「パスフレーズ:SSID」のフォーマットで入力、OKを押下する
    image.png

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

内容を確認

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

image00000.png

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

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に送信され続けていました。
iamge00000000.png

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

この結果から

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

と考えられます。

おわりに

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

参考

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?