産業用制御システムの情報セキュリティ：攻撃ベクトルのヒューマンマシンインターフェイス

「約30年前、私たち産業オートメーションの専門家は、準備が不十分な課題に直面していました。 プロセスの進捗をリアルタイムでグラフィカルに表示できる機能を備えた産業用制御システムを導入し始めました。 ただし、最初は画面が空白で、情報を入力する必要があり、「良い」グラフィックスとは何かを読むことができるマニュアルがありませんでした。 私たちはできることはすべてやりましたが、むしろ、知っていることはすべてやりましたが、あまり知りませんでした。 結果は予測可能でした-ヒューマンマシンインターフェース（HMIまたは英語：HMI、人道マシンインターフェース）の非効率的なパラダイムを作成しました。 思考の慣性が残りを行いました。 基本的に、実装を簡単にするために、プロセスをP＆ID（英語：プロセスおよび計装図から）、数値で補完された機能図の形で表すことにしました。 「DCS / SCADAシステムのグラフィカル機能が向上し、古い画面が新しいシステムに単純に移行した場合でも、このパラダイムを順守しました。」

ビル・ホリフィールド、InTech。

歴史的に

調査によると、技術プロセスを観察および制御するオペレーターのエラーは、事故の約42％を引き起こします。 これは、生産の発展と自動化の強化によるものです。 同時に、実際の機器に近づいていないオペレータは、現在の動作条件で現在の自分の体調を評価することができません。 今日、現代の世界では、この機能はSCADAシステムによって実行されます。SCADAシステムの主なコンポーネントはヒューマンマシンインターフェイス（HMI）です。



歴史的に、HMI（ヒューマンマシンインターフェイス）は、スイッチデバイス、ボタン、スイッチ、サーキットブレーカーを意味すると理解されていましたが、現時点では、緊急シャットダウンボタンと緊急表示ランプが実際の物理的なオブジェクトである必要があります。 最新の操作パネルは、仮想ボタン、グラフ、アナログおよびデジタルインジケーターで構成されています。



安全基準に準拠しているため、物理デバイスを完全に放棄することはできません。 制御回路の物理的なギャップを整理し、仮想インターフェイスに障害が発生した場合に状況を制御できるためです。



操作パネルとヒューマンマシンインターフェース（HMI）は同じものではないことを理解することが重要です。 パネルは、プロセス技術を簡単に理解するための単なるインターフェースです。 最新の機能と「知的能力」のほとんどは、ソフトウェアによって決定されます。 したがって、HMIの進化は常にハードウェアとソフトウェアの開発と並行しています。



実践が示すように、オペレータとディスパッチャは、SCADAシステム用のヒューマンマシンインターフェイスを作成するプロセスに参加しません。 この要因は、オペレータの効率と、施設でのプロセス制御中にオペレータが行うエラーの数に影響します。



HMI開発の分野における受動的アプローチは、既に使用されているサンプルに基づいてインターフェイスを作成する設計者の要望によって決まります。 この問題は、ロシア連邦GOST 21480-76「システム」マンマシン」の領域で現在使用されているという事実によってよく説明されています。 図を模倣する。 一般的な人間工学的要件」、1986年11月に転載。明らかに、過去30年間で、SCADAシステムの能力だけでなく、技術プロセスの自動化のレベルと量に根本的な変化がありました。 規格IEC 60447-93「マンマシンインターフェース（HMI）、GOST R IEC 60447-2000」マンマシンインターフェース。 駆動原則””ですが、HMIを最適化するアプローチを反映していません。



その結果、今日では数千のオペレーターが数百億の生産量を管理しており、HMIの有効性がわからなかった当時に開発された原始的な写真を見ています。

HMIを改善する方法

人からマシンインターフェースに最大の利益をもたらす方法は、重要な情報を直感的に明確な形で提供することです。 高性能HMIは情報を表示します—有用な特定のコンテキストのデータ。 HMIは、さまざまなプロセス変数の値を表示するだけでなく、これらの値が「良い」か「悪い」かを表示する必要があります。 異常インジケータは明確に区別する必要があります。 グラフィック形式のプロセスで情報を提供すると、オペレーターの効果を最大限に高めることができます。 プロセスは、最も有益で即時の方法で提示される必要があります。



2009年に、電力研究所またはEPRIは、HMIの広範な研究を実施しました。 この調査の結果、「オペレーターヒューマンマシンインターフェースケーススタディ：石炭火力発電所シミュレーターでの既存の「従来の」オペレーターグラフィックスと高性能グラフィックスの評価、ID 1017637」というレポートが作成されました。



研究のために選ばれたTPPには、10年以上使用された特別なシミュレーターがありました。 テスト中に、既存の使い慣れたコントロール画面と高性能HMIの原理を使用して編成された新しいコントロール画面の両方を使用して、いくつかのオペレーターが重大な状況を検出および解決しました。 後者は、いくつかの重要な方法でオペレータの効率を大幅に改善しました。



このテストの前に、タスクを完了するために必要なすべての管理ツールを使用して、このようなシナリオ用の特別な画面を開発することは誰にも起こりませんでした。 テスト結果は、HMIを編成するための新しいアプローチがより効果的であることを示しました。 複雑な制御システムは、原則として、特別な知識のない人々によって作成された非効率的で問題のあるHMIを所有しています。 適切な原則に基づいて構築されたHMIにより、オペレーターのパフォーマンスを大幅に向上させることができます。 高性能HMIは非常に実用的で、実装が簡単で手頃な価格です。

HMIの現在の傾向と抱負

重要な意思決定の生産のためのプロセス制御システムは、どんなに現代的であっても、常に人次第です。 利便性、信頼性、機能性は、プロセス制御システム全体の成功を大きく左右します。



自動化に関するその他の要件は、プロセステクノロジ自体の複雑さに関連しており、さまざまなメーカーのさまざまなデバイスが関係しています。 消費者にとって、すべてのさまざまなデバイスとのHMI統合の容易さ、オープンな通信プロトコル（ほとんどの場合イーサネット）のサポート、より白いシステムへの情報転送機能、およびここで紹介するソリューションのスケーラビリティが最初になります。



ただし、HMIには一般的な要件があり、これはマシンとプロセスの自動化の両方の特徴です。 第一に、カスタマイズの容易さと生産のニーズへの適応です。 第二に、動的なオブジェクトを含む独自のオブジェクトを作成し、それらを複製する機能。 第三に、環境条件やその他の要因に関係なく、情報を明確かつ明確に表示します。 最後に、第4に、現在の状態、環境条件、その他の要因に関係なく、システムを迅速かつ明確に制御する機能。



スマートフォンやタブレットの時代では、画面は情報出力デバイスとしてだけでなく、入力デバイスとしても認識されています。



上記のように、操作パネルの革新的な機能の多くは、ソフトウェアの進化に関連しています。 ソフトウェアの特性から、アプリケーション開発の速度と構成の柔軟性が決まります。



通常、HMIハードウェアには業界特有の明確な特徴はなく、IEC、UL、CSA、EAC、マリンBV、GL、ATEXなどのさまざまな分類団体の証明書によって決定されます。



また、市販のアーキテクチャ-TVDA（技術的に検証された文書化されたアーキテクチャ）を使用して、HMIツールを業界のタスクに適合させることもできます。 TVDAのおかげで、かさばるプログラムを作成する必要はなく、既成のアーキテクチャのパラメーターを入力するだけです。



スクリプトプログラミング言語JavaScriptをサポートすることにより、パネルを構成するためのソフトウェアの機能を大幅に拡張することができます。これにより、ほぼすべてのロジックを実装できます。



近年のHMI市場の重要な傾向の1つは、固定パネルだけでなくモバイルデバイスを使用して生産プロセスを制御する能力です。 この機能は、リモート機器を制御する必要がある場合に需要があります。



高度なオプションを使用すると、技術管理者または開発エンジニアは、モバイルデバイス上で操作パネル画面に関連しない追加の画面を作成できます。 彼らの助けを借りて、従来のワークステーションでは利用できない設定を変更できます。



また、最新のオペレーターパネルは、ユーザーにSMSまたは電子メールを送信することで、遠くからユーザーとやり取りできます。



産業用コンピューターには、ユーザーのニーズに応じて、Windowsオペレーティングシステム、アプリケーションをインストールするためのSCADAシステム（監視制御システムとデータ収集）、またはHMIシステムまたはWebインターフェイスがインストールされています。



HMIツールは自動化システムの不可欠な部分であり、そのコンポーネントのいずれか、多くの場合トップレベルシステム（ERPおよびMES）と簡単に統合する必要があります。

脆弱性と可用性

生産ネットワークは通常、パブリックネットワークや企業の内部ネットワークから分離されているように見えます。それらの機器とソフトウェアは、従来のネットワークとは大きく異なります。すべてのプロセスが明確に規制され、厳密に制御されていることは言うまでもありません。



SCADA HMI市場は非常に活発ですが、多くの場合、必要なほど安全ではありません。 この業界で最大のHMIサプライヤは、シーメンス、アドバンテック、およびGEですが、他の多くの国にも多くの小規模企業が存在します。 場合によっては、製品のパッチがリリースされる前に小さな会社が購入されるため、情報開示のプロセスで脆弱性のステータスを追跡することが難しくなります。



さらに、SCADAシステムベンダーは、それを管理するソフトウェアではなく、産業用機器に焦点を合わせる傾向があります。 彼らは機器の販売から利益を得るからです。



SCADAシステムの根底にある実際のコードに関しては、ほとんどが基本的な保護（アドレス空間割り当て（ASLR）のランダム化、SafeSEH、スタックCookieなどの詳細）を使用していません。 これは、これらのソリューションが完全に隔離された環境で機能するという誤った考えに起因する可能性があります。

重要なシステムへの不正アクセスを取得することの明らかなリスクにもかかわらず、SCADAシステム開発業界は、ソフトウェアではなく機器の生産に焦点を当てています。 HMIソフトウェアのグローバル標準の欠如は、この分野のセキュリティ上の懸念をさらに悪化させます。



この研究は、脆弱性知識ベース（ ICS-CERT、NVD、CVE、Siemens Product CERT、Positive Research Center、Trend Micro、Zero Day Iniciative（ZDI） ）、メーカー通知、エクスプロイトコレクションなど、公開されているソースからの情報に基づいています、科学会議の報告、専門サイトやブログでの出版物。



その結果、自動プロセス制御システムで743の脆弱性が発見され、2005年から2012年にかけて発見されました.2009年から2012年にかけて、自動プロセス制御システムで検出された脆弱性の数は20倍に増加しました（9から192）。 近年（2012〜2015）、毎年検出される脆弱性の数は安定しています（約200）。 2015年のデータによると、3か月以内に排除された脆弱性は14％のみであり、3か月以上にわたって34％が排除され、残りの52％のエラーはまったく修正されなかったか、メーカーが排除時間を報告しませんでした。



2016年の時点で、インターネットで利用可能な158,087個のICSコンポーネントが発見されました。 ICSコンポーネントの最大数は、HTTP、Modbus（RTUおよびTCP / IP）およびProfibus / Profinet、BACnetを介して利用でき、それぞれ約33％、OPC（25％）を占めています。 ただし、検出される脆弱性の数は、製品の普及率と、製造元が責任ある開示ポリシーを遵守しているかどうかによって異なります。



SCADAコンポーネントおよびヒューマンマシンインターフェイスのコンポーネントで、最も多くの脆弱性が検出されました。 ただし、既知の脆弱性の5％のみが現在エクスプロイトを公開しています。 この指標は2012年と比較して大幅に減少しました。その後、35％の脆弱性に対するエクスプロイトを見つけることができました。

ACS TPで使用されるすべてのオペレーティングシステムの中で、Microsoft Windowsは大きな差でリードしています。 ほとんどの場合、SCADAシステムのさまざまなコンポーネント（HMIを含む）がグローバルネットワークに存在します。 検出されたすべてのオブジェクトの70％を占めています。



パブリックドメインで脆弱性または脆弱性に関する情報を悪用する既製のツールがあると、攻撃が成功する可能性が大幅に高まります。



通常、公開されている脆弱性の数は、公開されているエクスプロイトの数と相関しています。 2011年の初めから2012年9月までに、50件のエクスプロイトが公開されました-2005年から2010年までの6年間の6倍です。

ただし、既知の攻撃の実現方法がないため、攻撃の可能性は減りますが、完全に除外されるわけではありません。産業施設に対するサイバー攻撃は、「エクスプロイトパック」やその他の一般的なツールを必要としない経験豊富な高レベルの専門家が参加して行われるためです。



攻撃者はシステムに侵入するための深い知識と長い準備を必要としないため、脆弱性は既に悪用されていますが、パッチはまだリリースされていないため、最も危険です。

HMI脆弱性レポート2016

SCADAソリューションの開発者は、多くの場合、ユーザーインターフェイス（UI）を構築した経験がほとんどありません。 これは、システムの最終的な動作環境がどうなるかを開発者が知らないという事実によるものです。 これにより、開発者は多くの場合正しくない仮定を行うことを余儀なくされます。 コード開発の完全なライフサイクルがなければ、プログラムには脆弱性が含まれます。 SCADA開発者は、10年前にアプリケーションおよびOS開発者が犯したのと同じ間違いを犯し続けます。



トレンドマイクロの専門家は、HMIの脆弱性に関連する2015年から2016年までのICS-CERT警告を分析し、残念な結論に至りました。

この調査では、SCADA HMIの現在のセキュリティステータスを検証します。 Zero Day Initiative（ZDI）プログラムを通じて取得された250の脆弱性を含む、2015年と2016年以降に修正されたSCADAソフトウェアのすべての公開された脆弱性の分析。 脆弱性のほぼ3分の1（36％）は、バッファオーバーフロー（バッファオーバーフロー）に関連しています。 このセキュリティ上の問題により、攻撃者はプログラムの異常終了またはフリーズを引き起こし、サービス拒否につながるだけでなく、ターゲットシステム上で任意のコードを実行することができます。



すべてのタイプの脆弱性を追加すると、その悪用によりハッカーがコード実行（たとえば、バッファオーバーフロー、リモートコード実行）を実行できるようになり、すべての脆弱性の約40％が得られます。 認証とキー管理（認証/キー管理）に関する多くの問題-ほぼ23％に注目する価値があります。



これらのエラーはすべて、安全なコード開発方法を使用して防止できます。 最後に、SCADAプロバイダーへのエラーの公開からパッチのリリースまでの平均時間は150日、さらに30日であり、ソフトウェアの展開に必要です。



これは、SCADAの脆弱性が修正されるまでに平均5か月かかることを意味します。 一部のメーカーの場合、これには1〜2週間しかかかりませんが、大規模なメーカーの場合は最大200日間かかります。



米国国土安全保障省のICS-CERTは、法執行機関および情報機関との連携およびプーリングの取り組みを通じて、すべての重要なインフラストラクチャセクター内のリスクを低減する役割を担っています。



さまざまな製品で見つかった脆弱性を人々から購入する、とても興味深いZDIプログラムがあります。 脆弱性を購入した後、彼らはコードにエラーがある特定の会社のすべての類似製品でこの脆弱性を分析します。 その後、彼らは会社に連絡し、脆弱性を提示します。 本質的に、これはビジネスに変わりつつあります。 ZDIプログラムがSCADAに影響する脆弱性を取得すると、この問題を解決するためにICS-CERTが報告されます。 2015年、ICS-CERTは295件のインシデントに対応し、486件の脆弱性開示を処理しました。



HMIにどの脆弱性が存在するかを判断するために、2015年と2016年のICS-CERT検出の結果、および過去2年間の修正を検討します。 このデータは、ZDIが購入した250以上のゼロデイ脆弱性と組み合わされました。 また、この情報をリストされたCWE脆弱性と比較して、合計を決定しました。



判明したように、調査された脆弱性の20％はメモリ破損（バッファオーバーフロー、フィールド外の読み取り/書き込みの脆弱性（範囲外読み取り/書き込み）など）が原因で発生しました。



脆弱性の23％は認証メカニズムの不足が原因で発生し、問題の19％は資格情報（有線パスワード、完全な権限を持つ隠しアカウント、クリアテキストでのパスワードの保存）に関連し、問題の9％はコードの実装を許可していました。





図1：脆弱性カテゴリ



いくつかのクロスサイトスクリプティング（XSS）およびクロスサイトリクエストフォージェリ（CSRF）の問題が予想されましたが、ほとんどのHMIの問題はWebアプリケーションではなくWindowsの問題です。 一部のXSSおよびCSRFエラーは、その他のカテゴリに存在しますが、少数です。



メモリ破損の問題



メモリ破損の問題は、特定された脆弱性の20％を占めています。 このカテゴリの弱点は、スタックバッファオーバーフローや読み取り/書き込み境界外のヒープなど、古典的なコード保護の問題です。 コードのどこかにエラーがあるためにメモリセルの内容が誤って変更された場合、HMIでメモリ破損が発生する可能性があります。



また、メモリセキュリティの違反とも呼ばれます。 破損したメモリの内容がこのプログラムで後で使用されると、コードがクラッシュするか、実行することを意図していません。





20.44％のメモリ破損



例：Advantech WebAccess HMIソリューション



ある時点で、ZDIは1日でAdvantech WebAccess HMIを使用して100の個別のレポートを受け取りました。 これらのケースのほとんどはバッファオーバーフローであることが判明し、そのほとんどは以下の例に似ています。



図2：Advantech WebAccessツールバー



1つの興味深い点は、現在SCADAソリューションであるが、モノのインターネット（IoT）のソリューションとしても宣伝されていることです。 ソリューションには、ローカル管理ユーザーのコンテキストで実行されるwebvrpcs.exeサービスが含まれています。 サービスは、伝送制御プロトコル（TCP）ポート4592でリッスンし、リモートプロシージャコールプロトコル（RPC）ベースのプロトコルを使用してアクセスできます。



アプリケーションからのサービスコールは、Microsoft Windows DeviceIoControl関数に似るように設計されています。 各サービスコールには、ジャンプテーブルを使用して数百のサービスタイプを使用できるI / O値（IOCTL）が含まれています。 この例では、パラメーターは名前ボックスであり、_sprintf関数を使用して0x80文字のスタックバッファーにコピーされます。







黄色でマークされた領域はIOCTLコードで、その後にバッファーの長さ（インとアウト）-サイズが0x8cバイト、最後にゼロが続きます。 この攻撃では、長さ0x80バイトのバッファーに0x8cバイトのデータが格納されるため、予測されるオーバーフローが発生します。 脆弱なコードを表示すると、オーバーフロー状態を許可する従来の_sprintf呼び出しが明らかになります。







スタックレイアウトをチェックすると、WindowNameが-80に設定され、戻りアドレスとして0が表示されます。 コンパイル段階でインストールされなかったため、保護のために設定されたスタックCookieはありません。







スタックCookieの欠如、およびASLRやSafeSEHなどの他の保護は、おそらく、これらのエンコード方式が存在する前に元のコードが書かれたという事実によるものです。 ただし、禁止（API）を使用し、詳細なセキュリティ対策がないため、攻撃者は戻りアドレスを攻撃バックリンク（ROP）の先頭に書き換えるだけで済みます。



ASLRがなければ、攻撃者によって制御されたコードを昇格された特権で実行するのに手間はかかりません。 この脆弱性に対するパッチの分析により、データベースのエージングコードをクリーンアップするための興味深いオプションも明らかになりました。 元の_sprintf関数は、2007年にリリースされたAPI禁止のMicrosoftのリストに含まれていました。 ZDIの研究者は、アドバンテックが禁止されているAPIのリストを実装し、コードから既知の悪い機能を削除することを期待していました。 代わりに、このエラーのパッチは_sprintf関数を_snprintf関数に変更しました。







ただし、_snprintfも禁止APIリストに含まれています。 _snprintfは_sprintfよりも優れたオーバーフロー復元力を提供しますが、文字数が多すぎると（null文字で）終了できません。



これは、スタックがクリアされない場合（まれな状況）、サイバー犯罪者がこのWindowNameで文字列操作を使用して、プログラムが0x80文字のバッファーをカウントするように仕向けることが可能になることを意味しますが、実際には、バッファーはゼロで終了しないため、バッファーは長くなります。



アドバンテックがリリースした75個の修正のうち、すべてがスポット修正でした。 つまり、プロバイダーはバグを修正しましたが、グローバルな問題機能は修正しませんでした。 数千の_sprintf関数と_snprintf関数が、今日のコードベースに残っています。 アドバンテックは、ZDIの研究者によって報告された残りの25の質問に対するパッチをリリースしませんでした。 これらの問題はその後、ZDIプログラムの方針に従って一般に公開されました。



資格情報管理の問題



資格情報管理の問題は、特定された脆弱性の19％を占めています。 このカテゴリの脆弱性は、ハードコードされたパスワードの使用、回復可能な形式（たとえば、プレーンテキスト）でのパスワードの保存、不十分な資格情報保護などのケースです。







非表示のGE MDS PulseNETアカウント



ゼネラルエレクトリック（GE）MDS PulseNETは、世界中のエネルギー、上下水道セクターに展開されているデバイスと産業用通信ネットワークの監視に使用されます。 ZDIプログラムは、「影響を受ける製品には、完全な権限を持つハードコードされたアカウントが含まれている」と報告しています。 完全な調査の結果、CVE-2015-6456が公開され、システムの総合的な脆弱性評価（CVSS）の評価は9.0になりました。



ユーザーコントロールパネルを見てください。これは、システム内に2つのアカウント（オペレーターと管理者）のみが存在することを示しています。 ただし、Andrea Micalizzi（「rgod」とも呼ばれる）が指摘したように、管理者権限を持つ3番目のアカウントが隠されています。





図3：GE MDS PulseNETユーザーコントロールパネル



HeidiSQLを使用してデータベースから情報を取得すると、ge_supportアカウントにパスワードハッシュ<！[HDATA [MD5 $ 8af7e0cd2c76d2faa98b71f8ca7923f9。 解読されたMD5ハッシュ、「Pu1seNET」として表示されるパスワード。





図4：ログイン後のGE MDS PulseNETユーザーコントロールパネル



ge_supportアカウントを使用してログインした後でも、3番目のユーザー名はユーザーのコントロールパネルに表示されません。



認証/承認の欠如およびデフォルトでの安全でない場所



このカテゴリは、SCADA脆弱性の23％を表します。多くの安全でないデフォルト、機密情報の転送におけるクリアテキスト、暗号化の欠如、安全とマークされた安全でないActiveXコントロールが含まれます。







使用例：Siemens SINEMA Serverの安全でないファイルの



アクセス権アクセス特権の最も一般的なHMI脆弱性の1つは、企業が標準のWindows Program Filesディレクトリを使用する代わりに独自のアクセス制御リスト（ACL）と最上位ディレクトリを作成することを決定した場合に発生します。



これらの最上位ディレクトリを適切に保護する代わりに、デフォルトで書き込み可能であり、ディレクトリツリーにはサービス決定ソースファイルが含まれています。これにより、ローカルユーザーは、ディレクトリにシステムサービスとして実行される新しいバイナリファイルを埋め込むことができます。この問題はSiemens SINEMAサーバーで発生し、CVE-2016-6486を使用して解決されました。製品自体は、弱いACLを持つディレクトリツリーにインストールされます。デフォルトでは、MicrosoftはProgram FilesディレクトリをACLで保護されるように設定します。





図5：標準プログラムファイルのアクセス許可を表示するコマンドライン



このツリーにファイルを書き込むことができるのは、管理アカウントと特殊アカウントだけではないことに注意してください。ユーザーには、読み取りと実行の権限もあります。プログラムファイルまたは少なくともProgram Filesと同じ権限を使用する代わりに、Siemensインストーラーは独自の最上位ツリーを作成します。





図6：Siemens SINEMA Serverのセキュリティ許可プロパティ



上記のように、システムのすべてのユーザーは、このディレクトリに含まれるファイルにデータを追加および書き込むことができます。ユーザーは、ファイルとサブディレクトリを追加することもできます。これにより、ディレクトリのローカライズが原因でコードが実行される可能性があります。さらに悪いことに、プログラムのアクセス許可を見ると、結果は懸念を裏付けます。







ハイライトされた行で示されているように、認証されたユーザーは完全に制御できます。信頼できるユーザーグループに参加するには、ユーザーはWindowsドメインに対する認証のみが必要です。本質的に、これは、システム内のほぼ全員がAuthenticated Usersグループに属することを意味します。このディレクトリのソースコードを調べると、同様の結果が示されます。







この特定のソースファイルは、ローカルシステムレベルで実行されるサービスを起動することに注意することが重要です。







この安全でないデフォルトのインストールの最終結果により、認証されたユーザーは必要に応じて元のファイルを置き換えることができます。さらに、この新しい攻撃者が管理するバイナリは、次回の再起動後にローカルシステムコンテキストで実行されます。



例：Advantech WebAccess



Advantech WebAccessは、クロスプラットフォーム、クロスブラウザのデータアクセスと、HTML5テクノロジーに基づくユーザーインターフェイスを提供します。 ZDIは、パスワードを変更するときに他のパスワードを表示できるエラーメッセージを受け取りました。



このエラーに関するICS-CERTレポート「適切に認証された管理者は、他の管理者のパスワードを表示できます。」これはシステム管理者を意味するものではないことに注意してください。これは、SCADAシステム管理者に適用されます。ソリューションの一部として、SCADA管理者が自分のユーザー名、パスワード、または説明を更新できるupAdmin.aspスクリプトがあります。 Active Server Pages（ASP）スクリプトは、システム権限を持つ人が操作できます。





図7：Advantech WebAccessユーザー設定パネル



攻撃者がこのエラーを利用するには、まず既知のアカウントにログインし、「ユーザープロパティのプロジェクト」をクリックする必要があります。これにより

URL http：///broadWeb/user/upAdminPg.asp？に移動しますか？Uname = known＆return = bwproj

この例では、これはシステムのIPアドレスと既知のユーザーアカウントです。攻撃者は、その後の両方で、アカウント名に対象アカウントのURLアドレスを変更し

ます。http：？///BroadWeb/user/upAdminPg.aspのuname =被害者＆リターン= bwproj

アスタリスクで隠された最初の犠牲者のアカウントのパスワードが、しかし、見ているだけHTMLコードソースの場合、ページにはターゲットユーザーのパスワードが表示されます。







このエラーにより、認証されたユーザーは、SCADAソリューションの管理者を含む他のユーザーのパスワードを取得できます。



コード入力の問題



他のオンラインサービスと同様に、HMI領域にはコードインジェクションの脆弱性が存在します。これらの問題は、特定された脆弱性の9％に相当します。通常のタイプの注入はSQL、コマンド、OSですが、ドメイン固有のプログラミング言語への注入もあり、SCADAソリューションにリスクをもたらします。これらのドメイン固有の注入可能言語の1つはガンマで、Cogent DataHubシステムで使用されます。

- Gamma?

Cogent DataHub Gamma HMI . , Gamma , . , C C ++, , . Gamma API .

例：Cogent DataHub



製造元によると、Cogent DataHubは、他のWindowsアプリケーションのプロセス制御（OPC）のOLEにデータを高速かつ効率的に集中および配信するハブとして機能するリアルタイム常駐データベースです。



ZDIは、攻撃者がWebサーバーで安全でない処理モードを有効にできるエラーレポートを受け取りました。これにより、攻撃者は任意のスクリプトをサーバーに送信し、任意のコードを実行できます。





図8：Cogent DataHub WebView



上記のように、Cogent DataHubは、SCADAシステムスイートに視覚化を追加するリアルタイムミドルウェアを提供します。この場合、攻撃者はGamma EvalExpressionメソッドの欠陥を悪用して、標的システムで攻撃者が制御するコードを実行します。 Ajaxオブジェクトを介したこのリモートアクセス方法は、TCPポート80でリッスンします。



ガンマはドメイン固有の言語であるため、多くの組み込み関数とSCADA業界向けの関数が含まれています。ただし、スクリプトには、システムコマンドにアクセスして実行する機能も含まれています。以下の脆弱なコードからわかるように、攻撃者が違反できるのはこの能力です。







強調表示されたエラーは式を受け取り、単一のフラグをチェックして、システムが式を実行できるかどうかを判断します。このチェックがtrueを返す場合、式に含まれるものに関係なく式が実行されます。攻撃者は依然としてシステムをだます必要があります。攻撃者にとって幸いなことに、システムはこれも許可します。このエクスプロイトを完了するには、攻撃者はまず必要なライブラリをロードするガンマスクリプトにHTTPリクエストを送信する必要があります。



既に述べたように、開発者はこれらのシステムが分離されたネットワークで動作することを想定していますが、そうではないことがよくあります。攻撃者はリクエストを使用してAJAXSupport.AllowExpressionsを呼び出し、allow_any_expressionをTrueに設定します。これにより、攻撃者はAJAXSupport.AllowExpressionsを呼び出して、実行したいスクリプトを渡すことができます。この攻撃方法は非常に信頼性が高く、再現性があります。パッチのレビューは、Cogentがこの問題を解決する方法を示しています。下の画像の左側に古いコードがあり、右側にパッチコードがあります。変更が強調表示されます。





図9：修正前後のコードの違い



パッチの最初の部分では、AllowExpressionsは完全に削除されました。これにより、システムでこのフラグが切り替えられなくなります。開発者がEvalExpressionsを完全にアンインストールするまで、彼はコメントを作成しました。メソッドを使用するとセキュリティ上のリスクが生じることに注意してください。







Cogentは違反コードについてもコメントしたため、デフォルトでは設定されませんでした。コードを有効にするには、開発者がログインしてメソッドを手動でロック解除する必要があります。また、この方法により、将来エラーが繰り返される可能性が低くなります。



開示



研究者がSCADA製品の脆弱性を発見すると、エラーの修正にかかる時間は異なります。この時間は、しばしば脆弱性のウィンドウと呼ばれます。 ZDIの研究者は、プログラムを通じて得られたすべてのHMIの脆弱性（250以上）を調べ、それらが修正された期間を分析しました。過去4年間のデータからわかるように、平均修正時間は減少しません。



2013年以降、研究者がサプライヤーに間違いを開示してからパッチがリリースされるまでの平均時間は約140日です。





図10：脆弱性が年ごとに発見されてからの平均修正時間



リリースされたパッチの品質も、時間内に重要な役割を果たします。システムに問題のある更新を適用すると、重要なインフラストラクチャでサービス拒否（DoS）が発生する可能性があります。これらの問題およびその他の問題により、パッチの可用性と本番システムへのこのパッチのインストールには遅れがあります。

すべてのSCADAプロバイダーが同じ時間枠内で動作するわけではありません。



一部のベンダーは、他のベンダーよりもはるかに高速に応答します。たとえば、ZDIは、Cogent Real-Time Systemsがこの脆弱性に迅速に対応したことを分析しました。大規模なサプライヤ-ABB、GE、IndusoftおよびPTC-は、パッチの作成に平均200日以上かかります。





図11：彼らはサプライヤーの開示された時点から、脆弱性を修正する平均時間



、業界での比較を



SCADAメーカーの応答時間を他の産業と比較すると、応答時間は他の産業とそれほど変わらないことがわかります。マイクロソフト、アップル、オラクル、アドビなどの大規模ベンダーの広範なソフトウェアの平均応答時間は120日未満です。



SCADAシステムおよび自動化システムのセキュリティでは、平均で約150日間です。セキュリティソフトウェア業界はわずかに高速ですが、それほどではありません。ビジネスプログラムは、HPEやIBMなどの企業のものです。これらのプロバイダーは、エラー情報を開示するためにかなり長い時間を必要とします。





図12：脆弱性が業界で発見されてからの平均修正時間

おわりに

過去4年間、脆弱性を除去する効率はほぼ同じレベルである約140日間であったことは注目に値します。前述のように、SCADAシステムのメーカーは、ソフトウェアではなく産業機器に焦点を当てています。これは、ハードウェアが大きな利益をもたらすためです。

また、このレポートは、たとえば企業が犯すミスの多くが、特定の脆弱性（脆弱なAPIの置き換え、問題のある機能の無効化など）のみを排除しますが、それ以上ではないことも示しています。

« HMI SCADA- , . , , , . , »,- .

さまざまなソリューションを通じて、SCADA HMIは攻撃者にとって最も印象的で真の標的です。 HMIは、集中化された重要なインフラストラクチャ管理センターとして機能します。攻撃者がHMIの脆弱性を悪用した場合、機器の物理的な損傷を含め、インフラストラクチャ自体で何でもできます。



攻撃者がプロセスを中断しないことを決定した場合でも、HMIを使用してシステムに関する情報を収集したり、オペレーターに機器の危険を警告するためのアラートや通知をオフにしたりできます。



この調査では、ほとんどのHMIの脆弱性が、メモリ破損、資格情報管理、認証/承認の欠如、および安全でないデフォルト値の4つのカテゴリに分類されることを調査しました。これらのエラーはすべて、安全なコード開発方法を使用して防止できます。



また、研究者がSCADAプロバイダーに間違いを開示してからパッチがリリースされるまでの平均時間が150日、MicrosoftやAdobeなどのベンダーではさらに30日ですが、企業からの提供よりも43日少ないことに気付きました。 HPEやIBMなどの企業。



脆弱性がシステムへの効果的なエントリポイントであるHMI、SCADAシステムに対する攻撃のベクトルを考慮して、SCADAの所有者と管理者が公開された脆弱性を認識し、それに応じて脅威をブロックしようとすることを願っています。 HMIおよびSCADAソリューションの開発者は、10年にわたってOSおよびアプリケーション開発者によって行われてきたように、ソフトウェア開発ライフサイクルの安全な方法を採用するのに役立ちます。



禁止されているAPIを使用するための監査などの簡単な手順を実行することにより、ベンダーは攻撃に対する製品の耐性を高めることができます。 SCADA開発者は、製品が理想的なシステムで使用されないことも期待する必要があります。たとえば、これは悪いセキュリティ慣行と見なされますが、開発者は製品とソリューションに責任を持ち、システムがパブリックネットワークに接続されることを理解する必要があります。



製品使用の最悪のシナリオを含むアプローチを採用する場合、開発者はより深いセキュリティ対策を実装する必要があります。プロセス制御システム専用に設計された悪意のあるプログラムが存在し、HMIを積極的にターゲットにしています。

SCADAシステムのエラーは、もう何年もの間私たちにありそうです。連携して、これらのシステムのセキュリティは引き続き改善されます。完全に安全なシステムは決して作成されないでしょう。HMIコードの研究開発を強化することは、必要な限り攻撃者を阻止するための私たちの最高のチャンスです。