ICSセキュリティの盲点 ― プロトコルゲートウェイ：（2）ICSへのステルス攻撃を可能にする脆弱性
本ブログシリーズでは、本リサーチの結果をもとに、工場のスマート化に欠かせないプロトコルゲートウェイに見つかった深刻な脆弱性の影響を分析し、工場セキュリティ管理者が取るべきセキュリティ対策を提示します。第二回目となる本稿では、本リサーチの検証手法と結果を概観し、実験で明らかになったセキュリティリスクのひとつである「プロトコル変換機能の欠陥」について解説します。
プロトコルゲートウェイは、「プロトコル変換器」「プロトコルコンバータ」とも呼ばれる小型のネットワーク機器で、異なるプロトコルによる通信の仲介役を担ういわばデジタル世界の「通訳」のような存在です。IoTで加速するネットワークの統合により、プロトコル変換の重要性は高まっています。しかし、プロトコルゲートウェイのセキュリティについては、今まで十分に検証されてきませんでした。トレンドマイクロは、プロトコルゲートウェイの持ちうる潜在的なセキュリティリスクに着目し、2020年8月6日、そのセキュリティリスクをまとめたホワイトペーパーをリリースしました。本ブログシリーズでは、本リサーチの結果をもとに、工場のスマート化に欠かせないプロトコルゲートウェイに見つかった深刻な脆弱性の影響を分析し、工場セキュリティ管理者が取るべきセキュリティ対策を提示します。第二回目となる本稿では、本リサーチの検証手法と結果を概観し、実験で明らかになったセキュリティリスクのひとつである「プロトコル変換機能の欠陥」について解説します。
検証方法：ブラックボックス法トレンドマイクロのリサーチチームは、プロトコルゲートウェイの変換処理能力を検証するため、プロトコルゲートウェイへのインプットとアウトプットを比較するというブラックボックス法を採用しました。この検証方法は、今回のように検証対象とした製品の設計情報が公開されていない場合に有効な手法です。今回の検証では、ファザー（テストパケット自動生成ツール）を用いて、検証対象となるプロトコルゲートウェイへのインバウンドトラフィックを生成し、プロトコルゲートウェイによる変換結果を比較しました。図１は、本検証のフレームワークを表しています。
結果：９つの脆弱性上記のブラックボックス法を用いたプロトコル変換プロセスの分析により、本リサーチで検証対象とした5製品中3製品に、合計で９つの脆弱性が発見されました（表1）。これらすべての脆弱性は、トレンドマイクロの脆弱性発見コミュニティ「Zero Day Initiative」により各メーカに報告されています。2020年8月18日時点では、5～7はメーカにてセキュリティパッチをリリース済み、8～9はメーカにて対応中というステータスとなっています。また1～4についてはメーカから「当該製品は生産終了のためパッチリリースは行わない」という旨の回答を受けています。では、それぞれの脆弱性について、以下に概要を見ていきましょう。
1.プロトコル変換バイパス【CVSS：xx】
不正なModbus TCPパケットがフィルタされずにプロトコルゲートウェイを透過してしまい、Modbus RTUの正規パケットとしてフィールドバスを流れてしまう問題です。攻撃者はこの脆弱性を悪用することで、本来の命令とは異なる命令をPLCに流し込むことが可能となります。
2.非暗号化MQTT【CVSS：xx】
TLS/SSLなどの暗号化をサポートしていないという脆弱性です。製品に暗号化を有効にするオプションがないため、常にクリアテキストでデータを転送します。その結果、攻撃者はスニッフィングを介してユーザ名やパスワードなどの個人情報に不正にアクセスできます。
3.認証バイパス【CVSS：xx】
ログインユーザー名がWebコンソールで設定されている場合でも、ゲートウェイが常にnullユーザ名（0x00000000）を送信してしまう脆弱性です。その結果、攻撃者は不正なMQTTブローカーを構成し、「匿名ログイン」を有効にする（または認証を無効にする）ことで、対象のゲートウェイによって変換されたすべてのトラフィックを傍受し、プライバシーと機密性を侵害できます。
4.無害化されていないMQTTアップストリーム【CVSS：xx】
クラウドに転送するデータをプロトコルゲートウェイが検証しないという脆弱性です。 Modbus TCPからMQTTへの変換では、アップストリームされるメッセージがmodbus仕様に準拠していることを検証することで正しい処理が行われますが、この脆弱性を持つゲートウェイはすべてのメッセージをアップストリームしてしまいます。そのため攻撃者は、サービスのバックエンドに潜む脆弱性をトリガーするような悪意あるペイロードをクラウドサービスに流し込むことが可能となります。
5.独自コマンドによる情報窃取【CVSS - 6.9】
プロトコルゲートウェイからイーサネット経由で送信される設定情報に暗号化キーが含まれているという脆弱性です。オンラインで取得したデバイスのファームウェアから抽出した独自の復号ライブラリを利用することで、暗号化された設定情報を復号することが可能です。
6.クレデンシャル情報の再利用【CVSS - 6.9】
乱数生成のためのランダムシードが設定されておらず、暗号化が再現されてしまうという脆弱性です。この脆弱性により、攻撃者は平文のパスワードを知らずとも、デバイスのクレデンシャル情報を再利用して管理者アカウントにログインすることが可能となります。
7.ルートシェル取得【CVSS - 8.8】
この脆弱性により、非特権ユーザが特権コマンドを実行できるようになります。これは、デバイスのウェブインターフェースによって提供される診断機能内の入力値チェックがおこなわれていないことが原因です。非特権ユーザは、単純なHTTP GETリクエストを介して、ルートユーザーとしてTelnetデーモンを起動できます。 これにより、権限のないユーザがデバイスへの完全なリモートアクセス（ルートシェル）を取得できるようになります。
8.Modbusパケット送信によるDoS【CVSS - 7.5】
攻撃者は特別に細工された悪意のあるModbus TCPパケットを送信することにより、プロトコルゲートウェイのリブートをリモートでトリガーできます。この脆弱性は、インバウンドパケットのサニタイズを製品が行っていないことが原因です。
9.メモリリーク【CVSS - xx】
特定の状況下でメモリリークが発生する脆弱性です。攻撃者は、プロトコルゲートウェイに送信された読み取りメッセージを介して、漏えいしたデータにアクセスします。
今回の研究だけで9つもの脆弱性が発見されたことは、今までプロトコルゲートウェイに対する十全なセキュリティ措置が施されてこなかったことを示していると言えるでしょう。
また、上記の脆弱性の中でも、特に『1.プロトコル変換バイパス』はプロトコル変換機能に特有のバグであり、なおかつICS環境内でのステルス攻撃を可能にしてしまう深刻な脆弱性です。それにもかかわらずメーカから修正パッチがリリースされない状況も鑑みると、当該製品ユーザへの注意喚起は必要と思われるため、以下に当該脆弱性の詳細を解説していきます。
プロトコル変換プロセスの欠陥：パケットフィルタリング機能の欠如プロトコル変換バイパスの例として、ICS環境内の制御系デバイスからPLCに対して「複数レジスタ書き込み」の命令を出したケースを考えてみましょう。表2は、「複数レジスタ書き込み」命令時のModbus TCPからModbus RTUへの正常なプロトコル変換を簡易的に表したものです。なお、表中の数値は16進数表記となっています。
Modbus TCPプロトコルは、TCP/IPスタックにおけるアプリケーション層でデータ交換を行います。Modbus TCPのデータは表1のようにByte単位で区切られます。左から転送ID、プロトコルID、メッセージ長を含むヘッダがあり、その後にファンクションコードを含むModbusペイロードが続きます。Modbusにおける命令は0x01～0xFFの「ファンクションコード」で定義されており、ここでは「0x10」＝「複数レジスタ書き込み」が命令となっています。開始アドレス以降のフィールドおよび数値は、ファンクションコードに対応して設定されます。
他方、Modbus RTUプロトコルは物理層におけるシリアル通信です。そのためTCPヘッダ情報は含まれず、プロトコル変換時にヘッダ情報はドロップされます。しかしキーデータとなるModbusペイロードは当然含まれているため、ファンクションコード以下のデータはメッセージフレームに含まれています（表3）。また、Modbus RTUにはエラーチェックコードと、データのStart/Endを表すサイレントインターバルが含まれていますが、ここではプロトコル変換時のデータ変遷を分かりやすくするために割愛しています。
この二つの異なるプロトコル形式のメッセージフレームを理解したうえで、正しい命令内容（＝ファンクションコードとそれに付随する転送データ）と、正しい宛先（＝ユニットID）をPLCに伝えることが、プロトコルゲートウェイの役目になります。表4は、正常なプロトコル変換のデータを示しています。
では、もしインバウンドパケットに不備があった場合、プロトコルゲートウェイはどのような挙動を見せるのでしょうか？セキュリティの観点から見れば、プロトコルゲートウェイは無効パケットをフィルタする機能を持って然るべきです。しかし、ファザーを用いて無効なModbus TCPパケットを流した結果、不正パケットを「透過」させてしまう製品があることが発見されました。図2は、その現象の一例を示したものです。
図2の赤文字部分はパケットの伝文長を示すフレームですが、本来は0x000B（11バイト）であるべきところを0x0009（9バイト）に意図的に変更し、Modbus TCPとしてはプロトコル仕様に準拠していない「正しくない」パケットになっています。しかし、当該プロトコルゲートウェイは、そのパケットをModbus RTU上にそのまま「置き換え」、フィールドネットワークに流してしまう結果となりました。また、Modbus TCPヘッダも保持されたままでした。
このシンプルなプロトコル変換エラーは、一見取るに足らない現象にも思えます。ただ単に有効でないパケットを透過するだけであれば、大きな危険があるとは言えないでしょう。しかし、この脆弱性を利用して、意図しない命令をフィールドデバイスに出すことが可能であれば、話は別です。トレンドマイクロは、プロトコルゲートウェイに流し込むパケットを細工することで、フィールドネットワークに対するステルス攻撃を可能にする新たな攻撃手法を確認しました。最終回となる次回では、このステルス攻撃手法の詳細を解説するとともに、本研究結果から推奨されるICS環境のセキュリティ対策を提言します。
----------------------------------------------------
石原 陽平 YOHEI ISHIHARA
トレンドマイクロ株式会社 グローバルIoTマーケティング室
セキュリティエバンジェリスト
カリフォルニア州立大学フレズノ校 犯罪学部卒業。台湾ハードウェアメーカーおよび国内SIerでのセールス・マーケティング経験を経て、トレンドマイクロに入社。世界各地のリサーチャーと連携し、IoT関連の脅威情報の提供やセキュリティ問題の啓発にあたる。