IoTデバイスがあまり安全ではないということは既に知られていますが、それを裏付ける事例が実のところたくさんあります。インターネット接続を「必要とする」デバイスが増えるにつれて、WiFi対応トースターがハッキングされたり、クレジットカード番号がツイートで拡散される可能性は、もはや、冗談では済まなくなっています。
このことを念頭に置いて、私たちのラボで以前購入したものがあったので、コーヒーメーカー「Mr. Coffee」(WeMo_WW_2.00.11058.PVT-OWRT-Smartに対応)を調べてみました。（私たちのラボでコーヒーを飲む人はそれほど多くなかったので、それを分解することについてそれほど問題はありませんでした）。同僚のダグラス・マッキー（Douglas McKee）（@fulmetalpackets ）が以前に行った分析と、彼のWemoによるスマートプラグの脆弱性のブログを参考にしようと思います。この製品にはない似たような攻撃経路を発見し、異なる手法で調べた結果、別の脆弱性を発見しました。このブログでは、私が実施した方法論とプロセスを詳述します。
すべてのWemoデバイスには、Wemo Appと通信する2つの方法があります。リモートでインターネット経由か、ローカルで直接つなぐかです。リモート接続は、リモートアクセス設定が初期設定で有効になっている場合にのみ存在します。Wemoデバイスをリモートから制御できるようにするために、WemoはBelkinのサーバーを定期的に確認し更新を行います。これにより、Wemoはあなたのネットワーク上のポートを開く必要はなくなります。ただし、Wemoデバイスをローカルで制御しようとしている場合、またはリモートアクセス設定が無効になっている場合は、WemoアプリはWemoに直接接続されます。私の研究はすべて、リモートアクセス設定をオフにしたローカルデバイス通信に基づいています。
コーヒーメーカーがモバイルアプリケーションと通信する方法についての洞察を得るために、最初に「SSLキャプチャ」と呼ばれるアプリケーションを使用して私の携帯電話にローカルネットワークキャプチャを設定しました。SSLキャプチャによりユーザーはモバイルアプリケーションのトラフィックをキャプチャできます。今回、私はWemoアプリケーションを選択しました。キャプチャを実行しながら、Wemoアプリを使い、ネットワークトラフィックを生成するためのいくつかの標準コマンドを起動しました。こうすることで、コーヒーメーカーとWemoアプリケーションの間のコミュニケーションを見ることができました。このアプリのユニークな特徴の1つは、ユーザーが指定した時間にコーヒーメーカーでコーヒーを淹れるようスケジュールできることです。私はいくつかのスケジュールを作り、それらを保存しました。
私はスマートフォンのアプリとMr. Coffeeの間のネットワークトラフィックの分析を始めました。 2つのデバイス間のすべての送信はテキストで書かれていて、暗号化は使用されていません。また、コーヒーメーカーとモバイルアプリがUPNP（Universal Plug and Play）と呼ばれるプロトコルを介して通信していることもわかりました。これは「SOAP ACTIONS」と呼ばれる事前設定アクションを持ちます。 デバイスからのネットワークキャプチャを掘り下げていくと、「SetRules」というSOAPアクションが出てきました。これには、モバイルアプリケーションから設定した「抽出スケジュール」に関連するXMLコンテンツが含まれていました。
この時点で、Wemoモバイルアプリケーションが抽出スケジュールをどのように処理しているかを確認することができました。次に、コーヒーメーカーがスケジュールの何らかの検証を行ったかどうかを確認したかったので、モバイルアプリケーションに戻ってそれらをすべて無効にしました。そして、ネットワークキャプチャからデータとヘッダーをコピーし、Linux Curlコマンドを使用してパケットをコーヒーメーカーに送り返しました。リターンヘッダーのステータスは「200」で、HTTPでは「OK」を意味します。 これは、抽出スケジュールのソースについて検証されていないことを示しています。 さらにモバイルアプリケーションで検証すると、新たに予定されていた抽出が登場しました。
この時点で、Wemoモバイルアプリケーションを使用せずに、コーヒーメーカーの抽出スケジュールを変更することができました。スケジュールがWemoコーヒーメーカーにどのように保存されているかを知るために、物理的に分解して内部の電子機器を見ることにしました。分解すると、コーヒーメーカーの機能の制御を担うより大きなPCBに接続されたWemoモジュールがあり、それをコーヒーメーカーから取り出しました。これは、WemoインサイトデバイスにあるWemoモジュールとほとんど同じです。Wemoインサイトの悪用に関するダグのブログを拝借して、シリアルID、ファームウェアの抽出、およびルートパスワードの変更を再現しました。Wemoデバイスのシリアルポートを介してrootアクセスを取得した後、Wemoアプリケーションが基本的なLinux OSで起動する方法を調べました。最も一般的なLinuxのファイルとディレクトリに目を通すと、「crontab」ファイル（Linuxでコマンドの実行とスケジューリングに使用される）に奇妙なことがあることに気付きました。
開発者は簡単な方法を選択し、独自の抽出スケジュール機能を作成するのではなく、Linuxのcrontabファイルを使用してタスクをスケジュールしているようでした。 crontabのエントリーは、Wemoアプリケーション（coffee-3）を介して送信し、ルートとして実行した抽出スケジュールと同じものでした。これは特に興味深いものでした。再生したUPNPパケットから実行コマンドを追加することができれば、ネットワーク経由でルートとして自分のコマンドを実行することも潜在的には可能です。
ファームウェアがダンプされたことで、crontabで呼び出された「rtng_run_rule」実行可能ファイルを調べることにしました。rtng_run_ruleはLuaスクリプトです。Luaはスクリプト言語なので、テキストで書かれており、他のすべてのWemo実行ファイルのようにはコンパイルされていません。実行のためにテンプレートにパラメータを送るルールを確認するまで、実行の流れを追いました。この時点で、ルールに直接コマンドを挿入しようとしても無駄になることはわかっていたので、代わりに実行を行うテンプレートを変更することを検討しました。
「do」、「do_if」、および「do_unless」という送信された3つのテンプレートがありました。各テンプレートはLuaスクリプトで、base64でエンコードされています。これに基づくと、自分自身のコードを挿入することが簡単だということがわかりました。唯一残っているハードルは、テンプレートの一番上に含まれているMD5ハッシュでしょう。それも結局のところ、ほとんど障害ではありませんでした。
base-64のデコードされたLuaスクリプトとbase64のエンコードされたスクリプトのMD5ハッシュを別々に作成し、どちらかが送信されたハッシュと一致するかどうかを単純に確認しましたが、どちらもテンプレートで送信されたMD5と一致しませんでした。開発者がある種のHMACかテンプレートのハッシュに巧妙な方法を使用していると考えました。これだと、悪意のあるテンプレートをアップロードすることがはるかに困難になります。代わりに私が驚いたのは、 “begin-base64 644 <template name>”という文字列が先頭に追加され、 “====”という文字列が添えられた単なるbase64コードだったことです。
ついに私は自分の選んだテンプレートをアップロードすることができ、スケジュールされたルールで使用するために必要なWemoの検証手順をすべてパスすることができました。
私は「hack」と呼ばれる新しいテンプレートを追加し、そのテンプレート内にシェルスクリプトをダウンロードして実行するためのコードブロックを追加しました。
そのシェルコマンドの中で、WemoでMr. CoffeeのコーヒーメーカーにNetcatのクロスコンプライアント版をダウンロードするように指示し、「rc.local」へのエントリーも追加しました。 こうしておけば、コーヒーメーカーの電源を切ってすぐに入れ直せば、再起動後にはNetcatリバースシェルを介してデバイスへの永続的なアクセスを持っているでしょう。
このエクスプロイトの最後の段階は、過去の学習を踏まえて、シェルスクリプトを実行する新しい「ハック」テンプレートを使った抽出スケジュールを立てることでした。私は以前に再生することができたスケジュールを使い、「ハック」テンプレートが送信時から5分実行されるように修正しました。必要な時間値をエポックタイム形式に変換しなければなりませんでした。
今、私は腰を落ち着けて、コーヒーメーカー（私の指定された時間の遅れで）が私のコンピューターに接続し、シェルスクリプトをダウンロードし、それを実行するのを待っています。リバースシェルがあり、それが意図したとおり完璧に実行されたことを確認しました。
この脆弱性は、コーヒーメーカーがアクセスしているのと同じネットワークへのアクセスを要求します。ユーザーのパスワードの複雑さにもよりますが、WiFiのクラッキングは今日のコンピューティングパワーで達成するのは比較的簡単な作業です。たとえば、Wemo Insightスマートプラグ用のデモでやや複雑なWPA2パスワード（英数字10文字）を解読するための迅速で簡単な総当たり辞書攻撃を実証しました。ただし、特殊な文字を使用した少し複雑なパスワードでも、総当たり攻撃の困難性は指数関数的に膨らみます。私たちは、2018年11月16日に（Wemoを所有している）Belkinに連絡し、この問題を開示しました。彼らはこのレポートに反応しませんでしたが、最新のファームウェアアップデートによってこの問題が修正されたことを確認したのはうれしい驚きでした。普段のコミュニケーションはありませんが、私たちの研究の結果によってホームオートメーション機器が一段と安全になるのを確かめられるのは嬉しいものです。
この脆弱性は、あなたが何を求めているかを理解しさえすれば、すべてのエクスプロイトが過度に非常に複雑であるとか、そこから抜け出すためにとてつもない努力を必要とするなどというわけではないことを示しています。この脆弱性は、入力の管理や検証の欠如とあいまっていくつかの不適切なコーディングの決定が行われたがゆえに発生しています。このターゲットには機密データは含まれておらず、ローカルネットワークに限定されていますが、だからといって悪意のあるハッカーがこうしたIoTデバイスをターゲットにしていないということにはなりません。これらのデバイスは、セキュリティの観点から見過ごされがちで、ホームネットワークやビジネスネットワークに単純で監視されない足場を提供してしまい、格好のターゲットになるかもしれません。新しいIoTガジェットを購入するときには、「本当にインターネットに接続する必要があるかどうか」と自問することが消費者にとって非常に重要です。コーヒーメーカーについての判断は、みなさんにお任せします。
※本ページの内容は、2019年2月25日（CET）更新の以下のMcAfee Blogの内容です。
原文：Your Smart Coffee Maker is Brewing Up Trouble
著者：Sam Quinn