Operation Smart Kettle – Börzels Blog

先週の土曜日、食料品の買い物をしているときに、特別オファーの棚でWi-Fi制御の「スマートケトル」を見かけました。これは、エイプリルフールのジョークとして書かれたHTTPステータスコード418「I'm a tea pot」を思い起こさせ、マストドンにジョークで投稿しました。その衝動は悪化し、結局、このハイテクデバイスの1つを購入して水を沸かすことにしました。 スマートWi-Fi IoTデバイスでプロジェクトやハッキングを行ったことがなかったので、どのように動作し、何を期待すべきか全く分かりませんでした。私の最初の考えは、スマートフォンアプリがケトルと直接通信し、ケトル上には何らかのサーバー/APIが動作していて、それに話しかけることができるだろうということでした。 まず、ケトルのベースを主電源に接続し、Wi-Fiボタンを押しました。ビープ音が鳴り、点滅し、そして驚くべきことに、独自のオープンアクセスポイントを起動しました。;) それに接続できましたが、DHCP経由でIPを配布しませんでした。 次の試みとして、Lidl Smart Homeアプリをスマートフォンにインストールし、初期設定を実行してWi-Fi認証情報を入力し、データが転送されるケトル自身のWi-Fiに接続しました。いくつかのビープ音の後、ケトルは私のWi-Fiに接続され、アプリで利用可能になりました。ここでは、沸騰させる水の温度を設定し、保温する時間を設定するという素晴らしいオプションがあります。また、さまざまな紅茶などのためのいくつかのプリセットされた「プログラム」/温度も提供されています。ケトルの状態と水温も表示されます。下部にはカレンダーアイコンがありますが、沸騰をスケジュールすることはできません。 ネットワーク上の新しいデバイスに関するFritzboxからの通知のおかげで、すでにそのIPアドレスを取得していました。それを使ってnmapスキャンを実行し、ケトルで何が動作しているかを確認しました。TCP 6668のポートが1つ開いていましたが、nmapはそのポートで何が動作しているかを特定できませんでした。netcatを使ってバナーを取得しようとしました。nc 192.168.178.70 6668接続は確立できましたが、何もバナーが返ってこず、何が動作しているかのヒントは得られませんでした。ブラウザで http または https://192.168.178.70:6668 を訪問しても失敗しました。あまりにも簡単すぎたでしょう。;) 次に、スマートフォンとケトル間のトラフィックを傍受するために、中間者攻撃用の偽のアクセスポイントを設定しようとしました。そのために、Kali VMを実行し、Alpha USB Wi-Fiドングルを接続しました。ホストOSのホームWi-Fiは、VMにeth0として有線ネットワークで接続されています。手動で設定したIPアドレスをインターフェースで上書きするため、ネットワークマネージャーサービスを無効にしました。 sudo systemctl stop NetworkManager.service eth0に固定IPを設定し、デフォルトルートをホームルーター（Fritzbox）に設定しました。 sudo ifconfig eth0 192.168.66.129/24 up sudo route add default gw 192.168.66.2 eth0 wlan0に固定IPを設定しました。 sudo ifconfig wlan0 10.0.0.1/24 up wlan0からeth0へのトラフィックを転送するためのiptablesルールを設定しました。 sudo sysctl -w net.ipv4.ip_forward=1 sudo iptables -P FORWARD ACCEPT sudo iptables --table nat -A POSTROUTING -o eth0 -j MASQUERADE DHCPサーバーを設定して実行しました。 cat dnsmasq.conf interface=wlan0 dhcp-range=10.0.0.10,10.0.0.250,12h dhcp-option=3,10.0.0.1 dhcp-option=6,10.0.0.1 server=8.8.8.8 log-queries log-dhcp cat fakehosts.conf 127.0.0.1 test.de sudo dnsmasq -C dnsmasq.conf -H fakehosts.conf -d APサービスを設定して実行しました。 cat hostapd.conf interface=wlan0 driver=nl80211 ssid=fake channel=1 sudo hostapd ./hostapd.conf Wiresharkを起動し、wlan0でリッスンしました。 偽のWi-Fiを設定した後、ケトルをリセットし、アプリで再度初期設定を実行しました。今回は偽のWi-Fiを使用するように設定しました。そして見てください、設定は成功し、アプリとケトルからのトラフィックを見ることができました。 少しがっかりしたのは、アプリとケトルの間の直接的なトラフィックを全く見ることができなかったことです。AzureクラウドのIPアドレスへのトラフィックのみでした。ケトルは定期的にTLS 1.2暗号化接続を介してクラウドに接続し、状態をプッシュし、新しいコマンドを取得しようとしていると推測されます。 私の次の考えは、TLS接続を破って何が起こっているかを見る方法でした。私たちは中間者/アクセスポイントなので、ケトルに偽の証明書を提供してトラフィックを暗号化し、Azureサーバーの公開鍵で暗号化して通常通りクラウドに転送することを試みることができます。Ettercapまたはbettercapならそれができると知っていますが、最終的には試しませんでした。 代わりに、Wi-Fiモジュールを製造したのは誰かを確認するために、簡単なMACアドレスルックアップを行いました。Tuyaです。新しい名前なので、Googleおばさんに聞いてみましょう。そしてここでtuya.comを見つけました。これは大きな「IoT」アズアサービスプロバイダーのようです。彼らのモジュールまたは完成品でデバイスを構築し、ロゴを付け、コントロールアプリを組み立て、Tuyaクラウドサーバーをバックエンドとして使用できます。手にWi-Fi IoTデバイスを持っていた場合、それはTuyaのものの一つである可能性がかなり高いようです。 しかし、ここで何があるでしょうか？ハードウェア、APIなどに関する完全な開発者ドキュメントがあります。https://developer.tuya.com/en。彼らはHTCPCPを話さないようです :( 私のトゥートへの返信（Zach、ありがとう）のおかげで、OTAファームウェアでWi-Fiコントローラーをフラッシュして、「解放された」ファームウェアをロードし、Tuyaクラウドなしで実行できる可能性があることを知りました。しかし、私のデバイスはそれには若すぎるようです。 https://community.home-assistant.io/t/kogan-smart-kettle/165466/63 https://github.com/tasmota/tasmotizer このように、IoTハッキングのこの小さな冒険は、失望の結末を迎えます。アプリとケトルの間の直接通信はなく、ケトルに話しかけるウェブサービスもなく、HTCPCPの実装もなく、エラー418もありませんでした。:( もしかしたら、ハードウェアで直接楽しいことができるかもしれませんね？;) しかし、それは別の小さな冒険のために取っておきましょう...！