node-opcuaで匿名の書き込みを許す脆弱性、修正版あり
node-opcuaの2.42.0以上2.180.0未満で、名前空間に設定した既定のアクセス制限が効かず、認証なしの接続元が書き込みやメソッド呼び出しをできる場合があります。2.180.0に更新し、該当する設定を使っていないかを確認してください。
急ぎ度: 早めに
CVSS v3は9.1で、認証なしにネットワークから悪用でき、修正版の2.180.0も公開済みですが、影響を受けるのは名前空間の既定権限に頼って制限している構成に限られます。
関係があるか
Node.jsでOPC UAサーバーを自作・組み込みしていて、名前空間単位の既定権限で書き込みやメソッド呼び出しを制限している組織が対象です。工場や設備の監視・制御に近い環境では、書き換えの影響が大きくなります。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| node-opcua（npmパッケージ） | 2.42.0以上2.180.0未満。ただし名前空間の既定権限を設定し、個別のRolePermissionsを持たないノードに継承で制限をかけている構成 | 2.180.0 |
確かめ方
- 1プロジェクトで
npm ls node-opcuaを実行し、入っている版が2.42.0以上2.180.0未満か確認する。依存先のパッケージ経由で入っている場合も、この表示で分かります。 - 2自社のコードでsetDefaultRolePermissionsを呼んでいるかを検索する。呼んでいなければ、既定権限の宣言がないサーバーとして、この脆弱性による認可回避の対象外です。
- 3呼んでいる場合は、個別のRolePermissionsを付けていないノードがあるか洗い出す。個別に権限を付けたノードも対象外です。
- 4node-opcuaを組み込んだ製品や外部ベンダーのシステムは、ベンダーに該当の有無と更新予定を問い合わせる。
何が起きたか
node-opcuaに、名前空間全体へ設定したアクセス制限が、個別の権限を持たないノードで効かなくなる脆弱性が見つかりました。制限をかけたつもりのサーバーで、認証していない相手が変数を書き換えたり、メソッドを呼び出したりできます。
node-opcuaはOPC UAをTypeScriptとNode.jsで実装したライブラリーです。名前空間の既定権限はsetDefaultRolePermissionsで設定しますが、実行時に権限を判定するSessionContext.getApplicableRolePermissionsが、設定された名前空間側の値ではなく、存在しない、またはnullのメタデータ値を読んでいました。このnullが「許可」として扱われるため、既定の制限が素通りになります。
修正版の2.180.0で解消されています。
攻撃の流れ
-
1
制限を設定
運用者が名前空間の既定権限を制限的に設定し、各ノードには個別の権限を付けず継承に任せている。
-
2
サーバーへ接続
認証を使わない接続元が、ネットワーク経由でOPC UAサーバーに到達する。
-
3
判定が許可に
既定権限が読まれず、権限なしの結果が許可として扱われる。
-
4
書き込み・呼び出し
書き込み可能な変数が書き換えられ、紐付いたメソッドが実行される。
どう悪用されるか
認証は不要で、利用者の操作も要りません。OPC UAサーバーにネットワークから届く位置にいれば成立します。CVSSの評価では、攻撃の難易度は低く、機密性と完全性への影響が高い一方、可用性への影響はないとされています。
悪用されると、書き込み可能な変数の値を勝手に書き換えられたり、紐付いたメソッドを実行されたりします。制御や設定に使う値であれば、設備の動作や業務データに直接響きます。制限を設定した本人が「守られている」と思っているため、異常に気づきにくい点にも注意が必要です。
今すぐやること
-
1
使っている版を確認する
各プロジェクトでnode-opcuaの版を調べ、2.42.0以上2.180.0未満かを確かめます。開発環境だけでなく、本番や出荷済みの製品に含まれる版も対象です。
npm ls node-opcua -
2
既定権限に頼る構成かを洗い出す
名前空間の既定権限を設定しているコードと、個別のRolePermissionsを持たないノードを一覧にします。該当しなければ、この脆弱性による認可回避の対象外です。
grep -rn "setDefaultRolePermissions" src/ -
3
2.180.0以降に更新する
修正版に更新して再ビルド・再デプロイします。更新後は、テスト環境で制限した名前空間に匿名のまま書き込めないことと、許可した利用者の操作が通ることを確認します。変更点や互換性の注意は、node-opcuaのGitHubにあるアドバイザリとリリースノートで確認してください。
-
4
更新前の書き込み履歴を調べる
該当する構成で公開していた場合は、更新前の期間に想定外の書き込みやメソッド呼び出しがなかったかを、サーバーのログや変更履歴で確認します。
すぐ更新できないとき
すぐに更新できないときは、個別にRolePermissionsを明示したノードが対象外であることを利用し、重要な変数とメソッドに権限を直接付けます。あわせて、OPC UAサーバーへ接続できる送信元を、ファイアウォールやネットワーク分離で信頼できる機器だけに絞ります。匿名接続を許可しない設定も有効ですが、認証済みの低権限ユーザーの扱いは告知で確かめてください。いずれもつなぎの対策で、修正版への更新が本筋です。
背景
OPC UAは、工場の設備やPLC、SCADA、IoTゲートウェイなどが値をやり取りするための通信規格です。node-opcuaは、それをNode.jsで動かすライブラリーで、設備データを集めて上位システムに橋渡しするゲートウェイや、監視用の小さなサーバーによく使われます。サーバー側では、どの利用者がどの変数を書き込めるか、どのメソッドを呼べるかを、ノードごとや名前空間ごとの権限で決めます。
今回の問題は、権限の設定そのものではなく、設定が見つからなかったときの扱いにあります。値が取れなかった場合に「拒否」ではなく「許可」に倒れる作りは、フェイルオープンと呼ばれます。名前空間の既定権限を一つ設定すれば配下のノードを一括で守れる、という便利な使い方がそのまま穴になったため、個別設定を省いていた構成ほど影響を受けます。
よくある質問
Q.node-opcua以外のOPC UA実装も影響を受けますか。
Q.2.42.0より前の版は安全ですか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
node-opcua is an OPC UA implementation for TypeScript and Node.js. From 2.42.0 until 2.180.0, namespace-level access control configured through setDefaultRolePermissions is not honored by the runtime enforcement path for nodes without explicit per-node RolePermissions. SessionContext.getApplicableRolePermissions reads a missing or null DefaultRolePermissions metadata value instead of the configured namespace field, and the null result is treated permissively. An anonymous network client can consequently write variables with CurrentWrite access or call bound methods when an operator configured a restrictive namespace default and relied on inheritance. Servers with no declared policy, nodes with explicit per-node permissions, and correctly bound programmatic namespace metadata are outside the authorization-bypass case. This issue is fixed in version 2.180.0.
出典: CVE.org (CVE Program・cvelistV5) NVD GitHub Advisory
参照URL
- advisory github.com
- advisory github.com
- advisory nvd.nist.gov
- patch github.com
- patch github.com
- web github.com