組み込みハッキングの理由
インターネットに接続されているか、完全なオペレーティング システムを実行しているデバイスは、今日の社会でますます普及しています。機関車用のデバイスからワイヤレス ライト スイッチまで、モノのインターネット (IoT) のトレンドは増加傾向にあり、今後も定着していくでしょう。これにより、私たちの生活がはるかに楽になる可能性があります。ただし、かつてのアナログ デバイスの知覚力が高まると、敵対者はそれらを標的にして悪用する可能性もあります。
これらのインターネットに接続されたデバイスが至る所にあるため、悪用する「モノ」が余剰になっています。このブログ投稿の主な目的は、個人が組み込みデバイスをリバース エンジニアリングする方法と、脆弱性を見つけようとするプロセスを一般化することです。
このデモンストレーションでは、Belkin WeMo LED Lighting Starter Set (http://www.belkin.com/us/p/P-F5Z0489/) の一部である WeMo Link を見ていきます。このデバイスの以前の反復で特定された脆弱性がありました。ただし、これらの脆弱性は Web サービス コンポーネントに重点を置いており、物理コンポーネントの組み込みセキュリティの分析に基づいていません。
ハードウェアを分析する手順
アナリストがデバイスを調査する際に実行する必要がある手順がいくつかあります。これらの手順の概要は次のとおりです。
- デバイスを研究する
- コンポーネントを特定する
- デバッグ ポートを特定する
- フラッシュを捨てる
- ファームウェアの抽出/分析
これらの手順は、分析対象のデバイスを理解するために不可欠であり、脆弱性を特定するために必要です。次のシナリオでは、前述の手順を順を追って説明し、それぞれの手順、私がたどったパス、および特定のシナリオを考慮して、他の潜在的なサブパスを説明します。
デバイスを研究する
このプロジェクトの範囲には、主に組み込み Linux をオペレーティング システムとして実行する IoT 組み込みハードウェア デバイスの調査が含まれていました。いくつかの IoT デバイスを検討した結果、モバイル アプリケーションで制御でき、ホーム オートメーションに使用できること、ワイヤレス コンポーネントを利用できること、およびインターネット経由で制御できることから、WeMo Link に決定しました。
WeMo 製品を使用すると、モバイル アプリケーションで電球をリモートで調光したり、オン/オフしたり、日の出や日没と自動的に同期させることで電球にちょっとしたインテリジェンスを追加したりできます。デバイスを駆動する主要コンポーネントは 2 つあります。WeMo リンクと WeMo 電球です。 WeMo Link は、WiFi 2.4GHz 無線コンポーネントと、同じ帯域で通信する ZigBee コンポーネントで構成されています。ソフトウェアに関しては、ユーザーは自分の Android または iOS デバイス用のモバイル アプリケーションをダウンロードして、最初に WeMo Link をセットアップします。これにより、WeMo 電球を制御できるようになります。
初期設定時に、WeMo Link は「WeMo.Bridge.XXX」の SSID をブロードキャストします。次に、ユーザーは自分のモバイル デバイスでこの AP (アクセス ポイント) に接続し、ユーザーのワイヤレス AP 資格情報を共有し、残りは WeMo が処理します。次に、WeMo はモバイル アプリケーションから送信されたコマンドを受け取り、それをユーザーのルーターと WeMo リンクに送信し、ZigBee 経由でコマンドを送信して、コマンドを適切な電球に実行します。ものすごく単純。
コンポーネントを特定する
この例では、操作の頭脳は WeMo Link コンポーネントのようです。確認するには、デバイスを分解する必要があります。蓋は、プラスチックのリップの下にマイナス ヘッドで力を加えると簡単に外れます。デバイスを適切に分解する方法を特定するには、プルタブの特定から、保証警告テープで覆われたネジの露出まで、いくつかの方法があります。この場合、デバイスにはわずかに突き出た蓋があり、4 つのタブで押さえられていました。プラスチック製の蓋の後ろには、メインボードと、変圧器、整流器などで構成される AC/DC コンバーターの 2 つの主要コンポーネントがありました。
メインボードを調べるとき、デバイスがどのように機能するかをよりよく理解するために、各コンポーネントに関連するデータシートを特定する必要があります。メインボード自体ですぐに見えるのは (シールドは後で削除します)、Winbound W9825G6KH-61 (https://www.winbond.com/resource-files/da00-w9825g6khc1.pdf) 32MB SDRAM とWinbound 25Q128FVSG (https://www.winbond.com/resource-files/w25q128fv_revhh1_100913_website1.pdf) 図に示すように、SPI (シリアル ペリフェラル インターフェイス) (これは後で重要になります) を介して通信する機能を備えた 16MB のシリアル NOR フラッシュ メモリ1. 後者のチップは、デバイスの電源がオフの間でも、より永続的なメモリをボードに保存するために使用されます。
基板の反対側にあるシールドの 2 つの金属片を取り外した後 (マイナス ドライバーで簡単にこじ開けることができます)、さらに 3 つの主要なコンポーネントが見つかります。
図 2 に示すように、最初のチップは SoC (System-on-a-Chip) Ralink RT5350F (https://cdn.sparkfun.com/datasheets/Wireless/WiFi/RT5350.pdf) で、MIPS が組み込まれています。ネットワーク デバイスに一般的に使用されるプロセッサであり、SPI 通信、360 MHz MIPS24KEc CPU コア、802.11n ワイヤレス通信などをサポートします。このコンポーネントは、デバイスの主な機能を駆動し、デバッグ インターフェイスを介して通信し、ZigBee コンポーネントとやり取りし、組み込みの Wi-Fi コンポーネントを介してルーターと通信するために使用されます。
図 3 に示すように、シールドされたもう一方のセクションには、Silicon Labs EM357 (https://www.silabs.com/Support%20Documents/TechnicalDocs/EM35x.pdf) というラベルの付いた ZigBee デバイス用の SoC が含まれており、ZigBee のすべてを処理します。 2.4 GHz の通信および処理能力 (32 ビット ARM Cortex M3 プロセッサ) は、WeMo 電球との間で情報を中継するために使用されます。同じセクションにある他のチップは、ZigBee 送信に使用される SkyWorks SKY65336 (http://www.skyworksinc.com/uploads/documents/200939H.pdf) 送信/受信フロントエンド モジュールです。前述の Silicon Labs EM357 ZigBee SoC を使用して、電球へのデータの実際の送信を実行します。
デバッグ ポートの特定
デバイスをデバッグ/操作する場合、最も一般的な 2 つの方法は、JTAG (Joint Test Action Group) と UART (Universal Asynchronous Receiver/Transmitter) で構成されます。 JTAG は、ターゲット デバイスとの通信に使用されるシリアル インターフェイスとして実装される専用のデバッグ ポートです。 UART は、任意の UART-to-USB ブリッジを介して USB 経由で簡単にブリッジできるシリアル通信の手段です。 UART 通信を検索すると、多くの場合、ボードの他の部分にルーティングされたトレースと共にグループ化された 3 ～ 4 個のピンが表示されます。これらのピンを識別するために、マルチメーターを使用できます。疑わしいピンのそれぞれを、正の端をパッドに、負の端をグランド (シールドなど) に接触させることで、電圧を監視し、ピンが何であるかを特定できます。ただし、この場合、WeMo の回路基板のシルク スクリーニングは、デバイスとのインターフェイスに使用されたパッドを正確にラベル付けするのに十分なほど使いやすかった.図 4 に示すように、便宜上、UART_RX、UART_TX、GND、および VCC とラベル付けされています。
ラベルが正確であることを確認するために、マルチメーターを使用して各パッドの接続をテストできます。デバイスの電源を入れて各ピンを監視することにより、UART_RX は一連の電圧全体で発振しました。これは、データがこのパッドを介してストリーミングされていることを示しています。これは、後でデバイスのコンソールを表示するために使用します。 UART_TX はデバイスにコマンドを送信するために使用され、識別が少し難しい場合があります。このパッドも 3.3V として表示されますが、その配置を考えると、これが VCC であるとは予想していませんでした。 VCC は他のパッドよりも太いトレースを持っている場合があり、これは電源に使用されていることを示しています。 GND パッドはマルチメータに 0 ボルトを供給し、これはそれが接地ピンであることを意味し、VCC は安定した 3.3 ボルトを供給し、それが電源パッドであることを意味します。フラッシュ ダンプから抽出したファームウェアを分析した後、これらの接続を後で使用します。
フラッシュを捨てる
この投稿の WeMo 分解セクションで前述したように、このデバイスのブートローダーとファームウェアを格納するために使用されるフラッシュ メモリを特定しました。これは、攻撃者が変更しようとするデバイスのコア コンポーネントです。このコンポーネントからメモリをダンプするには 2 つの方法がありますが、そのうちの 1 つを紹介します。これらの方法には次のようなものがあります: チップがまだボードにはんだ付けされている間にテスト クリップをチップ自体に接続し、バス パイレーツなどのツールを使用してフラッシュ メモリをダンプするか、チップのはんだを除去してからチップをプログラマーに配置して読み取ります。チップからメモリを取り外します。
可能な限りハードウェア指向にするために、チップのはんだ除去を行わずにバス パイレートを介して SPI フラッシュ メモリをダンプする方法を採用しました。私の分析が肉眼で発見されない (物理的な変更がない) ように、非侵襲的なアプローチを取りたかったのです。この方法のために、私は Dangerous Prototypes からバス パイレーツと SOIC8/SOP8 テスト クリップを購入しました (これらはさまざまな種類のチップ パッケージを表しており、輪郭の小さい集積回路と輪郭の小さいパッケージを意味します)。この特定のフラッシュ チップは、私の 8 ピン テスト クリップに完全に適合し、ボードからチップを取り外さずに接続するために使用されました。次に、図 5 に示すように、データシートとチップのピン配置に従いながら、バス パイレート ポートに対してチップを正しく配線しました。
チップからフラッシュ メモリをダンプするには、何らかの電源が必要です。この場合、図 6 と図 7 に示すように、バス パイレーツの 3.3v ラインを利用してチップに電力を供給します。
これに伴う問題は、電圧注入が発生し、ボード上の他のチップがウェイクアップする場合があることです。これは、他のチップがフラッシュ チップと通信し、フラッシュ ダンプ プロセスを中断することを意味します。これが、リワーク ステーションでチップのはんだを除去し、プログラマでチップの内容を読み取ることが一般的に推奨される理由です。ありがたいことに、私たちは幸運でしたが、そうではありませんでした。フラッシュ チップから 16777232 バイト (正確には 16MB) 相当のコンテンツ全体をダンプするために、flashrom というツールを使用しました。このツールは、図 8 に示すように、バス パイレート デバイスとうまく連携してフラッシュ メモリを完全に抽出します。
ファームウェアの抽出/分析
デバイスからフラッシュ ダンプを取得したので、図 9 に示すように、ツール binwalk を使用してフラッシュ ダンプ内のヘッダーを分析し、ダンプの構成をよりよく理解することができます。
一見したところ、デバイスは U-Boot をブートローダー (組み込み Linux デバイスで一般的) として使用し、SquashFS、JFFS2 などのいくつかのファイル システム タイプがあることがわかります。幸いなことに、binwalk には、フラッシュ ダンプ内のシグネチャから識別できる限りの情報を自動的に抽出し、デバイスの完全なファイル システムを提供する非常に優れた機能があります。ファイル システム抽出フラグ (binwalk -e) を指定して binwalk を実行すると、いくつかのファイル システムが表示されます。そのうちの 1 つを図 10 に示します。
このディレクトリ内で、ハードウェアのリバース エンジニアリングの帽子を脱ぎ、ソフトウェアのリバース エンジニアリングの帽子をかぶって、WeMo デバイス ファームウェアの署名に使用される暗号化キー、ハッシュされたルート パスワード、起動時に開始される興味深いサービスなどの興味深いアイテムを探し始めることができます。など
さらなるテスト
フラッシュ メモリをダンプした後に興味深いと思ったのは、すべてのメモリがチップから直接読み取れることと、ブートローダーが同じフラッシュ チップにバンドルされていることです。これは、フラッシュ チップには読み取り制御がなく、ブートローダーも同じ (保護されていない可能性がある) チップ上に存在するため、自分のデータをデバイスに書き込むことができる可能性があることを意味します。デバイスのシリアルを変更するなど、フラッシュ ダンプ バイナリ自体を操作するいくつかのテストを実行しました (これにより、ワイヤレス ブロードキャスト AP SSID が変更されました)。この最初のテストは、フラッシュ メモリの一部を正常に変更して、実際の環境でこれらの変更を表示できるかどうかを確認することでした。このケースでは、元の「WeMo」ではなく、ブロードキャスト AP SSID の名前を「WeMo.Bridge.HAK」に変更しました。 .Bridge.CBD」を、図 11 に示します。
元のコンテンツを完全に上書きして、新しいバイナリ ファイルをデバイスに書き込むことができたので、私の努力は励みになりました。これをさらに調べるには、フラッシュ ダンプを変更し、デバイスの起動コンソールを表示して結果を判断する必要がありました。これには、前述のようにデバイスの UART デバッグ パッドに接続し、コンソールの出力を表示する必要がありました。 UART_TX パッドを操作するために、絶縁テープで包んだワニ口クリップを使用して、パッドに接触し、UART_RX ピンに接続された UART to USB デバイスに接続されたワイヤを押さえました。デバイスはコンセントに差し込まれ、すでに電力が供給されていたので、送信パッドとアースに接続するだけで済みましたが、電力は必要ありませんでした。これは、デバイスを揚げたでしょう。図 12 に示すように、既にグランドとして機能しているシールドにグランド ワイヤを接続することにしました。これは、アース ワイヤを対応するアース パッドに接続するよりもはるかに簡単でした。
ソフトウェア側では、プログラム baudrate.py を使用して、UART 経由でデバイスのボー レート (伝送速度) を簡単に決定しました。デバイスの電源を入れ、文字化けしたテキストを何行か繰り返した後、57600 のボー レートに遭遇しました。これは、図 13 に示すように、このデバイスのブート プロセス全体を表示する読み取り可能なテキストを表示していました。
これで、フラッシュ ダンプで見つかった文字列と、デバイスの起動プロセス中に表示された文字列を比較できるようになりました。ブートローダーを変更する可能性があるという私の理論を確認するために、バイナリで見つかった文字列をコンソールに表示されたものと照合し、それらの文字列を変更して、ブートローダー U-Boot のこのセクションを書き直そうとしました。 16 進エディタを使用してバイナリ ファイルを変更し、フラッシュ ROM を使用してファイルをフラッシュ チップに消去/書き込みしている間に、ブートローダー プロセスで見つかった文字列を正常に変更しました。図 14 に示すように、ブートローダー ヘッダーを「U-Boot 20140225_MFG (2015 年 2 月 13 日 – 16:58:37)」から「Mandiant Bootloader (2016 年 5 月 18 日 – 15:38:25)」に変更しました。
また、図 15 に示すように、イメージ検証プロセスに関するさまざまなフィールド名を変更することもできました。これは、おそらくブートローダーがファームウェアの有効性をチェックする頃です。
ブートローダの一部を変更できる場合、イメージ検証プロセスに存在するチェックは無関係です。理論的には、上記の主張が正しければ、攻撃者は新しい悪意のあるブートローダーとファームウェアをデバイスに非侵襲的に書き換え、ユーザーのネットワーク上で信頼できるデバイスとして悪意のある行為を実行できる可能性があります。このようなシナリオは、この製品の再販業者がカスタム ブートローダーとファームウェアをこのデバイスに配置し、疑いを持たない顧客に製品を販売し、ユーザーのネットワークにコントロール ポイントを持つことで構成できます。これにより、攻撃者がネットワーク上のトラフィックを傍受したり、ネットワーク上のデータを取得したり、データを変更したりできるようになる可能性があります。
修復
次の推奨事項では、セキュリティの向上を実装するためにデバイスに大幅な変更を加える場合に関係するすべての変数が考慮されているわけではありません。これらの推奨事項は、前述のシナリオを修復しようとするときに考慮すべき事項です。
敵対者によるフラッシュ チップへの読み取り/書き込みなどを大幅に困難にするハードウェア ベースのアクションがいくつかあります。そのようなアクションの 1 つは、ハードウェア認証チップを実装することです。これには、復号化に必要なキーとともに暗号化メカニズムをボードに保存することが含まれ、敵対者がデバイス上のデータを複製または改ざんする能力を妨げます。これは、IoT デバイス メーカーにとって費用対効果の高い方法です。
2 番目のアクションは、保護されたストレージまたは SoC に格納することによってブートローダーを保護するか、ブート プロセス中に SoC が認証チップと通信することを要求することです。保護されていないフラッシュ チップにブートローダーを実装する際の問題は、ブート時にファームウェア イメージを解凍し、イメージを悪意のあるイメージで上書きするときに CRC チェックを無効にすることで操作できます。ブートローダをフラッシュ チップに保存する必要がある場合は、OTP (One-Time Programmable) メモリに含めることができ、サード パーティによるこの領域への書き込みを禁止します。
結論
一般に、セキュリティに注意を払う量は、デバイスの価値に比例することを覚えておくことが重要です。比較的安価なホーム オートメーション システムに厳格なセキュリティ機能を実装することは、最もセキュリティ意識の高い消費者以外には意味がない場合があります。とはいえ、攻撃者がバックドアを使って悪意のあるブートローダー/ファームウェアを簡単に実装できることを理解することは重要です。ワイヤレス電球のような単純なデバイスは、ホーム システムへのエントリ ポイントとして引き続き使用できます。
組み込みデバイスを分析するために前述の手順を実行することで、関連するチップ、UART デバッグ ポート、およびデバイスのブート プロセスに影響を与える、アクセス可能なフラッシュ チップに生データを読み書きする方法を特定することに成功しました。以前に定義した手順に従うと、ほとんどの組み込みデバイスをさらに調査して脆弱性を特定するのに役立ちます。
この研究を発表する意図をベルキンに通知すると、彼らは次の声明を出しました。
「Wemo は、潜在的なセキュリティ問題を特定し、接続されたデバイスを消費者にとって安全に保つために重要な役割を果たしている、FireEye やその他のホワイト ハット研究者の仕事に感謝しています。悪意のあるハッカーがより巧妙になるにつれて、安全性とセキュリティに対する深刻な脅威を軽減するために、私たちと他のスマート ホーム メーカーがこれらのグループと協力することが重要です。
「Wemo は、FireEye が最近のブログ投稿で公開した潜在的な脆弱性を認識していますが、当社のハードウェア生産に大きな変更を加えるほど深刻であるとは考えていません。この攻撃シナリオを容易にするために、ハッカーは Wemo Link デバイスに物理的にアクセスし、その回路を改ざんしてから、ハッキングされたデバイスを返却するか転売する必要がありますが、どちらもほとんどありません。この特定の脆弱性により、リモートまたはローカル ネットワークの脅威がユーザーに及ぶことはないため、これを防止する最善の方法は、公式の Wemo ディーラーから常に新しい未開封の商品を購入することであると考えています。」
参照: https://www.mandiant.com/resources/blog/embedded-hardwareha
Comments