Coway Airmega IconS空気清浄機がルート証明書を暗号化されていないHTTP経由でダウンロードするというセキュリティ上の不備を突くことで、ユーザーはデバイスの通信を傍受し、プライベートサーバーへとリダイレクトすることに成功しました。この操作により、デバイスを事実上「脱クラウド」化し、Cowayの公式クラウドインフラに依存することなく、ローカルのホームオートメーションシステムに統合することが可能になりました。

クラウド依存型IoTの問題点

Coway Airmega IconSのような多くの現代的なスマートホームデバイスは、リモート制御やアプリ連携のためにメーカーがホストするクラウドサービスに依存しています。便利ではありますが、この依存関係は単一障害点を生み出します。メーカーのサーバーがオフラインになったり、APIを変更したり、サービスを停止したりすると、デバイスの機能が失われてしまう可能性があるのです。

このプロジェクトの著者は、サーバーのメンテナンス、サードパーティ連携によるアカウントの停止、またはモバイルアプリのHTMLレイアウトの変更などにより、Cowayのクラウドサービスが機能しなくなった事例をいくつか指摘しました。長期的な信頼性を確保するために、制御ロジックをクラウドからローカルサーバーへ移行することが目標となりました。

ブートストラップリクエストの傍受

クラウドサービスをバイパスする際の主な技術的障壁はSSL証明書の使用であり、これによりデバイスが偽のサーバーに接続するのを防いでいます。しかし、Cowayのデバイスは初期セットアップ中にAmazon S3バケットから暗号化されていないHTTP経由でルート証明書をダウンロードすることが判明しました。

Raspberry Piとmitmproxyを使用して中間者(MitM)環境を構築することで、ユーザーはこの特定の要求を傍受しました。彼らはカスタムプラグインを使用して、公式の証明書を自身のラボで生成した証明書と入れ替え、デバイスにメーカーのインフラではなくユーザーのローカルインフラを信頼させることに成功しました。

AmazonRootCA1.pemのプレーンなHTTP GETリクエストを示すmitmwebインターフェース
ユーザーは、暗号化されていないHTTP経由でルート証明書をダウンロードしようとするデバイスの初期リクエストを傍受しました。scottjg.com

この画像は、デバイスがプレーンなHTTP経由でルート証明書を取得するという特定の脆弱性を説明しています。これにより中間者攻撃が可能になります。

AIの支援によるMQTTコマンドのマッピング

デバイスがローカル証明書を信頼するようになったことで、ユーザーは生のトラフィックを確認できるようになりました。初期のHTTPリクエストはMACアドレスや証明書トークンなどのメタデータを提供していましたが、実際の動作コマンドはポート8883上のMQTTプロトコルを介して送信されていました。

ユーザーはネットワークのファイアウォールルールを設定するという退屈なプロセスを進めるためにLLMを採用しました。公式アプリを操作しながら暗号化されたMQTTストリームを観察することで、ユーザーは特定のボタン操作をメッセージバス上の対応するメッセージにマッピングすることができ、最終的にデバイスの機能を完全にローカルで再現することが可能になりました。

ファンとAWS IoT間の生のMQTTストリームを示すmitmwebインターフェース
デバイスにローカル証明書を信頼させた後にキャプチャされた生のMQTTトラフィック。scottjg.com

この視覚資料は、ファン速度やその他の制御に関する特定のコマンドを特定するために使用された生のMQTTストリームを示しています。

アプリのボタン操作をMQTTコマンドにマッピングしたリストを示すチャットインターフェース
LLMを使用して、特定のアプリ操作を対応するMQTTメッセージにマッピングする。scottjg.com

ユーザーは、ボタン操作を基礎となるメッセージバスにマッピングするという複雑なプロセスを進めるためにLLMを活用しました。

制限事項とセキュリティへの影響

このプロジェクトは成功しましたが、重大なセキュリティ上の欠陥を浮き彫りにしました。HTTP経由でルート証明書を取得するデバイスは、本質的に傍受に対して脆弱です。この「ブートストラップ」の脆弱性は、攻撃者や趣味のユーザーがデバイスのトラフィックを任意の送信先にリダイレクトすることを可能にします。

著者は、この手法がクラウドからの独立性を提供する一方で、ネットワークルーティング、プロキシ、プロトコル分析を含む高度なセットアップが必要であることを指摘しています。さらに、ファンの速度に関する特定のAPIコールは初期のHTTPリクエストでは見えなかったため、完全な制御を実現するにはユーザーがMQTTストリームをさらに分析する必要がありました。

Hacker Newsの読者の反応

  • 技術的な指摘: あるコメント投稿者は、デバイスがプレーンなHTTP経由でルート証明書を安全に扱っていないことが中間者攻撃に対して脆弱であると指摘し、AIツールによってこのような欠陥のリバースエンジニアリングという退屈な作業が容易になっていることを示唆しました。 コメント ↗
  • 技術的な指摘: 別のユーザーは、標準的なメーカーの制限を回避して反応の良い環境を作るために、さまざまなハードウェアコンポーネントやセンサーをカスタムのホームオートメーションセットアップに統合した経験を共有しました。 コメント ↗
  • 技術的な指摘: あるコメント投稿者は、コントローラーをバイパスしてハードウェアを改造しようとすると、ネイティブのスマート機能を持つデバイスを購入するよりも、部品や労働のコストがかさんでしまう可能性があると警告しました。 コメント ↗

Hacker Newsのスレッドで出た意見の要約です。事実として検証されたものではありません。 議論の全文を読む ↗