McAfee LabsのAdvanced Threat Research Team（ATR）はビル管理など複数のアプリケーションに使用されているDeltaのコントローラを調べた結果、未報告のバッファーオーバーフローが発見した。「McAfee Labs、ビル管理にも使われる産業用制御システムの脆弱性を発見（前編）」に引き続き、確認された脆弱性とその潜在的な影響について詳細の技術的分析を紹介する。
現実世界のシナリオ
攻撃者にルートシェルを提供すれば脆弱性が悪用されることは明らかですが、攻撃者はそれを使って何ができるのでしょうか？攻撃者がシステムの通常の操作をコントロールしたり、貴重なデータを盗んだりできない限り、シェルはそれ自体では役に立ちません。その場合、デバイスに格納されている有用なデータはそれほど多くありません。システムの設定方法や何をコントロールしているかという情報をダウンロードできる者もおり、そこにはある程度の価値がありますが、それだけでは大きな影響はありません。使用不可の状態にターゲットを容易に配置できるDoS攻撃を用いて重要なシステムファイルを削除することも妥当ですが、単純な破壊もまたさまざまな理由から価値が低いものです。まず、前述のように、デバイスには起動中に障害が発生した場合にフォールバックするバックアップイメージがあります。デバイスに物理的なアクセスをしなければ、攻撃者はバックアップイメージが元のイメージとどのように異なるのか、または悪用できる可能性があるのかという明確な考えを持てません。バックアップイメージが異なるバージョンのファームウェアを使用している場合、エクスプロイトはもはや機能しません。おそらくもっと重要なことは、もともとDoS攻撃が繊細さに欠けていることに悩まされていることです。攻撃が実行されたときにすぐにアラームを停止させる場合、攻撃者はシステム内での持続性が長く続かないと予想できます。
システムが検出されずに攻撃者によってコントロールされた場合はどうでしょうか？このデバイスによってコントロールされる環境の種類を検討しながら、このシナリオはさらなる関心事になります。
通常のプログラミング
単なるルートシェルからデバイスの標準機能をコントロールするには、デバイスが通常の設定でどのように動作するかについてのより深い理解が必要です。通常、Delta eBMGRはインストーラーによって特定のタスクセットを実行するようにプログラムされています。これらのタスクは、アクセスコントロールの管理から建物の照明や空調設備などにまで及びます。一旦プログラムされると、コントローラーは複数の外部入力／出力（I／O）モジュールに接続されます。これらのモジュールは、接続されているデバイスの状態をコントロールすることと、情報を管理者に送り返すために利用されます。これらの「通常の状態」を再現するために、プロのインストーラーにサンプルのプログラムを使ってデバイスをプログラムさせ、適切なモジュールを添付しました。
図27は、各コンポーネントがサンプルプログラミングにどのように接続されているかを示しています。最初のテストでは、ポンプやボイラー、暖房弁のような大きな機器は実際に持っていませんでした。これらの機器の状態は、モジュール上のLEDかタッチスクリーンインターフェースのどちらかを通して追跡することができたため、テスト目的で入手することは不可欠でした。にもかかわらず、仮想であれなんであれ、それぞれの「デバイス」を入力または出力するどのタイプがモジュールに接続されているかに注目することは依然として重要です。
図27
これらのデバイスをコントロールするプログラミングは驚くほど簡単です。基本的に、入力に基づいて出力がレンダリングされます。図28は、テスト中にデバイスに存在するプログラミングロジックを示しています。
図28
3つのユーザー定義ソフトウェア変数があります。「暖房システム」、「室内温度Spt」、「暖房システム有効Spt」です。ここでの「spt」はセットポイントを指します。これらは実行時に管理者が定義でき、いつ出力をオンまたはオフにするかを決定するのに役立ちます。「暖房システム」バイナリー変数は単にシステムのオン／オフ状態をコントロールします。
デバイスをコントロール
最初に脆弱性を探し始めたときのように、デバイスをコントロールする方法はコントローラー毎によって異なるコードに依存しないようにする必要があります。そのため、Delta eBMGRに接続されているすべてのI／Oデバイスをコントロールする方法を見つけ、このデバイスの特定のプログラミングに依存しないようにします。
他のLinuxベースのシステムと同様に、最低レベルのインストーラー定義のプログラミングでは、システムの呼び出し、または関数を使用して、接続されているハードウェアをコントロールします。これらの関数を操作する方法を見つけることによって、インストーラーのプログラミングに関係なくモジュールをコントロールする普遍的な方法を手に入れるでしょう。システムへのルートアクセスがある場合、このタイプのコントロールを獲得する一般的な方法は、関数フックを使用することです。このアプローチの最初の課題は、単にどの関数をフックするかを決定することです。このケースでは、正常に動作している間に膨大な量のシステムのリバースエンジニアリングとデバッグを必要としました。調査する必要がある関数の範囲を狭めるために、バイナリー出力（BO）のコントロールに焦点を絞ることから始めました。最初の課題は、バイナリー出力の状態変更をハンドリングするコードをどのように見つけるかでした。
いくつかの重要な要素が、私たちが正しい方向に向かう助けになりました。まず、コントローラーのドキュメンテーションには、PLCデバイスによくあるコントローラー・エリア・ネットワークバス（CANバス）を介してデバイスがI／Oモジュールと通信することが示されています。前述のとおり、Deltaバイナリーにはすべてシンボルが含まれています。そのため、バイナリーで提供されている関数名を使用して、注目する必要があるコードの表面を減らすことができます。IDAによると、名前の最初の方に「canio」を持つ関数は28個しかないといいます。次に、BOの状態を変更するには物理ハードウェアを呼び出す必要があるため、その変更を行なうにはLinuxシステムの呼び出しが必要であると考えられます。デバイスがIOデバイスに変更を加えているため、使用されているLinuxシステム呼び出しは「ioctl」でほぼ間違いありません。「canio」で始まり、「ioctl」を呼び出す関数を相互参照すると、28あった検索スペースは14に減りました。1つの関数名が非常に目立ちました。「canioWriteOutput」です。関数のデコンパイル版を、図29で再現しました。
図29
この仮説を使って、canioWriteOutput内で「ioctl」への呼び出しにブレークポイントを設定し、タッチスクリーンを使用してバイナリー出力の1つの状態を「off」から「on」に変更します。ブレークポイントがヒットしました！一度ブレークポイントをステップオーバーすると、正しいLEDが点灯し、出力がオンになっていることを確認できました。
フックする必要がある関数がわかったので、すぐに次の質問が浮かびます。どのようにしてフックするのか？このタスクを実行するには複数の方法がありますが、最も簡単で最も安定した方法の1つは、LD_PRELOADという環境変数を使用して、起動プロセス時にメインバイナリーがメモリーに読み込むライブラリーを作成することです。プログラムを実行する前に、共有オブジェクトまたはライブラリーへの1つまたは複数のパスがLD_PRELOADに設定されている場合、そのプログラムは他の共有ライブラリーよりも先にそれらのライブラリーをメモリースペースに読み込みます。 Linuxが関数呼び出しを解決するとき、ライブラリーがメモリーに読み込む順番で関数名を探すので、これは重要です。したがって、メインのDeltaバイナリーの関数が名前とシグニチャーを、攻撃者によって生成され最初に読み込まれたライブラリーで定義されたものと共有している場合、攻撃者が定義した関数が代わりに実行されます。攻撃者はデバイスにルートシェルを持っているので、起動時にDeltaソフトウェアが開始する前に、攻撃者が生成したライブラリーへのパスをLD_PRELOAD変数に入力するためにinitスクリプトを修正することができます。そして再起動の際に実行するマルウェアを実質的にインストールします。
プロジェクトの初期段階で作成されたクロスコンパイルのツールチェーンを使用することで、図30に示す「ライブラリー」でこの理論を簡単にテストできました。
図30
上記のコードに何かしら意味があるものはありませんが、この方法をフックしても期待通りに動作するかを確認します。最初に、canioWriteOutput用のIDAで見たのと同じ関数プロトタイプを使用して関数ポインターを定義しました。canioWriteOutputが呼び出されると、まずこの関数が呼び出され、「opt」ディレクトリーに出力ファイルを作成し、テキストを書き込む場所を提供し、フックが機能していることを証明します。次に、シンボルテーブルでオリジナルの「canioWriteObject」を検索し、フックに渡されたものと同じパラメーターを使用してそれを呼び出し、実質的にパススルー関数を作成します。このテストの成功により、この方法が機能することが確認されました。
関数フックが単なるパススルーとして機能する以上のことをするには、どのパラメーターが関数に渡されていて、それらが実行に与える影響を理解する必要がありました。GDBを使用することで、「オン」状態と「オフ」状態の両方で渡されたデータを調べることができます。canioWriteObjectでは、バイナリー出力の状態が、関数に渡される2番目のパラメーターにエンコードされていることがわかりました。そこから、他のパラメーターをそのままにして、2番目のパラメーターとして望ましい状態を実関数に渡すだけで、バイナリー出力の状態を理論的にコントロールできます。ただし実際には、この方法を使用して生成された状態変化が持続したのはほんの一瞬で、その後デバイスは出力をリセットして正しい状態に戻りました。
なぜデバイスは出力を正しい状態に戻したのでしょうか？何らかの種類の保護が実行されているのでしょうか？メインのDeltaバイナリーの文字列とデバイス上のファイルシステムを調査したことで、デバイスソフトウェアがファイルシステム上にデータベースを維持していることがわかりました。再起動の際にデバイスと状態情報を保持するためとみられます。これらのデータベースの少なくとも1つは、おそらく他の種類のI／Oデバイスとともにバイナリー出力の状態を格納するために使用されます。GDBを使用したさらなる調査により、すべてのバイナリー出力の状態をデバイスがこのデータベースに継続的にポーリングして、データベースから取得した状態を公開するためにcanioWriteOutputを呼び出し、それ以前のどんな状態でも上書きしていることがわかりました。同様に、タッチスクリーンを介してユーザーによって行なわれたこの状態への変更は、この同じデータベースに格納されます。最初は、デバイスへのルートアクセスがあるため、最も簡単な解決策はデータベースの値を変更することだと思われました。ただし、データベースは既知の基準のフォーマットではありません。これは、この形式を置き換え、さらにデータの格納方法を理解する時間が必要なことを意味しています。すでに関数をフックする方法があるので、canioWriteOutputが呼び出されたときに出力をコントロールする方がより簡単です。
これを達成するために、マルウェアを更新し、攻撃者が出力に変更を加えたかどうかを追跡できるようにしました。変更が加えられていた場合、フック関数は、canioWriteOutputの2番目のパラメーターに格納されている正しい状態を、実際のcanioWriteOutput関数を呼び出す前に攻撃者によってアサートされた状態に置き換えます。さもなければ、フック関数は実際の取引のための単純なパススルーとして機能します。攻撃者の観点からのこのプラスの副作用は、マルウェアがそれを修正した後でも、ユーザーが最後に要求した状態として出力がタッチスクリーンに表示されることです。単なる状態追跡の実装によって、攻撃者がアサートした状態が持続しないという以前の問題が解決されました。
バイナリー出力をコントロールすることで、モジュールに接続できる他の種類の入力と出力のそれぞれを調べることにしました。モジュールからデータを読み書きし、それをフックする際に使用される方法を識別するときと同様のアプローチを使用しました。残念ながら、すべての関数がcanioWriteOutputほど単純ではありませんでした。例えば、アナログ出力をコントロールするために使用された関数を入れ替えると、デバイスの状態を含むアナログデバイスに関する様々な情報を保持するために、関数がカスタムデータ構造を利用することがわかりました。その結果、それらの状態を修正する前にアナログ情報がどのように出力に送られているのかを理解するため、まず、これらのデータ構造のレイアウトを入れ替える必要がありました。静的解析と動的解析を組み合わせて使用することで、管理者に接続されているすべてのデバイスの状態をコントロールするために、包括的な悪意のあるライブラリーを作成することができました。
マルウェアを次のレベルに
ルートシェルから変更を加えることで、攻撃者がエクスプロイトされたデバイスをコントロールできることは確かに証明されますが、攻撃者にとってはアクティブシェルに付随しない完全なリモートコントロールを持つことがより実用的かつ現実的です。I / Oモジュールを操作するためにすでに起動時にライブラリーを読み取っていたので、同じライブラリーを使用してコマンド・アンド・コントロールタイプのインフラストラクチャーを作成することも可能だと判断しました。これによって攻撃者は、常時接続やシェルアクセスを維持することなく、単に、リモートから「マルウェア」にコマンドを送信できるようになります。
この概念を実現するためには、バックドアを作成する必要があり、初期化関数はおそらくそれを配置するのに最善の場所でした。ちょっと調べたところ、CANバスを初期化させる関数である「canioInit」を見つけました。 CANバスはデバイスの動作に何らかの変更を加えるために必要とされるので、バックドアが開始される前にこの関数が呼び出されるのを待つのは理にかなっています。前述のいくつかのフックとは異なり、この呼び出しやその戻りデータに変更を加えることはありません。バックドアが適切なタイミングで開始されるようにするための手段としてのみ使用しています。
図31
canioInitが呼び出されると、まず新しいスレッドを生成してから、実際のcanioInit関数を実行します。新しいスレッドはUDPポート1337でソケットを開き、「バイナリ出力0をオンにする」を示す「bo0 on」や、デバイスをユーザーのコントロールに戻す「リセット」などの非常に特殊なコマンドをリッスンします。提供されたコマンドに基づいて、このスレッドで呼び出された「set_io_state」手段は、前のセクションで説明したように、必要なフッキング手段をアクティブにしてI／Oをコントロールします。
図32
Deltaソフトウェアのメモリースペースに完全に機能するバックドアがあるため、私たちは現実的な攻撃の連鎖についてデバイスを完全にコントロールしました。図33に攻撃全体の概要を示します。
図33
悪意のあるパケットの送信からリモートコントロールの取得までの上記のプロセス全体は3分とかからず、最も時間のかかる作業は再起動でした。攻撃者がコントロールを確立すると、ユーザーが提供される情報には影響を与えずにデバイスを操作できるため、攻撃者は検出されないまま、Deltaコントローラーが管理するハードウェアの種類に応じた深刻な被害をもたらすのに十分な機会が与えられます。
現実世界への影響
このような攻撃はどのような影響を与えるのでしょうか？これらのコントローラーは、世界中の複数の業界で導入されています。Shodanを使って、脆弱なファームウェアのバージョンを実行している600近くのインターネットアクセス可能なコントローラーを観察しました。 2019年2月から2019年4月までの間のeBMGRデバイスを追跡したところ、パブリックIPアドレスで利用可能な新しいデバイスが多数存在することがわかりました。
2019年4月上旬の時点で、492個のeBMGRデバイスがShodanを使用したインターネット全体のスキャンで到達可能のままでした。見つけ出されたもののうち一部は明らかにShodanデータ内で見つかった、ユーザーが適用したタグに基づくハニーポットであり、404の潜在的に脆弱な被害者を残しています。同じファームウェアを使用している他のDeltaコントロールデバイスを含め、それらが同じエクスプロイトに対して脆弱である可能性が高いと仮定すると、潜在的なターゲットの総計は1600以上に膨らみます。2019年2月以来、119の新しいインターネット接続eBMGRデバイスを追跡しましたが、その後オフラインになった216台のデバイスがこれらを追い越しました。これは産業用制御システムのシステムアドミニストレータがこれらのデバイスをインターネットに接続するための標準的な方法と、インターネットに接続された脆弱なデバイスのフットプリントを減らすために、積極的に顧客に手を差し伸べているベンダー（Delta Controls）による戦略が一体となった組み合わせだと考えています。ほとんどのコントローラーは北米にあり、米国はオンラインデバイスの53%を占め、カナダは35％を占めています。場合によっては、IPアドレスは、Shodanによるデバイスの地理的位置がISP（インターネット・サービス・プロバイダー）まで遡るため、誤った位置情報をもたらすことがあるということには注意が必要です。
デバイスのアクセシビリティを考えると、他の業界よりも危険にさらされている業界があるようです。業界を特定するためにこれらのデバイスのごく一部しかマッピングできませんでしたが、上位3位のカテゴリーは、教育、電気通信、不動産であることがわかりました。教育には、小学校から大学までのすべてが含まれていました。大学では、複数のキャンパスにまたがる多数の施設で、学区全体にデバイスが導入されることがありました。その一例が、カナダの公立学校システムで、地区内の各校舎にアクセス可能なデバイスがありました。電気通信は、完全にISPや電話会社で構成されていました。これらの多くが、ISPがサービスプロバイダーとしてリストされているためだとみられます。不動産のカテゴリーには、一般的にオフィスビルとマンションが含まれています。検索結果によって入手可能なメタデータから、脆弱な製品を使用している教育、医療、政府、食品、ホスピタリティ、不動産、保育、金融機関の事例も見つけました。
さらに掘り下げると、公開情報を通じて簡単に他のターゲットを見つけることができました。機密文書をオンラインに掲載するのは一般的なやり方ではありませんが、これらのデバイスが会社のビルディング・オートメーション計画の一部として使用されていることを示す多くの文書を確認しました。これは必要なインフラストラクチャー建設の提案書が発行される政府庁舎にとくに当てはまります。詳細な提案、要件、価格設定、エンジニアリング図面、その他予備調査に役立つ情報を含む、全体で約20の文書を集めました。とある政府庁舎には、デバイスの内部ネットワーク設定、制御図面、さらにデバイスの設置場所も含む48ページのマニュアルがありました。
攻撃者が第三者の空調や暖房をオンやオフに出来たら、どんな重要な問題があるでしょうか？影響を受ける可能性があった業界をいくつか見てみましょう。これらのシステムが誤動作すると、病院、政府機関、電気通信などの業界では、深刻な結果をもたらすおそれがあります。例えば、eBMGRは医療施設や病院で陽圧・陰圧室を維持するために使用され、そこでは加圧のわずかな変化が、空気感染性疾患の拡散によって生命を脅かす危険性があります。その代わりに、データセンターがターゲットになったとします。データセンターは、過熱しないように低温に保つ必要があります。仮に攻撃者が脆弱なコントローラーにアクセスし、危険レベルにまで室温を上げ、アラームを無効にすると、重要なデータが永久に失われる可能性があるのは言うまでもなく、サーバーハードウェアが大量に物理的に損傷し、ダウンタイムコストが発生するかもしれません。Ponemon Institute （https://www.ponemon.org/library/2016-cost-of-data-center-outages）によると、データセンター停止に伴う平均損失コストは2016年に74万357ドルにも達し、さらに上昇しています。マイクロソフトはその代表例です。2018年に同社は冷却故障のために大規模なデータセンターの機能停止（https://devblogs.microsoft.com/devopsservice/?p=17485）となり、およそ22時間にわたってサービスに影響を及ぼしました。
LEDライトの点滅よりも大きく影響を示すために、McAfee ATRは、稼働しているDeltaシステムで小規模なデータセンターシミュレーションを構築するために、ローカルのDeltaインストーラーを縮小しました。これには暖房と冷房の両方の要素が含まれ、本物のHVACシステムへの攻撃の影響を示すことができます。このデモでは、温度を危険なレベルまで上げ、重大なアラームを無効にし、さらに正常に動作しているとコントローラーに見せかけることで、ターゲットシステムの通常の機能と、エンドツーエンドの完全な攻撃連鎖をお見せします。以下のビデオは、この単なるパッチ未適用の脆弱性が実際のシステムにどのようにして壊滅的な影響を与える危険性があるかを示しています。
また、ヒルズボロの当社のラボにあるこのデモシステムで、有効なパッチ（この場合はDelta Controlsが提供）を使用し脆弱性が即座に軽減されるのを確認できることを強調します。これが今回の調査プロジェクトの最終的な目的です。
結論
CVE-2019-9569のような発見は、あらゆるデバイスにおけるセキュアなコーディング実践の重要性を示しています。Deltaのビルディングマネージャーなどの産業用制御システムデバイスは、きちんとセキュアな状態になっていない場合に企業や人に害を与えてしまう危険性がある重要なシステムをコントロールします。
産業コントロールなどの非標準環境に該当する製品のセキュリティーに関連するベストプラクティスと推奨事項がいくつかあります。デバイスの性質に基づけば、ウェブサーバー、エンドポイント、ネットワーキング機器のような基準のインフラストラクチャーと同じ可視性とプロセスコントロールが、それにはないかもしれません。その結果、eBMGR PLCのような産業コントロールハードウェアは、ネットワークやインターネットへの露出、脆弱性評価とパッチ管理、資産インベントリ、さらにはアクセスコントロールや設定レビューなど、さまざまな面から見過ごされるかもしれません。たとえば、最小特権の情報セキュリティーポリシーの原則はおそらく適切で、ネットワークの分離や保護されたネットワークセグメントは、敵対者へのアクセス境界を提供するのに役立つかもしれません。セキュリティー調査への関心と適切なパッチ適用戦略が、既知の脆弱性に対する露出時間を最小限に抑えます。これらの重要な資産を他のインフラストラクチャと同じ精査下に置くために、重要なセキュリティーテナントをそれぞれ徹底的にレビューおよび検証することをお勧めします。
McAfee ATRの目標の1つは、今日の複雑で絶えず進化する状況の中で、広範囲の脅威を識別して明らかにすることです。マカフィーの脆弱性公開に関する情報セキュリティーポリシーにより、McAfee ATRはDelta Controlsチームに直接情報を提供して取り組みました。このパートナーシップの結果、ベンダーはこのブログで詳述した脆弱性を効果的に軽減するファームウェアのアップデートをリリースし、最終的にはDelta Controlsの顧客向けに、この攻撃から身を護る方法を提供しました。脆弱なファームウェアバージョン（571848以前のもの）を使用しているあらゆる企業は、自社のパッチポリシーとテスト戦略に沿って、できるだけ早く更新することを強く推奨しました。特に重要なのは、インターネットに直接接続されているシステムです。McAfeeのお客様は、8月6日にリリースされた次のシグネチャで保護されています。McAfee Network Security Platform 0x45d43f00 BACNET：Delta enteliBUS Manager (eBMGR) Remote Code Execution Vulnerability.
ベンダーと研究者という関係の重要な役割を担い、責任ある開示という独自の課題を乗り越える能力を備えたDelta Controlsチームの卓越した努力に注目したいと思います。自社の製品と業界の共通の利益の両方についてセキュリティ研究と情報公開の力を受け入れてきました。Delta Controlsの次の声明をご参照ください。これは、McAfeeとの連携と責任ある開示の力についての洞察を提供します。
※本ページの内容は、2019年8月9日（US時間）更新の以下のMcAfee Blogの内容です。
原文：HVACking: Understanding the Delta Between Security and Reality
著者: Douglas McKee and Mark Bereza
