このブログは、広く使用されているアクセス制御システムの脆弱性発見に焦点を当てたマルチパート シリーズの 第3回目です。ターゲットの取得からエクスプロイトに至るプロセスの調査過程について紹介する内容です。ベンダーと製品を選択から始め、ハードウェアハッキングの技術まで掘り下げていきます。対象のデバイスは、HID Mercuryのアクセス コントロール パネル LNL-4420です。このシリーズでは、発見された最も影響力のある脆弱性に焦点を当てて、取り上げます。このシリーズの第1回目と第2回目も公開しています。
重要インフラは、グローバルなインフラ全体の基幹です。国家主体の攻撃者にとって紛れもなく魅力的なターゲット領域であり、時として許しがたいほど脆弱です。ここ数年だけを振り返っても、多くの事例がそれを証明しています。パイプライン、エネルギー網、水処理システム、通信事業者などに対するサイバー攻撃が大きく報道され、大胆不敵な攻撃者が世界中で増えていることが強調されています。
アクセス制御システムはデジタルと物理の領域を隔てる数少ない障壁の1つですが、機密性の高い資産の保護にあたっては過信されがちで、独特な攻撃経路になっています。産業用制御システム（ICS）やビルディングオートメーションシステム（BAS）に通じるこの攻撃経路を、研究者も敵対者も見落としてきました。このような隙があったので、このエリアの調査に取り組むことを決めました。
サードパーティベンダーによる OnGuard のインストール
完全に機能するエクスプロイトチェーンにより、ハードウェアとソフトウェアのハッキングプロジェクトにおける古典的な岐路にたどり着きます。この場合、ソフトウェアの一部は、通常の (正当な) 手段では購入またはダウンロードできず、完全な監査および通常のシステム操作の要件です。研究プロジェクトの早い段階では、ターゲットを調査するための操作の順序がコストによって決定される、反復的なアプローチに従うのが一般的です。eBayで信頼できる中古品を探しハードウェアを調達し監査することで、比較的安価でスムーズに調査が進められます。十分な動機 (脆弱性の発見など) が得られるまで、実際の使用状況を反映するために完全に製品化されたハードウェアとソフトウェアの組み合わせを購入するのは、ややリスクが高くなります。
この時点で唯一欠けていたのは、OnGuard と呼ばれる LenelS2 コントローラーの管理ソフトウェアでした。このソフトウェアがなければ、ネットワーク経由でデバイスを管理するために送信されるコマンドを発行して理解することはできません。余談ですが、チームが行った以前の Delta eBMGR 調査に関するブログを読んでいただくとわかるのですが、この問題を克服するために同様のアプローチを採用しました。そのときと同じように、私たちは LenelS2 について地元のサードパーティの請負業者に連絡を取ることにしました。これは常に、最終的に「ハッキングできる機能するデモシステムを構築する必要がある」という会話を作り上げるための戦略的アプローチです。Convergintのチームに連絡を試みたところ、初めはボイスメールや電子メールでの連絡が取れず、なかなか連絡が取れなかったのですが、私たちは最終的に、非常に親切で、非常に反応がよく、丁寧な対応のセールスマネージャーに連絡を取ることができました。そして、当社からは、「テスト」調査を行うために、小さなフォーム ファクターで機能するデモシステムが必要であるといったことを伝えました。少し曖昧な依頼であったにもかかわらず、数週間後に、チームから最初の「Hack-in-a Box」が届きました。（図1）
図1. ボックス デモ システムでの LenelS2 ハック
正規の環境に接続されていなくても、完全に機能するシステムを手に入れることで、2 つのことがわかりました。まず、通常のインストールに従って配線されたシステムに対するエクスプロイトを確認できました。接続しようとしたときのクリック音とリレー ライトの LED を確認できました。第 2 に、さらに重要なことは、ライセンスを受けたインストーラーが、OnGuard ソフトウェアの完全に機能する有効なライセンスを提供してくれたことです。OnGuard ソフトウェアをインストールするには、その使用方法を学ぶ必要がありましたが、幸運なことに、ベンダーのインストーラーが、ソフトウェアの基本機能のいくつかに関する簡単なチュートリアルを提供してくれ、十分にセットアップできるようにしてくれました。これは主に、ユーザーのプロビジョニング、カードの開始、およびスケジュールの設定にフォーカスしていました。これらの情報はすべて知っておくとよい情報ではありましたが、私たちの調査には直接影響する情報ではありませんでした。
ただし、2つの点で注意が必要でした。1つ目は「Open Door(s)」ボタンで、2つ目は「Download Firmware」ボタンです (図 2)。
図2. ドアを開けてファームウェアを更新するためのボタン
前に述べたように、脆弱性を調査およびスキャンしていたボードは eBay で買収されたため、ファームウェアがどの程度古いかを判断する方法も、自分で更新する方法もありませんでした。通常、新しいターゲットの調査を開始するときに最初に行うことは、ファームウェアを最新バージョンに更新することです。これにより、発見された脆弱性がゼロデイである可能性が高くなります。この管理ソフトウェアにより、プロジェクトの開始時には欠けていた、最終的にファームウェアを更新する機能が提供されました。ファームウェアをアップデートすることで、古いファームウェアで見つかったいくつかの脆弱性が修正されました。これについては、シリーズの第2回目のソフトウェア ハッキング セクションで取り上げました。
OnGuard ソフトウェアから得られるもう 1 つの重要なポイントは、「メイン アラーム モニター」ウィンドウです。これは、すべてのコントローラーのステータスが記録される場所です (図 3)。
図3. 各トランザクションは OnGuard ソフトウェアに記録される
ドアで発生したことはすべてここに記録されます。LNL-4420 には複数のセンサーが取り付けられており、キーカードなしでドアが開かれたかどうか (つまり「強制的に開いた」)、またはドアがロックされた後に再び閉じられなかったかどうか (つまり「開いたまま」) を監視できます。これは、ドアを通って入るすべての人 (バッジ) と、拒否されたエントリーまたは無効なカード形式を追跡するウィンドウでもあります。後ほど、このロギングをバイパスしてドアを完全に制御した方法を示します。
デバイスを制御
エクスプロイト チェーンを利用してリモートで LNL-4420 デバイスのルート アクセスを取得すると、スーパーユーザー権限でデバイスにアクセスできるようになりました。このレベルのアクセス許可を持つことで、ソフトウェア自体でさえ知らない変更が可能になります。このタイプの制御は、多くの場合、マルウェアに関連付けられています。私たちの研究は可能な限り現実的なものにすることを目指しているため、「できること」を示すだけでなく、実際にそれを実行することが不可欠です。そのため、コントローラーへのルート アクセス権を取得するだけにとどまりませんでした。代わりに、このコントロール パネルに接続されているドアとセンサーを完全に制御できる「マルウェア」の作成に着手しました。
LNL-4420 に接続された各ドアは、リレーによって制御されます。リレーは、電圧が印加されているときに開いたり、電圧が印加されていないときに閉じたりする電気スイッチです。コントロール パネルに接続されているすべてのドアは、ドアを物理的にロック解除またはロックするリレーによって操作されます。リレーは、ドアをリモートでロックまたはロック解除する方法を作成したかったため、マルウェアに組み込む主なターゲットでした。
私たちは、どのバイナリがリレー機能を制御しているのかを突き止めることに着手しました。OnGuard ソフトウェアに関するトレーニングから、ソフトウェア インターフェイスから直接、リモートでロック解除コマンドを発行できることがわかっています。そうすることで、発行されたコマンドに関連するメッセージがコンソールに表示されることを期待していました。これは成功しませんでした。ロック解除コマンドとロック コマンドの発行、およびキーカードによるドアの開放は、コンソールに記録されませんでした。
次のステップは、3 つの主要なバイナリのどれがリレーの制御を処理しているかを絞り込むことでした。候補は「mpl_icd_ep4502」、「mpl_mbg_ep4502」、「mpl_sio_ep4502」でした。不必要なオーバーヘッドを回避するために、最初にどのバイナリがデフォルトで実行されているかを調査することにしました (図 4)。
図4. デフォルトで実行されるバイナリの決定
「mpl_mbg_ep4502」バイナリはデフォルトでは実行されていなかったため、起動時に実行されていた残りの 2 つのバイナリに焦点を移しました。「mpl_sio_ep4502」の命名規則に関する簡単な観察から、「sio」が「シリアル入力/出力」を意味する可能性があると推測したため、この候補から始めることにしました。これは、Linux ベースのシステムが、GPIO ピン (汎用入出力) を備えたリレーなどの単純なオン/オフ デバイスと対話するためです。これらのデバイスは、カーネル モジュールと対話するために特別なファイルが使用される「 sysfs 」を介してマップされます。図 5 に、Linux での「sysfs」ファイルの使用例を示します。
図5. Linux で GPIO ピンを使用する例
このシナリオでは、sysfs ファイルはピン「189」を制御します。これは、LNL-4420 が LED を制御する方法です。エクスポートされた GPIO ピンに 1 または 0 をエコーし、デバイスの LED の動作が異なることを確認できました。これにより、ドアリレーもこの方法で制御できるという推論の飛躍を遂げました。GPIO (図 6) に関連するキーワードを検索しても、LED セットアップに関する結果はごくわずかでした (図 7)。
図6. 「GPIO」の検索結果
図7.「GPIO」関数へのすべての xref は、LED 関数によって使用された
トレース機能と共有メモリの分析を徹底的に調べた後、「リレー」という単語を検索しただけで、当然のことながら、探していた結果が得られました (図 8)。振り返ってみると、これはおそらく最初に検索した文字列の 1 つだったはずです。
図8. 「リレー」に関する関数を検索する
これは、物事がより理にかなっており、リレーはカスタムカーネルドライバーによって制御されていました. カーネル ドライバーによって処理されるため、リレーの GPIO ピンを参照するコードが表示されなかった理由が説明されています。コントローラーがドアのロックを解除するには、ユーザーランド アプリケーションが IOCTL システム コールを発行する必要があり、カーネル ドライバーはリレーをトリガーして応答します (図 9)。ここで、relay1on() 内の ioctl 呼び出しは 3 つのパラメーターを示します。これらは、GPIO ピンのファイル記述子、要求コード (この場合は 0xf003)、および制御するリレーを定義するゼロのインデックス番号を表します。ロック解除コマンドを発行するのに必要なのはこれだけです。
図9. IOCTL 呼び出しでリレー 1 をオンにする
これが「ドア ロック」を処理するコードであることを確認するために、relay1on 関数にブレークポイントを配置し、OnGuard ソフトウェアから手動で「ロック解除」コマンドを発行しました。仮説を確認すると、リレーは IOCTL 呼び出しを通過するまでトリガーされませんでした。ドアを開けるための IOCTL コマンドを使用して、relay1on 関数を模倣する小さな C アプリケーションを作成しました (図 10)。
図10. ドアを 10 秒間開くコード
単純な Cプログラムで IOCTL 呼び出しを呼び出すことにより、通常の API とアプリケーション コントロールを Lenel バイナリからバイパスしました。ただし、これにより、ドアを閉めたままにするように設計された他のシステム プロセスが妨害されました。たとえば、ドアを開くために IOCTL コマンドを発行すると、リレーが開き、ほぼ瞬時に再び閉じます。この問題に対する私たちの強引な解決策は、IOCTL 呼び出しを while ループでラップし、ミリ秒ごとに実行することでした。これにより、「オープン」機能が頻繁にトリガーされ、リレーを閉じようとする他の競合プロセスが優先されなくなります。
リレーに直接アクセスすることで、最後のステップは、有効なバッジがスキャンされた場合でもドアをロックしたままにできるかどうかを判断することでした。「mpl_sio_ep4502」バイナリ内には、「relay1off」という名前の関数もありました。ドアを「ロック」する IOCTL パラメータを提供するようにコードを変更することで、ユーザーをロックアウトまたはロックインすることができました。私たちは、人を建物に閉じ込める攻撃の妥当性を社内で検討しました。コードによるすべての外部ドアには、ロックシステムをバイパスする緊急出口が必要です。これは「フェイルセーフ」オプションです。内部ドアは同じ基準に保持されておらず、多くの場合、物理的なキーを持っていない限り、バッジでドアのロックを解除することしかできません。 これは、ドアのロック状態を維持することで、攻撃者に有利になる可能性があります。
全てを一緒に
プロセス全体をワンクリックの悪いある操作にまとめるには、2 つの脆弱性を連鎖させる必要がありました。1 つ目は認証されていないコマンド インジェクションで、2 つ目は強制的な再起動です。再起動時にコマンド インジェクションが実行されると、コマンド アンド コントロール サーバーに到達し、追加のペイロードをダウンロードしました。これには、リバース シェルを開始するツールと、ドア リレーを制御するために作成した「マルウェア」が含まれていました。次に、リバース シェルに接続し、IOCTL エクスプロイト コードを実行して、ネットワークを介してリモートでドアのロックを解除しました。最後に、IOCTL 呼び出しを介してドアのロックを解除した後にドアを開くときに渡される、避けられない「強制的に開く」メッセージをバイパスする方法を見つけ出す必要がありました。このメッセージは、ドアが開いているか閉じているかを判断できる位置センサーがドアにあるために発生します。ドアのロックを解除する正当な方法を迂回したため、ソフトウェアは基本的にドアを蹴り倒しただけだと考えます。ドアセンサーがどこから読み取られているかを把握しようとしているときに、別の「エレガントな」ソリューションを思いつきました。OnGuard サーバーと通信するプロセスを一時停止し、IOCTL 呼び出しでドアのロックを解除し、REX (終了要求) をトリガーし、最後にプロセスを再開すると、OnGuard サーバーにメッセージが伝達されないことがわかりました。この「ハッキング」は、ログに記録されず、「強制開放」ステータスをトリガーしないプロセスを通じて誰かが建物を去ることをシミュレートします。これにより、法医学的証拠がまったくなくても、自由に出入りできました。別の「エレガントな」ソリューションを思いつきました。OnGuard サーバーと通信するプロセスを一時停止し、IOCTL 呼び出しでドアのロックを解除し、REX (終了要求) をトリガーし、最後にプロセスを再開すると、OnGuard サーバーにメッセージが伝達されないことがわかりました。この「ハッキング」は、ログに記録されず、「強制開放」ステータスをトリガーしないプロセスを通じて誰かが建物を去ることをシミュレートします。これにより、法医学的証拠がまったくなくても、自由に出入りできました。別の「エレガントな」ソリューションを思いつきました。OnGuard サーバーと通信するプロセスを一時停止し、IOCTL 呼び出しでドアのロックを解除し、REX (終了要求) をトリガーし、最後にプロセスを再開すると、OnGuard サーバーにメッセージが伝達されないことがわかりました。この「ハッキング」は、ログに記録されず、「強制開放」ステータスをトリガーしないプロセスを通じて誰かが建物を去ることをシミュレートします。これにより、法医学的証拠がまったくなくても、自由に出入りできました。この「ハッキング」は、ログに記録されず、「強制開放」ステータスをトリガーしないプロセスを通じて誰かが建物を去ることをシミュレートします。これにより、法医学的証拠がまったくなくても、自由に出入りできました。この「ハッキング」は、ログに記録されず、「強制開放」ステータスをトリガーしないプロセスを通じて誰かが建物を去ることをシミュレートします。これにより、法医学的証拠がまったくなくても、自由に出入りできました。
最終的なデモ システムの構築
このブログ シリーズから他に何も学んでいない場合は、少なくとも、私たちが何かをするときは全力で取り組んでいることに気付くでしょう。正規のインストーラーによって配線されています。幸いなことに、Convergint の私たちの友人は電話をかけるだけでした。今回の会話ははるかに迅速でした。営業担当者が率先して地元のドア & ロック会社に電話し、数時間以内にカスタムビルドアウトの見積もりを取りました。彼らは、モビリティ プラットフォーム上で 7 フィートのドアを製造し、ドアの上に既存のハードウェア パネルを統合することができました。カードリーダーと退出要求を追加することで、以前に行った建物の設置と同じように配線された機能的なシステムがすぐにできました.
図11. デモ システムを構築するインストーラ
図12. 最終的なリモート デモ テスト用にセットアップされた ATR ラボ
数百マイル離れたサムの家からの最終テストは、私たちが探していた見返りでした! ドアがカチッと開いたので、ハッキングと呼ぶことにしました。私たちが撮影した最終的なデモ ビデオは、リアルタイムでエンド ツー エンドで行われ、ギミックはなく (恐ろしい演技を除いて)、簡潔にするために時間編集のみが行われました。
デモ
学びと教訓
このプロジェクトは、ツール、技術、およびターゲット システムに関する発見において、私たち二人にとって大きな成長をもたらしました。また、将来のためのいくつかの教訓も教えてくれました。これをやり直すことができたなら、最初に「本番」の OnGuard 制御システムを構築するチャンスをつかんだと思います。間接的な作業がいくらか減り、より完全な全体像が得られたはずです。同時に、ベンダーに知られていたにも関わらず、いくつかの追加の CVE が提出される結果となったので、害も反則もありません。2 つ目は、物理システムがエミュレートされたシステムとどれほど異なるかを認識したことです。エミュレートされた元の環境で動作させるのは非常に簡単でしたが、完全な OS を備えた物理デバイスに戻すと、悪用のハードルがはるかに高くなりました。最後のポイントは、プロジェクト全体をまとめたものです。ICS と BAS の業界を代表する方法で。多くの脆弱性が比較的単純であることに非常に驚きました。政府施設での使用が広くテストされ認定されている最新のシステムでは、基本的なセキュリティの観点から、はるかに高いハードルを期待していました。私たちが発見した問題の多くは、開発手法の悪さだけではなく、構成、テスト、およびネットワーク セキュリティの概念の理解における根本的な誤りを表しています。残念ながら、これは重要なインフラストラクチャの標準であり続けています。このシリーズが、ベンダーがセキュリティに再投資する動機となることを願っています。研究コミュニティに積極的に関与し、サードパーティの研究と責任ある情報開示を後援して受け入れ、顧客や一般大衆とのコミュニケーションを積極的に行います。多くの脆弱性が比較的単純であることに非常に驚きました。政府施設での使用が広くテストされ認定されている最新のシステムでは、基本的なセキュリティの観点から、はるかに高いハードルを期待していました。私たちが発見した問題の多くは、開発手法の悪さだけではなく、構成、テスト、およびネットワーク セキュリティの概念の理解における根本的な誤りを表しています。残念ながら、これは重要なインフラストラクチャの標準であり続けています。このシリーズが、ベンダーがセキュリティに再投資する動機となることを願っています。研究コミュニティに積極的に関与し、サードパーティの研究と責任ある情報開示を後援して受け入れ、顧客や一般大衆とのコミュニケーションを積極的に行います。多くの脆弱性が比較的単純であることに非常に驚きました。政府施設での使用が広くテストされ認定されている最新のシステムでは、基本的なセキュリティの観点から、はるかに高いハードルを期待していました。私たちが発見した問題の多くは、開発手法の悪さだけではなく、構成、テスト、およびネットワーク セキュリティの概念の理解における根本的な誤りを表しています。残念ながら、これは重要なインフラストラクチャの標準であり続けています。このシリーズが、ベンダーがセキュリティに再投資する動機となることを願っています。研究コミュニティに積極的に関与し、サードパーティの研究と責任ある情報開示を後援して受け入れ、顧客や一般大衆とのコミュニケーションを積極的に行います。政府施設での使用が広くテストされ、認定されているため、基本的なセキュリティの観点からは、はるかに高いハードルが予想されます。私たちが発見した問題の多くは、開発手法の悪さだけではなく、構成、テスト、およびネットワーク セキュリティの概念の理解における根本的な誤りを表しています。残念ながら、これは重要なインフラストラクチャの標準であり続けています。このシリーズが、ベンダーがセキュリティに再投資する動機となることを願っています。研究コミュニティに積極的に関与し、サードパーティの研究と責任ある情報開示を後援して受け入れ、顧客や一般大衆とのコミュニケーションを積極的に行います。政府施設での使用が広くテストされ、認定されているため、基本的なセキュリティの観点からは、はるかに高いハードルが予想されます。私たちが発見した問題の多くは、開発手法の悪さだけではなく、構成、テスト、およびネットワーク セキュリティの概念の理解における根本的な誤りを表しています。残念ながら、これは重要なインフラストラクチャの標準であり続けています。このシリーズが、ベンダーがセキュリティに再投資する動機となることを願っています。研究コミュニティに積極的に関与し、サードパーティの研究と責任ある情報開示を後援して受け入れ、顧客や一般大衆とのコミュニケーションを積極的に行います。しかし、構成、テスト、およびネットワーク セキュリティの概念の理解における根本的な誤りを表しています。残念ながら、これは重要なインフラストラクチャの標準であり続けています。このシリーズが、ベンダーがセキュリティに再投資する動機となることを願っています。研究コミュニティに積極的に関与し、サードパーティの研究と責任ある情報開示を後援して受け入れ、顧客や一般大衆とのコミュニケーションを積極的に行います。しかし、構成、テスト、およびネットワーク セキュリティの概念の理解における根本的な誤りを表しています。残念ながら、これは重要なインフラストラクチャの標準であり続けています。このシリーズが、ベンダーがセキュリティに再投資する動機となることを願っています。研究コミュニティに積極的に関与し、サードパーティの研究と責任ある情報開示を後援して受け入れ、顧客や一般大衆とのコミュニケーションを積極的に行います。
開示状況
8 つの脆弱性すべてにインストール可能なパッチがあり、HID Mercury の顧客とパートナーにとって最優先事項です。さらに、Trellix のお客様は、当社の IPS シグネチャを介して説明されているエクスプロイト手法に対してある程度の保護を受けています。HID Mercury との開示の代理人となってくれた Carrier に感謝します。多くの点でプロセスを複雑にしましたが、彼らは責任と説明責任を負い、迅速に作業してパッチ適用を促進し、CVE を提出することで公開作業を支援しました。適切な緩和策を開発し、顧客に迅速に通知する役割を果たした HID Mercury に感謝します。Convergint にも感謝します。この異常なプロジェクトの構築を熱心に支援し、カスタマイズされたデモ ソリューションを提供してくれました。最後に、読者の皆様、本当にありがとうございました。最後までやり遂げてくれて、このプロセスを通じて何か価値のあるものを見つけていただければ幸いです。詳細については、LinkedIn または Twitter でお問い合わせください。
本記事およびここに含まれる情報は、啓蒙目的およびTrellixの顧客の利便性のみを目的としてコンピュータ セキュリティの研究について説明しています。Trellixは、脆弱性合理的開示ポリシーに基づいて調査を実施しています。記載されている活動の一部または全部を再現する試みについては、ユーザーの責任において行われるものとし、Trellixおよびその関連会社はいかなる責任も負わないものとします。
Trellixは、米国およびその他の国におけるMusarubra US LLCまたはその関連会社の商標または登録商標です。その他の名称やブランドは、該当各社の商標または登録商標です。
※本ページの内容は2022年8月25日（US時間）更新の以下のTrellix Storiesの内容です。
原文：A Door Isn’t a Door When It’s Ajar – Part 3
著者：Sam Quinn、Steve Povolny