Operation Smart Kettle – Börzels Blog

Operation Smart Kettle

［画像: Blog post featured image］

先週の土曜日、食料品の買い物をしているときに、特売コーナーでWi-Fi制御の「スマートケトル」を見かけました。これは、エイプリルフールのジョークとして書かれたHTTPステータスコード 418 "I'm a tea pot" を思い起こさせ、マストドンに冗談で投稿しました。

まあ、その衝動は悪化し、ついにこのハイテクデバイスの1つを購入して、お湯を沸かすことにしました。

スマートWi-Fi IoTデバイスでプロジェクトやハッキングを行ったことがなかったので、それがどのように機能するのか、何を期待すべきなのか全く分かりませんでした。私の最初の考えは、スマートフォンアプリがケトルと直接通信し、ケトルには何らかのサーバー/APIが動作していて、それにアクセスできるだろうということでした。

まず、ケトルのベースを主電源に接続し、ボタンを押しました。ビープ音が鳴り、点滅し、そして驚くべきことに、独自のオープンアクセスポイントを起動しました。 ;)

［画像: Pasted%20image%2020230109204730］

それに接続できましたが、DHCP経由でIPアドレスは配布されませんでした。

次の試みとして、スマートフォンにLidl Smart Homeアプリをインストールし、初期設定を実行しました。そこでWi-Fi認証情報を入力し、ケトル自身のWi-Fiに接続してから、データがケトルに転送されました。何度かビープ音が鳴った後、ケトルは私のWi-Fiに接続され、アプリで利用できるようになりました。

ここでは、お湯を沸かす温度を設定したり、保温時間を設定したりする素晴らしいオプションがあります。また、さまざまな紅茶などのためのいくつかのプリセットされた「プログラム」/温度も提供されています。ケトルのステータスと水温も表示されます。下部にはカレンダーアイコンがありますが、沸騰をスケジュールすることはできません。

［画像: Pasted%20image%2020230109210821］ ［画像: Pasted%20image%2020230109210838］ ［画像: Pasted%20image%2020230109210853］

ネットワーク上の新しいデバイスに関するFritzBoxからの通知のおかげで、すでにIPアドレスを取得していました。それを使ってnmapスキャンを実行し、ケトルで何が動作しているかを確認しました。

［画像: Pasted%20image%2020230109211239］
TCP 6668ポートが1つ開いていましたが、nmapはそのポートで何が動作しているかを特定できませんでした。netcatを使ってバナーを取得しようとしました。

 nc 192.168.178.70 6668

接続は確立できましたが、動作しているものを示唆するバナーは何も返ってきませんでした。
ブラウザで http または https://192.168.178.70:6668 を開いても失敗しました。あまりにも簡単すぎました。 ;)

そこで次に、スマートフォンとケトル間のトラフィックを調べるために、偽のアクセスポイントを設定してMan-in-the-Middle攻撃を試みることにしました。

［画像: Pasted%20image%2020230109212121］

そのために、Kali VMを実行し、Alpha USB Wi-Fiドングルを接続しました。ホストOSのホームWi-Fiは、VMのeth0に有線ネットワークとして接続されています。

1. インターフェース上の手動設定IPを上書きするため、ネットワークマネージャーサービスを無効にします。

   sudo systemctl stop NetworkManager.service
   

2. eth0に固定IPを設定し、デフォルトルートをホームルーター（FritzBox）に設定します。

   sudo ifconfig eth0 192.168.66.129/24 up 
   sudo route add default gw 192.168.66.2 eth0
   

3. wlan0に固定IPを設定します。

   sudo ifconfig wlan0 10.0.0.1/24 up   
   

4. 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
   

5. 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
   

6. APサービスを設定して実行します。

   cat hostapd.conf 
   interface=wlan0
   driver=nl80211
   ssid=fake
   channel=1
   
   sudo hostapd ./hostapd.conf  
   

7. Wiresharkを起動し、wlan0でリッスンします。

   ［画像: Pasted%20image%2020230112134354］

偽のWi-Fiを設定した後、ケトルをリセットし、アプリで再度初期設定を実行しました。今回は偽のWi-Fiを使用するように設定しました。すると、設定は成功し、アプリとケトルからのトラフィックを確認できました。しかし、アプリとケトル間の直接のトラフィックが見られなかったため、少しがっかりしました。トラフィックはすべてAzureクラウドへのものでした。ケトルは定期的にTLS 1.2で暗号化された接続を介してクラウドに接続し、状態をプッシュしたり、新しいコマンドを取得しようとしたりしているようです。

次に考えたのは、TLS接続をどのように切断して何が起こっているかを確認できるかということです。Man-in-the-Middle / アクセスポイントとして、ケトルに偽の証明書を提供し、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もありませんでした。 :(

ハードウェアで直接楽しいことができるかもしれませんね？ ;)
しかし、それはまた別の小さな冒険のために取っておきましょう...！