多くの最新のコンピューターシステム（PCのマザーボード、スマートフォン、ネットワーク機器など）は、特定のハードウェア向けに開発され、利用可能なハードウェアリソースの全範囲を使用でき、最高の特権を持つファームウェアの制御下で動作します。 ファームウェアの保護には特に注意を払う必要があります。そうしないと、システムのセキュリティにおける真のアキレス腱になります。

この問題については、少数の記事で取り上げますが、実際の例を使用して、ファームウェアセキュリティの弱いモデルと強いモデルを示します。



ちなみに、この記事は産業用ネットワークスイッチのセキュリティに関する私たちの研究に基づいています。これは、私がZeroNights 2015の実務者向け情報セキュリティ会議で発表したものです（レポート「産業用スイッチファームウェアの変更」、プレゼンテーションはこちらです ）。

はじめに

最初に、調査の目的である産業用スイッチについて説明しましょう。



最新のICSインフラストラクチャの中心はデータ媒体です。 ほとんどの場合、それは産業用イーサネットなどの産業用ネットワークです。 イーサネットテクノロジーファミリに基づいています。 このようなネットワークは、主にリアルタイムプロトコル（たとえば、Profinet、EtherCAT、Ethernet / IPなど）の使用において通常のネットワークと異なります。



産業用ネットワークの例[ ここからの写真]：







さまざまな種類のデバイス（PLC、HMIパネル、制御PC、フィールドデバイスなど）は、産業用タイプのネットワークスイッチ（スイッチ）を介してネットワークに接続されます。 従来のスイッチとは異なり、動作条件（拡張動作温度範囲、サージ保護、耐衝撃性、DINレールへの取り付け可能性など）に対する要求が少なく、産業用ネットワークプロトコルをサポートします。



したがって、産業用スイッチは、産業用ネットワークの構造において重要な要素です。 ネットワーク上の他のデバイスの侵害、PLCとSCADAの間、ゲートウェイとPLCの間の異なる接続内のデータの干渉と変更、データの偽造、 HMIおよびジャーナリングシステムなどに転送されます。 これはすべて、技術プロセスの実際の状態に対するオペレーターによる制御の喪失、その結果、停止または事故を伴う可能性があります。



これを防ぐには：

• まず、スイッチの領土の場所は、スイッチへの不正な物理アクセスの可能性を最小限に抑える必要があります。
• 次に、スイッチのソフトウェアおよびハードウェアアーキテクチャには、現代の脅威を考慮した情報セキュリティモデルが必要です。

後者について説明します。

研究の対象

研究のために、産業用ネットワーク機器の2つの最も一般的なメーカーから管理された産業用スイッチの1つのモデルを取りました。

• ヒルシュマンRS20
• Phoenix Contact FL SWITCH MM HS

これらのスイッチの動作は、COMポート（両方ともRS-232コネクタを使用）またはネットワークレベルで制御できます。





COMポートを介して作業する場合、コマンドを入力するためのコンソールを扱っています。







コンソールへのアクセスには、ユーザー名とパスワードが必要です。 それでも、認証画面の前には、ハードウェアとファームウェアに関する情報の表示、ファームウェアの更新など、いくつかのオプションが利用できます。





ネットワークを介してスイッチを操作する場合、Webインターフェースに（IPアドレスで）アクセスできます。







アクセスするには認証が必要です。





ネットワークレベルでスイッチを管理するためのもう1つのオプションは、認証もあるSNMP（Simple Network Management Protocol）です。 ただし、調査したスイッチでのSNMPサポートには、いくつかの欠点があります。

• デフォルトでは（これがほとんどのネットワークデバイスの最もお気に入りの構成です）、このプロトコルの最も安全でないバージョンが使用されます-SNMP v1。
• SNMP v1では、これらのデバイスのベンダーはデフォルトのユーザー名とパスワードを変更しないことを強くお勧めします。
• SNMP v1およびSNMP v2cのバージョンは暗号化を使用しません。つまり、プロトコルはMITM（中間者）などの攻撃に対して脆弱です。

まず、Hirschmann RS20スイッチの研究について説明し、次にこのスイッチと比較してPhoenix Contact FL SWITCH MM HSの機能の概要を説明します。

Hirschmann RS20産業用スイッチの研究

ファームウェア

まず、ファームウェアを入手し、実行しているプロセッサの種類を理解し、プログラマ/デバッガを接続する機能を評価する必要があります。 これを行うために、私たちは中を見て、見ました：

1. CPU Digi NET + ARM NS9360B-0-I155、32ビットARM9、内部メモリなし（したがって、ファームウェアは外部メモリに保存する必要があります）。
2. 16 MB RAM Micron MT48LC8M16A2 SDRAM;
3. 8 MB Intel 28F640JD3D75フラッシュメモリ（ほとんどの場合、ファームウェアはこちら）。
4. CPLD Marvell 88E6095F-LG01は、イーサネットスイッチの機能を実行し、内部構成メモリを備えています。

フラッシュメモリチップはBGAパッケージで作られています。 取り外すと、赤外線はんだ付けステーションなしではんだ付けすることは非常に困難になります。 したがって、このスイッチのファームウェア（バージョン8.0.07）は、 オープンなHirschmann ftpサーバーからマージされました。



ダウンロードしたアーカイブ内のファイルの1つはrsL2E.binバイナリ（約4 MB）です。これはファームウェアイメージです。 調べてみると、2つのモジュールで構成されていることがわかりました。 各モジュールには、ヘッダー（構造は同じ）と圧縮された本文があります。









最初のモジュールはzlib圧縮（RFC 1951）です。 実行可能コードが含まれています。 開梱時のモジュールの重量は約7 MBです。



2番目のモジュールはgzipアルゴリズム（RFC 1952）を使用して圧縮され、解凍後、デバイスのWebインターフェースの実装であるJAR（Java Archive）ファイルを取得するpack200アーカイブが含まれます。 開梱後、モジュールの重量は約3 MBです。 ところで、このファイルは、IPアドレスでスイッチにアクセスするとき（つまり、デバイスのWebインターフェースにアクセスしようとするとき）にホスト（制御PC）に転送され、ホスト上で実行されます。



開梱されたモジュールの総容量は10 MBで、デバイスのシステムボードのフラッシュメモリは8 MBであることがわかります。 したがって、ファームウェアイメージはパック形式で保存されると想定しました。 そのため、このファームウェアを展開して起動するブートローダーが必要です。 しかし、ブートローダーについては後で。





各モジュールヘッダーのサイズは256バイトです。 その構造はどこにも文書化されていないので、科学的な方法で分解する必要がありました。 注目を集めたフィールド：

• モジュール署名
• モジュールのタイプ。
• モジュールサイズ;
• モジュールチェックサム（CRC32）;
• ファイルの最後までのオフセット（eofオフセット）。
• モジュールのチェックサム（繰り返し）（CRC32）;
• ヘッダーチェックサム（CRC32）。

これに基づいて、ファームウェアの整合性の制御があると結論付けることができます。 ただし、通常は電子デジタル署名（デジタル署名）である認証はありません。



これらのファームウェアを偽造する機能を確認する必要があります。このため、ファームウェアイメージから両方のモジュールをすばやく抽出し、それらを変更した後、完成したイメージに戻すことができる小さなスクリプトを作成しました。









しかし、変更を加える前に、それについて考える必要があります。 そして向きを変える。





ファームウェアの内部にはRTOSコード（リアルタイムオペレーティングシステム）VxWorksがあり、さらにかなり古いバージョン5.4.2（1998年頃）があることが判明しました。 執筆時点では、最新バージョンは7です。



中国語の「インターネット」でVxWorks 5.5のソースを見つけました。これにより、さまざまなOS機能、libcプロシージャなどの識別が大幅に容易になりました。 VxWorksコードの分析タスクに直面している人なら誰でも、「VxWorksの画像には常にシンボルテーブルがあります！」と思うでしょう。 それはありますが、この形式ではほとんど役に立ちません：









VxWorksはモジュラー製品であり、モジュールの構成は顧客がソースを購入するときに決定します。 この場合、基本的なコンポーネントに加えて、Webサーバーモジュール（EmWeb）、SnmpOverHttp（はい、キャプチャされたトラフィックのHTTPリクエスト内のSNMPパケットを見ました）などを見ました。

ベンダーは間違いなく詰め物の世話をしました。



しかし、セキュリティについて-そうではありません。 ここで、線形アドレス空間、コード実行はメモリ内のどこからでも実行でき、スタックのオーバーフローなどに対する保護はありません。 バイナリ脆弱性の悪用に対する基本的な保護メカニズムは完全にありません。 たぶん、それらは必要ありませんか？ しかし、このバージョンのVxWorksには多くの登録された脆弱性があります。

1. CVE-2015-3963スプーフィングTCPセッション。
2. CVE-2010-2968ブルートフォース;
3. CVE-2010-2967アクセスを取得します。
4. CVE-2010-2966アクセスを取得します。
5. CVE-2010-2965 RCE;
6. CVE-2008-2476 DoS;
7. ...

DoS（サービス拒否）、RCE（リモートコード実行）、ブルートフォース機能、認証バイパスオプションなど、あらゆる好みに合わせて選択します。 リストは完全ではありません。



しかし、動揺しないでください！ 実際、ファームウェアの分析中に、非常に興味深いコードの断片が見つかりました。

• SNMP要求ハンドラー
• コンソールコマンドのハンドラー。
• フラッシュメモリの読み取りと書き換え。
• Marvell CPLD構成メモリの読み取りと上書き！

回転、今、あなたは掛けることができます。



これを行うには、導入するコードの場所を正しく選択する必要があります。スイッチの通常の機能を妨げないようにし、オンデマンドで呼び出すのが最適です。



明らかな選択は、コンソールコマンドハンドラの1つでした。 具体的には、ログアウトコマンドハンドラー。 ファームウェアの代わりに、指定されたアドレスで指定されたサイズのメモリを読み取り（挿入されたフラグメントの最後にある変数ですべてが設定されます）、COMポートで削除されたダンプを表示するコードを記述しました。









既製のイメージを作成し、それでスイッチを更新しました（COMポートとWebインターフェースの両方でファームウェアを更新できます）。 成功！ 実際、ログアウトの代わりにlogoutコマンドを入力した後、メモリダンプが出力されるようになりました。









したがって、ファームウェアを偽造する機能が確認されました。



しかし、攻撃者が実際に工業用サイトで使用されているスイッチにファームウェアを挿入する方法はありますか？





COMポートを介して（つまり、コンソールインターフェイスを介して）更新する可能性を考慮してください。 すでに述べたように、スイッチのファームウェアを更新するには、ユーザー名とパスワードを知る必要はありませんが、デバイスに物理的にアクセスする必要があります（RS-232に接続するため）。 デバイスが既に施設で使用されている場合、このオプションは信じられません。



ただし、工場からは、スイッチはすぐに工業施設にヒットしません。 顧客への配信スキームには、無料のボーナスとして、オリジナルではないファームウェアをスイッチにダウンロードできる中間組織が常に存在します。



別のオプション（これは既に配布ベクトルですが）：COMポートを介してスイッチに既に接続されている、以前に侵害された制御PCからスイッチファームウェアに感染することができます。





スイッチのファームウェアをリモートで変更することはより困難ですが、攻撃対象ははるかに広くなります。 スイッチのWebインターフェイスにアクセスするには認証が必要であることを思い出してください。 何ができますか？ 試すには：

• デフォルトのユーザー名とパスワードを入力します。
• 既知のパスワード制限に基づいて選択します。 幸いなことに、ブルートフォース攻撃に対する保護はありません。
• バイナリの脆弱性（既知または正直な発見）を悪用しますが、再び、バイナリの脆弱性の悪用に対する保護はありません。

ところで、リモート-これは、スイッチに接続されたPCからだけではありません。 また、フィールドデバイスの1つからも、時には保護されていない領域に配置されます。 したがって、必ず電話を切る必要があります！





結論は次のとおりです。 潜在的な攻撃者は、コードをスイッチのファームウェアに挿入すると、次のことが可能になります。

• スイッチCPUでコードを実行します（ハードウェアリソースの全範囲を使用）。
• ホスト（制御PC）またはスイッチのIPアドレスに誤ってアクセスする他のクライアントPCの側でコードを実行します。 もちろん、このコードはJavaマシンで実行されますが、ご存じのとおり、これはセキュリティの防波堤ではありません。

侵害されたスイッチは、通常のファームウェア更新手順によって「治癒」できることに注意してください。 主なものは、新しいイメージの信頼性を確信していることです。





いずれにせよ、これはすぐにデバイスを修正する可能性の問題につながり、ファームウェアに加えられた変更がすべての更新を「生き残り」ます。 そして、ブートローダーを思い出しました。これにはダンプがありませんでした。

ブートローダー

ブートローダーがRAMにトレースを残すことを期待して、（上記のコードフラグメントを使用して）別の場所にダンプしましたが、何も見つかりませんでした。 そして、スイッチのフラッシュメモリから取得して、フラッシュメモリを読み取るための以前に見つかった手順を引き出すことにしました。 そして再び成功。



そのため、フラッシュメモリの内容は3つの領域に分割できます。

1. ブートブロック、最初の80000hバイト。 これはブート領域です。ここにはブートローダーがあり、3つの部分で構成されています。
   
   
   • 開始コード;
   • メインコード（ハフマンアルゴリズムに従って圧縮）;
   • ヘッダー（構造は、前述のファームウェアモジュールのヘッダー構造と同じです）。
2. 最大の領域であるアプリケーションファームウェアは、予想どおり、パッケージ化された形式でここに保存されます。
3. ストレージ、サービス情報、構成、ログなどを保存するための領域

ブートローダーコードにより、スイッチブートプロセスの初期段階を再構築できました。



開始時に、フラッシュメモリの最初の4 KB（およびこれは開始コードのサイズです）がCPUのアドレス0のアドレス空間に投影されます。このアドレスから実行が開始されます。

ブートローダーの開始部分のタスクは、メモリカードを構成し、ブートローダーの主要部分をメモリに展開し、制御を転送することです。



メインブートローダーコードは次のようにする必要があります。

1. CPUハードウェアリソースを初期化します。
2. 割り込みモデルを構成します。
3. ファームウェアを開梱し、制御を転送します。

ブートローダーを変更する方法がすぐに思い浮かびます。 スイッチは、フラッシュメモリを操作するための標準手順を使用して、ブートブロックエリアを上書きするファームウェアの修正バージョンで更新されます。







将来、修正されたブートローダーは、起動するたびに、解凍されたファームウェアイメージを変更できるようになります。 このように侵害された「侵害された」スイッチは、もはやそれほど単純ではありません。









通常の手段を使用してスイッチを「硬化」させることは可能ですか？ これを行うには、ファームウェアとブートローダーの両方を元のファームウェアに更新する必要があります。



コンソールインターフェイスでブートローダーを更新する可能性はありませんが、ファームウェアの更新と同じ方法でブートブロック領域を更新するための手順がファームウェアコードに見つかりました。 ただし、これらの関数はどこでも呼び出されないため、これは文書化されていないデバッグ機能です。



しかし、スイッチのWebインターフェイスでは、ブートローダーを更新するための完全に標準的なオプションが見つかりました。









唯一の質問は更新方法ですか？ しかし、何も！



デバイスの多くのモデルのファームウェアイメージを含むアーカイブでは、Hirschmannはブートローダーイメージを適用しません。 そして、それらの間で調査されたモデル。



テクニカルサポートに連絡してブートローダーイメージを取得することもできません。 試してみたところ、ブートローダーイメージは配布されていないとの答えを得ました。 彼らから得ることができた唯一のことは、RMAフォームを使用して彼らにデバイスを送信する提案でした。 しかし、彼らはあらゆる方法でこれを行うことを思いとどまらせるでしょう。



したがって、潜在的な攻撃者は、ファームウェアの変更によりデバイスローダーで修正することができます。 そして、彼を定期的な手段でそこから追い出すことはほとんど不可能です。

さらに深く掘ることは可能ですか？

現時点では、この質問に対する回答はありませんが、アイデアは表明されます。



このデバイスには、何らかの方法で独自のファームウェアを備えた別の実行可能環境があることを思い出してください。 これは、不揮発性構成メモリを内蔵したマーベルCPLDタイプのFPGA（プログラマブルロジック集積回路）です。



それらのプログラムは、ロジック記述言語（VHDL、Verilog-最も一般的）で記述されています。 スイッチのファームウェアコードで、この構成メモリの読み取りと上書きのための関数を見つけたことを思い出してください。

産業用スイッチPhoenix Contact FL SWITCH MM HSの研究

このスイッチを探索するとき、同じ方法で、より高速になりました。 内部の興味深いもの：

1. CPU PMC RM5231A、32ビットMIPS IV、内部メモリなし。
2. RAM SDRAM Micron MT48LC8M16A2 16 MB、2個。
3. Intel不明モデルのフラッシュメモリ。
4. チップセットガリレオGT-64115。

このスイッチのファームウェアイメージをベンダーの公式Webサイトからダウンロードし、同様にその構造を分解しました。 ヘッダーとzlib圧縮（RFC 1951）本体があります：









ヘッダー構造の主なフィールドは次のとおりです。

• 署名
• ヘッダーチェックサム（ADLER32）
• 解凍されたボディチェックサム（ADLER32）;
• 開梱された本体のサイズ。
• パックボディチェックサム（ADLER32）;
• パッケージ化された本体サイズ。

ここにはファームウェアの認証もありません。これを実験的に検証しました。









VxWorksもここにありますが、わずかに新しいバージョン6.1にも同じ問題があります。バイナリの脆弱性の悪用に対する保護メカニズムの欠如と登録済みのCVEの束です。



同じ方法でファームウェアを更新できます。

• COMポート経由で、認証も必要ありません
• Webインターフェース経由。 アクセスするには、ログインとパスワードを入力する必要はありませんが、設定を変更するとき（またはファームウェアを更新するとき）、パスワードを知っている必要があります。

パスワードといえば。 ドキュメントによると、現在のパスワードが失われた場合（まあ、またはハッカーの場合は決して取得されない）に備えて、エンジニアリングパスワードがあります。 これを行うには、スイッチのMACアドレスとシリアル番号を提供してテクニカルサポートに連絡する必要があります。

これは、これらの数値をエンジニアリングパスワードに変換するアルゴリズムがあることを示唆しています。



このスイッチには、上書き可能なブートローダーもあります。 そして、それは実験的に証明されています。 ブートローダーを更新するための通常の機能はまったくありません。

おわりに

この調査の結果、産業用スイッチのアーキテクチャに次の欠陥が特定されました。

1. ファームウェアを不正に更新する機能（一部の通常の手順では、認証は不要です）。
2. デバイスのファームウェアイメージを偽造する機能（ブートローダー、CPLDファームウェアなど） コード認証の欠如;
3. バイナリ脆弱性の悪用によるメカニズムはありません。これにより、スイッチでのリモートコード実行の可能性がさらに広がります。

調査の過程で、スイッチファームウェアを偽造する機能と、ブートローダーへの変更を固定する機能を示しました。





要するに、素晴らしい。



正しい、ファームウェアのセキュリティモデルの実際の例は、次の記事で検討します。