2019 年、Mandiant のレッド チームは、Digi International のConnectPort X2eデバイス内に存在する一連の脆弱性を発見しました。これにより、特権ユーザーとしてのリモート コード実行が可能になります。具体的には、Mandiant の調査は、SolarCity (現在は Tesla が所有) のブランド変更された ConnectPort X2e デバイスに焦点を当てており、住宅用太陽光発電設備で使用されています。 Mandiant は、この種の作業を研究目的と、グローバル クライアントの専門的能力の両方で行っています。
Mandiant は、Digi International および SolarCity/Tesla と協力して、責任を持って調査結果を開示した結果、次の 2 つの CVE が発生しました。
技術的な詳細は、 Digi International の 3.2.30.6 ソフトウェア リリース、および FireEye の Vulnerability Disclosures GitHub プロジェクト ( FEYE-2020-0019およびFEYE-2020-0020 ) で確認できます。
この 2 部構成のブログ シリーズでは、分析の概要を説明し、ConnectPort X2e デバイスへの初期アクセスを取得するために使用される新しい手法を探り、発見された脆弱性の技術的な詳細を共有します。対象となるトピックには、物理デバイスの検査、インターフェイス プローブのデバッグ、チップオフ技術、ファームウェア分析、グリッチ攻撃、およびソフトウェアの悪用が含まれます。
パート 2 の続きに興味がある場合は、今すぐ読むことができます。
よくある質問
どのデバイスが影響を受けており、(潜在的に) 何台のデバイスが影響を受けていますか?
この投稿で説明されている脆弱性は、ConnectPort X2e デバイスと、SolarCity のブランド変更された亜種に影響を与えます。他のベンダーのデバイスも脆弱である可能性があります。実際に展開されている ConnectPort X2e デバイスの数は不明です。
問題はどのように対処されていますか？
Mandiant は Digi International および Tesla と独自に協力して脆弱性を修正しました。 Mandiant は、Digi International と Tesla の製品のセキュリティ向上への協力と献身に感謝します。
攻撃者はこれらの脆弱性をどのように悪用しますか?
脆弱な X2e デバイスへのローカル ネットワーク アクセス (イーサネット経由で個人のホーム ネットワークに接続するなど) を持つ攻撃者は、CVE-2020-9306 および CVE-2020-12878 を悪用して、デバイスへの特権アクセスを取得できます。
これらの脆弱性を発見したのは誰ですか?
ジェイク・バレッタ (@jake_valletta)、サム・サベタン (@samsabetan)
Mandiant の組込みデバイス アセスメントに関するビデオやデータシートなどの詳細については、こちらを参照してください。
テクニカル分析
デバイスの概要
詳細に入る前に、ConnectPort X2e デバイス (この投稿では X2e デバイスと呼ばれます) について概要を説明します。 X2e デバイスは、ZigBee デバイスに接続してデータを収集するプログラム可能なゲートウェイです。これは一般に、住宅用ソーラー インバーターからのエネルギー測定値を解釈して送信するためのスマート エネルギー ゲートウェイとして使用されます。多くの場合、ベンダーは X2e デバイスを購入し、顧客のソーラー インバーターによって生成された電力消費を読み取るように構成します。図 1 は、一般的な住宅用太陽光発電設備の概要を示し、X2e の役割を強調しています。
私たちの研究では、SolarCity (現在は Tesla) が住宅用太陽光発電設備からデータを取得するために使用している X2e デバイスに焦点を当てました。典型的なセットアップでは、顧客のホーム ネットワーク上のイーサネット ケーブルを介してインターネットに接続されるゲートウェイを SolarCity が顧客に提供します。図 2 は、テストした SolarCity ブランドの X2e デバイスの 1 つを示しています。
X2e デバイスを接続しなくても、イーサネット インターフェイスと ZigBee 無線の少なくとも 2 つの別個のインターフェイスを調査することがわかっています。 X2e とソーラー インバーターの間の ZigBee インターフェイスについては確認していません。そのインターフェイスについては、このシリーズの第 1 部または第 2 部で取り上げません。
初期分析と物理的検査
ネットワーク偵察
ネットワークの観点から X2e デバイスを評価することから調査を開始しました。 nmapを使用して、デバイスが SSH と HTTP/HTTPS の両方を公開していることを発見しました (図 3 参照)。
これらのサービスにリモートでアクセスしたところ、両方のサービスで認証が必要であることがわかりました。また、限定的なブルート フォースの試行も行いましたが、成功しませんでした。さらに、基盤となるサービスは、公開されているエクスプロイトに対して脆弱ではありませんでした。従うべきネットワークベースの手がかりは多くないため、分析をハードウェアの観点に移して、ローカル攻撃がデバイスへの初期アクセスを取得する可能性があるかどうかを判断しました。
物理ボード検査
ハードウェア分析を開始するために、デバイスからプラスチック ケースを取り外し、さまざまな集積回路 (IC) コンポーネントをマッピングし、潜在的なデバッグ インターフェイスを探しました。回路基板 (PCB とも呼ばれます) に存在するコンポーネントの一覧を作成することは、デバイスがどのように設計されたか、および今後何が期待できるかを理解するための重要なステップです。図 4 は、マッピングされたコンポーネントと、組み込みデバイスの一般的なデバッグ インターフェイスである一般的な 3 ピン UART (Universal Asynchronous Transmit/Receive) 接続に似たピンのクラスターを示しています。
X2e デバイスへのリモート接続がない場合、UART は魅力的なターゲットです。 UART は通常、SSH や Telnet などのサービスと同等の機能を提供し、システムの起動中に詳細な出力を監視するという追加の利点を提供します。ピンのクラスターが UART インターフェイスであるかどうかを判断するために、最初に 3 ピンのスルーホール ヘッダーを PCB にはんだ付けしました。マルチメータとデジタル ロジック アナライザSaleaeを使用した導通テストを組み合わせて使用すると、実際に UART インターフェイスを扱っていることが明らかになりました。図 5 は、ヘッダーに接続された 3 つのピン (グランド、TX、RX) を示しています。 3 本のワイヤのもう一方の端には、Linux 仮想マシンに接続されたFTDI シリアル TTL-232 – USB アダプターが接続されていました。
UART ピンと UART to USB アダプターを正しく識別することに加えて、インターフェースから読み取り/書き込みを行うためのソフトウェアと、ボーレートの知識も必要でした。ボー レートはさまざまですが、通常は 9600、14400、19200、38400、57600、115200 などの標準値に従います。 Python モジュールpySerialを使用して、USB アダプターに接続し、レートの 1 つが読み取り可能な ASCII 出力を生成するまで、標準のボー レートを試しました (ボー レートが正しくないと、通常、読み取り不能な出力が生成されます)、X2e が 115200 のボー レートを使用していると判断しました。
X2e を起動すると、図 6 に示すように、BootROM、ブートローダー (一般的な組み込みブートローダーである Das U-Boot 2009.8) からの出力、および UART 接続を介して送信された Linux カーネルからの出力に注目しました。
U-Boot の多くの構成では、(UART などのインターフェイスを使用して) 物理的に接続されたユーザーがブート プロセスを中断することができます。ただし、この構成では、その機能が明示的に無効になっています (図 7 参照)。
多くの場合、Linux オペレーティング システムに渡されるブート パラメータを操作して、シングル ユーザー モード (通常はリカバリ シェル) での起動やファイルシステムの読み取り/書き込みモードでのマウントなど、ロード方法を制御できるため、ブートローダーの中断は攻撃者にとって魅力的です。 . X2e の場合、図 8 に示すように、UART 接続はユーザー名とパスワード認証を必要とする Linux TTY にマップされました。
X2e に対して認証するための起動プロセスや資格情報を中断する機能がなければ、別の行き詰まりに直面しました。次に、分析を X2e の不揮発性ストレージに保存されているファームウェアの取得に移しました。
チップの取り外しとデータの抽出
このセクションでは、組み込みデバイスに搭載されている「フラッシュ メモリ」と呼ばれることが多い不揮発性メモリの基本と、チップからコンテンツを抽出するために使用されるプロセスについて説明します。前述のように、PCB 上のコンポーネントのインベントリを作成することは、重要な最初のステップです。図 9 は、PCB 上に存在する疑いのあるフラッシュ チップをデジタル顕微鏡で拡大したものです。
図 9 に見られる目に見えるマーキングは、フラッシュのメーカーとモデルを特定できるため重要であり、チップのデータシートを入手するのに役立ちます。私たちの場合、扱っていたNANDはSpansion S34ML01G1で、そのデータシートはここにあります.
NANDの概要
NAND チップからのファームウェアの取得について説明する前に、まず、組み込みデバイスが通常従うさまざまなシナリオを理解することが重要です。
NAND 対 NOR : これらの根本的に異なるテクノロジには、それぞれ独自の利点と欠点があります。 NAND は安価ですが、「不良ブロック」、または工場出荷時に破損している領域が発生する可能性が高いという問題があります。そのため、これを防止できるように、保護と考慮事項が存在する必要があります。また、NAND は消去と書き込みがはるかに高速であるため、ファイル システム、カーネル、およびリセットまたは変更が必要な可能性があるその他のコードの保存に最適です。 NOR は読み取り時間が大幅に高速ですが、データ アクセスの柔軟性が低く、消去と書き込みの速度が遅くなります。 NOR は通常、低レベルのブートローダー、ハードコードされたファームウェア BLOB、および頻繁に変更されることが予想されないその他の領域に使用されます。 X2e はNAND フラッシュを使用します。
Serial verses Parallel : データへのアクセス方法を指し、通常は視覚的に識別できます。多数のピンがある場合、フラッシュは並列である可能性があります。シリアル NOR チップはサイズが小さい場合があり、通常、機能するために必要なピンは 8 つ以下です。一般的なシリアル インターフェイスは、Serial Peripheral Interface (SPI) または Inter-Integrated Circuit (I2C) ですが、NAND の一般的なパラレル インターフェイスは Open NAND Flash Interface (ONFI2.0、ONFI3.0) です。 X2e はパラレル フラッシュです。
IC フォーム ファクター: 別の視覚的に識別可能な特性であるフォーム ファクター (または「パッケージ」) は、チップが PCB にどのように取り付けられているかを示します。ここにはオプションの長いリストがありますが、一般的な表面実装フラッシュ パッケージには、スモール アウトライン パッケージ (SOP)、シン アウトライン スモール パッケージ (TOSP)、またはボール グリッド アレイの変形 (*BGA) が含まれます。ここでの重要な違いは、SOP と TOSP はピンを露出させますが、BGA はピンをパッケージの下に隠します。 X2e はBGA63 で、63 ピン BGA パッケージとも呼ばれます。
マネージド フラッシュとアンマネージド フラッシュ: これは、NAND と NOR のセクションで言及した理由により、NAND により適しています。前述のように、NAND はデータの整合性を管理するための支援が必要です。管理されていない NAND では、IC はフラッシュのセクション (「スペア」領域と呼ばれることが多い) を他の誰かがデータを管理するために予約します。これは通常、カーネル ドライバーまたは外部 NAND コントローラーのいずれかとして実装されます。マネージド NAND とは、IC パッケージにコントローラーが含まれ、透過的にデータを管理することを意味します。これは、組み込み MMC (eMMC) やユニバーサル フラッシュ ストレージ (UFS) などの組み込みデバイスでは非常に一般的です。 X2e はアンマネージ フラッシュを使用し、PCB 上のメイン マイクロコントローラによって制御されます。
基本的なことは終わったので、PCB からチップを物理的に取り外す作業に進みました。
切りくず除去
物理的なチップの除去は破壊的なアプローチと考えられていますが、PCB やフラッシュ チップ自体に損傷を与えることなく確実に実行できます。 BGA パッケージを取り外す場合、最も一般的な 2 つの取り外し方法は、熱風または赤外線 (IR) です。熱風と赤外線の両方に商用ソリューションが存在しますが、より安価な選択肢として熱風除去があります。 X2e では温風を使用することにしました。
PCB とフラッシュへの損傷を最小限に抑えるために、PCB ヒーターまたはオーブンを使用して、PCB 全体をゆっくりとはんだの融点よりも低い温度にすることができます。これにより、熱風をフラッシュ IC に直接集中させる必要がある時間を短縮し、プロセス全体で PCB への熱放散を減らすことができます。
近くのチップが (空気圧による) 損傷または紛失するのを最小限に抑えるために使用できる最後のトリックの 1 つは、一般にカプトン テープと呼ばれる高耐熱テープの使用です。図 10 は、近くのコンポーネントを保護するためにカプトン テープで包まれた PCB を示しています。
図 11 は、X2e PCB を PCB ヒーターに挿入し、ホット エア ガンを IC 上に吊るしたセットアップ例を示しています。
熱風でICとその周辺を温めながら、フラッシュを軽く押してはんだが溶けたかどうかを確認しました。チップが浮いているように見えたら、すぐにチップを取り出し、約 30 秒間冷まします。図 12 は、PCB から取り外された IC フラッシュを示しています。BGA パッドにはんだがまだ残っています。
NAND をクラムシェル チップ リーダーに挿入する前に、残ったはんだをフラッシュから取り除く必要があります。これは、はんだごて、高品質のフラックス、およびはんだ除去ウィックを使用して行うことができます。除去したら、イソプロピル アルコールと歯ブラシを使用すると、残ったフラックスの残留物を除去し、チップをクリーニングするのに非常に効果的です。
次のセクションでは、多目的チップ プログラマを使用して NAND チップからデータを抽出します。
データ抽出
きれいなフラッシュ チップを手にしたので、生のコンテンツを読み取るためのオプションを探ることができます。商用の法医学的取得デバイスは存在しますが、eBay や AliExpress で簡単に検索すると、多数の汎用チップ リーダーが生成されます。そのようなデバイスの 1 つであるXGecu Proは、さまざまなアダプターとチップセットをサポートし、USB を使用して Windows マシンに接続します。また、XGecu Pro と連携するソフトウェアも付属しており、フラッシュの自動検出も可能です。 Spansion NAND を XGecu Pro に接続するために、クラムシェル BGA63 アダプターも購入しました。図 13 はクラムシェル リーダーに挿入された NAND を示し、図 14 は XGecu Pro デバイスに接続されたクラムシェル アダプターを示します。
XGecu Pro ソフトウェアを使用して、フラッシュの内容全体をバイナリ ファイルに読み込んで、さらに分析することができます。これらは商用ソリューションではないため、2 ～ 3 回の読み取りを実行してから抽出を比較して、コンテンツがエラーなしで読み取られたことを確認することをお勧めします。
ファームウェア分析
クリーニングと取り付け
新鮮な NAND ダンプが手元にあるので、次のステップは、関連するファームウェアのブロブ、構成、またはファイルシステムを解析することでした。このプロセスを開始するための頼りになるツールはbinwalkです。 binwalkは、ファイルシステム、ブートローダー、およびカーネルを検出する素晴らしい仕事をします。さらに、 binwalkはエントロピーを計算し (パックされたデータまたは暗号化されたデータを検出)、アセンブリ オペコードを識別できます。図 15 は、NAND ダンプに対してbinwalkを実行した場合の出力の一部を示しています。
出力からわかるように、 binwalkは、U-Boot uImage ヘッダー、Linux カーネル イメージ、および 12 以上の Journaling Flash File System バージョン 2 (JFFS2) ファイル システムであると思われるものを正常に識別しました。 JFFS2 は組み込みデバイスで使用される一般的なファイルシステムです。 Unsorted Block Image File System (UBIFS) と SquashFS も一般的です。
一見すると、出力は有望に見えます。ただし、NAND に多数の JFFS2 ファイルシステムが実際に存在する可能性はほとんどありません。何かが正しくないことを示すもう 1 つの兆候は、16 進数のオフセットです。これらは、クリーンで均一なオフセットではないようです。 binwalkによって識別される項目のオフセットが、2048 の倍数である NAND ページ オフセットと一致することは、はるかに一般的です。
ここで何が起こっているのかを理解するために、NAND の概要セクションで説明した管理されていない (または「生の」) NAND IC の特性を再検討する必要があります。要約すると、raw NAND は、通常、定義された「不良ブロック」マーカーおよびページ (またはサブページ) ごとのエラー修正コード ( ECC）。 ECC の基礎に深く入り込むことなく、ECC は上位レベルのプロセスがページ上のn個の不良ビットを検出し、 m個のビットを修正する機能を提供します。
ここでの目標は raw NAND でフォレンジックを実行することではないため、当面の目標は、NAND ダンプから ECC バイトまたはその他の非データ関連バイトを削除することです。 MCU は最終的に raw NAND を操作するシステムであるため、NXP iMX28 シリーズ MCU であった当社の MCU がどのように NAND を管理するかを理解することは、これを実行できるようにするために重要です。
幸いなことに、このプロセスはセキュリティ コミュニティによってすでに検討されており、生の NAND ダンプを操作して既存の無関係なデータを削除するためのiMX 解析ライブラリが存在します。図 16 は、 imx-nand-convertスクリプトの出力に対してbinwalkを再実行した結果を示しています。
今回は、ちょうど 0x880000のラウンド オフセットに JFFS2 ファイルシステムが 1 つだけ表示されます。 binwalkの抽出 ( -e ) 機能を使用して、U-Boot ブートローダー、Linux カーネル、および JFFS2 システムの解析済みバージョンを取得できるようになりました。
克服しなければならない最後のハードルは、抽出した JFFS2 ファイルシステムをマウントして、コンテンツを探索できるようにすることです。 Linux でこれを実行する最も簡単な方法は、 mtd 、 mtdblock 、およびnandsimカーネル モジュールを使用することです。 nandsimモジュールは、特定の NAND デバイスをシミュレートし、 mtdおよび JFFS2 サブシステムを使用して適切に解析および管理します。 nandsimモジュールに渡す必要がある重要な情報は ONFI チップ識別子です。これは、NAND データシートから取得するか、汎用リーダー (データ抽出で使用される XGecu Pro など) を使用して IC から ID を要求することによって取得できます。セクション）。サポートされている ID のリストもmtdメンテナーによって提供されています。パラメーターを正しく設定するには、ちょっとした運と魔法が必要で、独自のバージョンのnandsimモジュールをコンパイルする必要がある場合があります。そのプロセスについては、この投稿では説明しません。
図 17 は、適切な Spansion NAND をシミュレートし、JFFS2 ファイルシステムをMakefileターゲットの形式でマウントするために必要な手順を示しています。
make mount-jffs2を実行することで、JFFS2 ファイルシステムをすばやく準備してマウントし、他のファイルシステムと同じように内容を調べることができます。
ファイルシステムへのアクセス
この投稿の最後のセクションでは、JFFS2 ファイルシステムの分析について説明します。私たちの最終目標は、リモートで悪用可能なバグを取得して、特権コードの実行を許可することです。それを念頭に置いて、関心のあるいくつかの分野は、デーモン/プロセスの実行、システム起動ロジック、およびネットワークでリッスンするサービスの資格情報です。最初に行ったのは、 /etc/shadowファイルを調べて、 rootユーザーと他のシステム ユーザーのパスワード ハッシュがあるかどうかを確認することでした。このファイルを簡単に確認したところ、ルートユーザーのパスワード ハッシュがないことが判明しました。これは、パスワード認証を使用して認証できないことを示しています。図 18 に示すように、 addpdおよびpythonユーザー用に、他に 2 つのパスワード ハッシュが存在することに気付きました。
addpdユーザーのデフォルト パスワードは脆弱でしたが、リモート メソッドを使用して認証することはできませんでした。最終的に、内部の GPU ベースのサーバーを使用してpythonユーザーのハッシュをクラックすることはできませんでした。
さらに、システムの起動中または起動後に起動されるプロセスにも関心がありました。ディレクトリ/WEB/python/には、 _x2e.zipという名前の ZIP アーカイブが含まれていました。このアーカイブには、システムの起動時に読み込まれる 200 以上のコンパイル済み Python スクリプト (PYC ファイル) が含まれていました。逆コンパイラuncompyle2を使用して、これらのファイルをレビュー用に解凍しました。名前が際立っていたファイルの 1 つはpassword_manager.pycで、起動に成功したときにログイン パスワードをリセットするために使用されるファイルでした。このファイルには、 pythonシステム ユーザーにマッピングされた 5 つのハードコードされたプレーンテキストの資格情報が含まれていました。これらの資格情報は、図 19 に示すように、Web インターフェイスと SSH へのアクセスに使用できます。Mandiant は、バージョンと接続状態ごとに異なるパスワードが使用されていることを確認しました。 Mandiant はこれを SolarCity に報告し、CVE 番号 CVE-2020-9306 が割り当てられました。
正しいパスワードを使用して、実行中の X2e の Web ポートと SSH ポートに最終的に接続できましたが、残念ながら権限の低いPythonシステム ユーザーとしてしか接続できませんでした。これは素晴らしいスタートでしたが、特権ユーザーとして X2e をリモートで侵害するという最終目標を達成することはできませんでした。このブログ シリーズのパート 2 では、X2e をさらに侵害する別の手段を探ります。
結論
この 2 部構成のブログ シリーズの第 1 部では、X2e の概要、最初のネットワーク ベースの偵察、PCB 検査技術、物理デバッグ インターフェイスのプローブ、チップオフ技術、およびファームウェア分析について説明しました。これらの方法論を使用して、ハードコーディングされた資格情報により、X2e デバイスを非管理ユーザーとしてリモートで侵害することに成功しました (CVE-2020-9306)。パート 2 では、X2e に対するグリッチ攻撃の形での物理的攻撃を再調査し、U-Boot ブートローダーを再調査し、最後に特権ユーザーとして X2e デバイスをリモートで侵害する攻撃を示します。
続きを読むには、パート 2 を今すぐチェックしてください。
参照: https://www.mandiant.com/resources/blog/solarcity-exploitation-of-x2e-iot-device-part-one
Comments