1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

セキュリティ事故分析「ポーランドPrivate APN侵入事件」と非保持型権限委譲

1
Posted at

0. はじめに

この記事は、セキュリティ関連のニュースを取り上げ、それに対して非保持型権限委譲をどのように適用できるか考察する技術記事です。

非保持型権限委譲については、以下の記事を参照してください。

1. 事件の概要

2025年12月29日、ポーランドのエネルギー関連施設を狙ったサイバー攻撃が発生しました。
この攻撃では、30以上の風力・太陽光発電設備などが攻撃対象となり、
約5万人へ熱を供給するCHP(熱電併給施設)でも、蒸気タービンや水処理設備が停止しました。

2026年8月8日にCERT Polskaが追加調査結果を公開し、Private APNを横移動に使って別の発電所OTネットワークへ侵入したという全経路が判明しました。
CERT Polskaは、実攻撃でPrivate APNがこの形で使われた事例としては把握する限り世界初としています。

2. 攻撃者はどのようにOTネットワークへ侵入したのか

poland_private_apn_ot_incident_01.png

CERT Polskaが再構成した経路は次の5段階です。

  1. FortiGate/VPNの侵害
    攻撃者はまず、風力発電所の境界機器を侵害し、VPN接続を確立しました。
    そしてそのLAN内に存在した、Teltonika RUTX50セルラールータを発見しました。

  2. Teltonika RUTX50への侵入
    TeltonikaのWeb管理画面、続いてSSHにログインします。
    このとき、RUTX50の初期パスワードは変更済みだったものの、攻撃者はrootに対しパスワード認証を複数回試行し、最終的に成功しています。
    攻撃者が変更後のパスワードをどのように取得したのか、あるいはRUTX50の脆弱性を利用したのかは判明していません。

  3. SSHトンネルによるPrivate APNへの進入
    RUTX50からSSHトンネルを張り、DSO(配電事業者)のPrivate APN内部へ侵入しました。
    攻撃者はPrivate APN内部を、VNC、HTTP、S7、Modbusなどでスキャンします。
    そして、APNに繋がっていた別施設のWAGO PFC200を発見しました。

  4. CHPのOTネットワークへ到達
    WAGO PFC200のパスワードは初期値のままでした。
    攻撃者はWAGOにログインし、WAN側SSHを有効化しました。
    その後、WAGOを踏み台に更にSSHトンネルを作り、CHP内部の専用OTネットワークへ侵入しました。

  5. Siemens PLCへのS7接続と破壊操作
    攻撃者は一週間ほど偵察したあと、12月29日にPLCやネットワーク機器へ破壊工作を実施しました。

3. 何重もの信頼境界を突破

FortiGate、RUTX50には、それぞれ認証機構が存在していました。
にもかかわらず、VPN、ルーターを突破され、Private APNに到達されました。

さらにPrivate APN上のWAGOにはデフォルト認証情報が残っており、WAGOを踏み台にCHP内部のOTネットワークへ侵入できました。
OTネットワークまで到達した後は、PLC等への直接通信が可能な状態でした。

4. 問題はネットワーク防御が破られたことなのか

ネットワーク信頼境界の設定が甘かった、と結論付けることも可能です。
しかし、WAGOのパスワードが変更されていたとしても、攻撃者が突破できなかったとは限りません。

根本的な問題は、閉域網への所属を暗黙の信頼として扱っていたこと
ネットワークへの到達可能性と、設備操作権限が十分に分離されていなかったことにあります。

Private APNにいる
      ↓
PLCへ到達できる
      ↓
PLCを操作できる

この信頼の連鎖自体が問題となります。

5. 非保持型権限委譲を工場設備へ適用する

このケースに、非保持型権限委譲を適用する例を考察します。

  1. PLCまたはPLC前段コントローラーを「実行主体」とする
  2. 保守端末を「認証主体」とする
  3. PLCのコントロールサーバーを「対応サーバー」とする
  4. 認証主体は保守時だけネットワークへ参加し、対応サーバーにログイン
  5. 認証主体は、実行主体(PLC)のハンドシェイクAPIへ、認証セッション識別情報を渡す
  6. 実行主体と対応サーバーの間で暗号化通信を確立
  7. 対応サーバー側で認証セッションと実行主体を対応管理
認証主体
(保守端末)
   │
   │ 必要時にハンドシェイク
   ▼
実行主体
(PLC / 前段コントローラー)
   │
   │ 暗号化通信
   ▼
対応サーバー

このように構成することで、対応サーバーと実行主体間で暗号化通信チャネルが確立され
他のネットワーク参加者からの命令を拒否できます。

そのため、攻撃者がOTネットワークに到達し、PLCに破壊命令を送ったとしても、PLCは命令を受け付けません。

FortiGate侵害       ○
RUTX50侵害          ○
Private APN侵入     ○
WAGO侵害            ○
OT LAN侵入          ○
PLC発見             ○

攻撃者 → PLC STOP
           ↓
正規対応サーバーからの通信ではない
           ↓
拒否

非保持型権限委譲では、ネットワークへの到達可能性と設備操作権限を分離します。

APIキーとの違い

このような、PLCが正規サーバー以外からの命令を拒否する機構自体は、APIキーやmTLSなど、PLC自体に認証機能を持たせることで実現できます。

対して、非保持型権限委譲では、認証主体がネットワークから離脱します。
PLCには認証セッション識別情報、PLC固有の暗号鍵しか残りません。
そのため、PLCが侵害されたとしても、サーバーの認証情報を取得できず、それを足掛かりとしてサーバーへ侵害を進めることができません。
また、認証セッションとPLC個別の暗号化鍵がサーバーで対応付けられるため、認証セッションや暗号鍵を横展開して、他のPLCを侵害することができません。

既存PLCには前段コントローラーで適用できる

非保持型権限委譲では、実行主体にハンドシェイクAPI、暗号化通信部を実装する必要があります。
しかし、古いPLC機器にこれらの機能を直接実装する必要はありません。

PLC前段に実行主体となるPLCコントローラーを配置し、PLCはコントローラーからだけ通信を受け付けるように構成できます。  
そうして、PLCコントローラーと対応サーバーが、暗号化通信を行います。

対応サーバー
    ↓
前段コントローラー
    ↓
既存PLC

この構成によって、既存の設備にも適用することができます。

6. 非保持型権限委譲でも防げないもの

  • FortiGateへの初期侵入
  • RUTX50そのものの侵害
  • Private APNへの侵入
  • WAGOのデフォルト認証情報
  • OTネットワークの偵察

非保持型権限委譲によって無害化できるのは、侵入したネットワークから、そのまま設備操作権限を取得できる攻撃経路です。

7. まとめ

Private APNなどのネットワーク境界を信頼することには限界があります。
ネットワーク分離やVPNを何重にしても、直列の信頼関係である場合、侵害が伝播するからです。

非保持型権限委譲によって、ネットワークの信頼性と設備操作権限を分離することができます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?