出典：Aleksey Funtap／Alamy Stock Photo
OPC UAは、産業現場でVPNの代替としてよく使われる標準化されたオープンソースの通信プロトコルですが、実際には多くの脆弱性や問題点、悪用の可能性があることが判明しました。
先週、SecuraのプリンシパルセキュリティスペシャリストであるTom Tervoort氏が、DEF CON 33でOPC UA（Open Platform Communications Unified Architectureの略、2006年に初登場）に関するセッションを開催しました。このプロトコルは独自の暗号認証およびトランスポートセキュリティ層を備え、異なるベンダー間での相互運用性もあります。
「それが私にとって興味深い研究対象となった理由です。特にTLSのような既存の標準プロトコルに依存せず、独自の暗号プロトコルを実装しているからです」と彼はセッション中に述べました。「これらのセキュリティ機能がどのように動作しているかを調べて、問題がないか確認することにしました。」
Tervoort氏がこのプロトコルの調査に時間をかけたのは、運用技術（OT）環境（OTネットワーク間やOTとIT／クラウド環境の橋渡し）での利用が攻撃者にとって非常に魅力的な標的となるためです。特にVPNがない環境でOPC UAサーバーがハッカーに侵害された場合、「そのサーバーが制御している産業システムに大きな混乱をもたらす可能性があります」と研究によれば述べられています。
OPC UAのセキュリティバグを調査
Tervoort氏によると、OPC UAの暗号プロトコル設計には複数のハンドシェイク、秘密鍵、セッションキー、暗号化メッセージ、チャレンジ、ユーザー認証が含まれています。また、RSAやAESなどのセキュリティポリシーもサポートしています。Tervoort氏はこのプロトコルの暗号実装を「冗長で、あまり良い設計ではない」と評しました。
とはいえ、彼の説明によれば、暗号処理が全くないよりは3倍多い方がまだ良いとも言え、構造的には多層防御を提供する可能性もありますが、この「高コスト」な暗号設計にこそ研究者は穴を発見しました。
例えばTervoort氏は、サーバーからクライアント、またはその逆にメッセージが署名される場合でも、メッセージがクライアント向けかサーバー向けかを示すメタデータが存在しない形式になっていることに気付きました。これにより、脅威アクターが特定の文脈で署名されたメッセージを別の文脈で利用できるという概念実証（PoC）攻撃を作成できました。結果として、攻撃者は2つの異なるサーバーを互いにログインさせ、ほとんどの認証をバイパスし、互いに生成したチャレンジを与えることで騙すことが可能になります。
ただし、この攻撃を行うには最初の防御線であるセキュアチャネルハンドシェイクをバイパスする必要があります。そのためにTervoort氏は、プロトコルの一部の設定方法によっては、攻撃者がHTTPS接続を設定し、プロトコルが通信が既に暗号化されていると誤信し、ハンドシェイクが不要と判断することを発見しました。研究者はこれを自動で行うツールも作成しました。
「HTTPSベースのOPC UAサーバーで、このクライアント認証機能を使っているものにツールを向けるだけです」と彼は述べています。これは一部ベンダーの実装でデフォルト設定となっています。ただし、HTTPS版プロトコルは比較的新しく、「実際にはほとんど誰も使っていません」とTervoort氏は指摘します。また、このツールはユーザー認証が有効なサーバーのバイパスには使えません。
Tervoort氏はさらに掘り下げ、標準のTCP版プロトコルへの攻撃も試みました。問題なのは、1990年代後半にスイスの暗号学者Daniel Bleichenbacher氏によって破られたPKCS #1暗号標準をサポートしていたことです。
この標準は最終的に廃止され、OPC UAでも使用が推奨されなくなりましたが、一部の実装やベンダーでは依然としてデフォルトで有効になっており、弱い暗号が無効化されていても、暗号化メッセージを送ることでサーバーが悪用される場合があります。サーバーは復号後に初めて、この標準を使うべきでなかったと気付くのです。
今すぐパッチを：OPC UAを安全に保つ方法
これらの問題の悪用は設定や実装の詳細に依存しますが、それでもプロトコル自体の欠陥を反映しています。彼が責任を持って調査結果を開示した後、複数のベンダーが影響を受けていることを確認しました。
「7つの異なる製品に影響する問題を見つけましたが、実際にはもっと多くの製品が影響を受けている可能性があります」と彼は述べています。彼の研究の一部を示す3つのCVEが公開されています：CVE-2024-42512、CVE-2024-42513、およびCVE-2025-1468です。
幸いなことに、プロトコルを使用するすべてのベンダーがオープンソースプロトコルを管理するOPC Foundationと連絡を取っているため、関連ベンダーへの問題開示や修正の実装に協力してくれました。「OPC Foundationには感謝しています。私の経験上、責任ある開示がこのようにうまくいくことは珍しいです。」
修正内容は、ソフトウェアのアップデートから機能の無効化、設定アドバイスまで多岐にわたります。多くの場合（すべてではありませんが）、HTTPSとBasic128Rsa15の無効化で十分です。証明書ベースでないユーザー認証も影響を受けません。最終的にTervoort氏は、ユーザーや組織に対し、ベンダーのドキュメントを確認するよう勧めています。
この研究の結果、多くの脆弱性は、関連するベンダーパッチが適用されていれば、悪用がはるかに困難になりました。影響を受けるベンダーがまだ存在する可能性はありますが、既に行われた修正は、今後同様の問題が明らかになった際にも役立つはずです。
VPNに戻るべきかどうかについては、Tervoort氏は、組織が脆弱なサーバーを簡単にパッチできるかどうかによると述べています。仮にパッチが可能で、VPNなしで運用したい場合でも、特に重要なものを含むサーバーでは、許可された接続のみを許可するIPホワイトリストの利用を強く推奨しています。