外部に公開された自動化インターフェースは、攻撃者にログインせず独自のコマンドを実行する手段を与えかねない。
VulnCheckは11月2日、監視システムがNode-REDに関連する認証欠如の脆弱性CVE-2026-58115の悪用を検知したと報告した。Siemensは以前、特定のSIMATIC IoT2050 Advancedの導入環境にこの脆弱性が存在し、最大権限でのリモートコード実行を許す可能性があると公表していた。
管理者にとって、対応ではアクセス制御とアプリケーションの挙動の両方を対象にする必要がある。侵入口を閉じただけでは、すでに不正なワークフローが存在するかどうかは確認できない。
攻撃者は自動化フローをコマンド実行に変える
Node-REDは、フローと呼ばれるワークフローを通じてアプリケーション機能を接続する。 VulnCheckの調査によると、攻撃者は10月30日、コマンドシェルを実行できるノードと自動トリガーを組み合わせた悪意あるフローを、同社のカナリアシステムに送信した。
このリクエストには、Linuxペイロードをダウンロードして実行する命令が含まれていた。ほかに確認されたリクエストでは、フロー内にウェブシェルが作成されており、後からHTTPリクエストを通じてコマンドを投入できる状態になっていた。これらのバックドアは再起動後も存続する可能性がある。
研究者は10月30日から11月1日にかけて、1つの送信元IPからこの脆弱性を標的とする16件のイベントを記録した。ダウンロードされたペイロードは取得できず、その機能は確認されていない。今回の調査結果が記録しているのは、VulnCheckの監視システムが受信した悪用リクエストである。産業顧客が侵害されたことや、ダウンロードされたペイロードが正常に実行されたことを示すものではない。
産業分野で使われることを考えると、これらのツールへのアクセスは重大な意味を持つ。別の Iconics SCADAの脆弱性は、周辺ソフトウェアの弱点が運用システムの可用性を脅かし得ることを示している。
注意が必要なSiemensの導入環境
Siemensのセキュリティアドバイザリは、8月11日付で、Industrial OS上でNode-REDがインストールされているSIMATIC IoT2050 Advancedデバイス（製品番号6ES7647-0BA00-1YA2）を特定している。
影響を受けるバージョンはV4.3.4.1未満。SiemensはV4.3.4.1以降への更新を推奨し、緩和策としてNode-REDのアンインストール、またはインストール環境の強化を挙げている。
この脆弱性のCVSS最大スコアは10.0。影響を受ける導入環境では、Node-REDのHTTPインターフェースに対する認証が強制されておらず、システムコマンドを実行できるプログラミング機能が外部に公開される。Siemensの対策に記載されたバージョン番号は影響を受ける製品リリースを指すものであり、Node-RED全般の更新先として扱ってはならない。
エディターとフローのエンドポイントは個別に保護する
この Node-REDセキュリティガイドは、エディターと管理APIを保護するadminAuthについて説明している。管理者は認証済みユーザーと権限を設定でき、フローを変更できるユーザーを制限することも可能だ。
フローによって作成されるHTTPエンドポイントには、別途保護が必要になる。Node-REDでは、HTTP Inノードによって公開されるルートでHTTP Basic認証を使用するhttpNodeAuthを説明しているほか、HTTPSによって接続を暗号化できる。管理者は管理インターフェースとアプリケーションのエンドポイントの両方で認証が有効になっていることを確認すべきだ。
ネットワークによる制限も、もう1つの防御層となる。 ネットワークアクセス制御とセグメンテーションを適用して、管理インターフェースには承認済みシステムからのみ到達できるようにし、意図せぬ外部公開につながるファイアウォールルールがないか確認する。
対応を終える前に、何が変更されたのかを明らかにする
まず、各導入環境の所有者と、それが支えているものを特定する。デバイスモデル、インストール済みリリース、アクセス経路、担当するアプリケーションチームまたは運用チームを記録する。これにより、対応担当者は更新と設定確認の具体的な対象範囲を把握できる。
次に、導入済みのフローを承認済みのベースラインと比較する。説明のつかない追加や変更、特にコマンドを起動したりHTTPエンドポイントを追加したりするワークフローを調査する。正当な自動化でもこうした機能を使う場合があるため、それらが存在するだけで侵害の証拠とはならない。所有者と本来の挙動を確認する必要がある。
不審な変更が見つかった場合は、組織の インシデント対応プロセスを利用して、封じ込め、証拠収集、調査、復旧を連携させる。関連する設定とログを保存し、変更によって本番環境の依存関係が中断する可能性がある場合は運用担当者も関与させる。
通常のアクセスを復旧する前に、必要な更新プログラムがインストールされ、認証が強制され、導入済みのワークフローが承認済みの挙動と一致していることを確認する。不正なコマンド実行が疑われる場合は、基盤ホストに追加の永続化や認証情報の露出がないか調査し、再構築が必要かどうかを判断する。復旧を裏付ける証拠を文書化し、未解決の指摘事項には担当者を割り当てる。
詳しくは： PHPの「Black October」対応が示す、チームがより早期のアクセスを調査し、インシデントを終結させる前に修正が有効になっていることを確認すべき理由。