名古屋港 2023年 ランサムウェアによるコンテナの搬出入の停止

港の5つのコンテナターミナルが1つのシステムを共有し、その保守用VPNは緊急時のために接続元を限らず、IDとパスワードだけで誰でも入れた。物理サーバー8台が全部暗号化され、控えは3日分で、その控えからもマルウェアが見つかった。1つのシステムの停止が、港全体の搬出入を約3日止めた。

名古屋港運協会、名古屋コンテナー委員会、ターミナル部会の2023年7月の発表と7月26日の経緯報告[1][2]、国土交通省のコンテナターミナルにおける情報セキュリティ対策等検討委員会の2024年1月の取りまとめ[5]に沿って書いています。2023年7月6日18時15分に全ターミナルで作業が再開した[1]。国の制度の手当ては2024年11月の国土交通省の資料の時点まで書きます[6]。ログが暗号化され、侵入の経路は断定されていません。

要点

  • 2023年7月4日6時30分ごろ、名古屋港統一ターミナルシステム NUTS が止まった。物理サーバー8台と仮想サーバーが全部暗号化され、全ターミナルでトレーラーによる搬出入が止まった。
  • 保守用VPNは、緊急時にすぐ入れるよう接続元のIPアドレスを限らず、IDとパスワードが合えばインターネットの誰でも入れた。VPN機器と物理サーバーには、数か月前に公表された脆弱性が残っていた。
  • 委員会は、VPN機器から入った見方が適切としつつ、残っていた脆弱性はこの攻撃で使われた例が知られておらず、資格情報の取得や推測など、脆弱性以外の方法の可能性が高いとした。
  • 控えは直近3日分で、控えからもマルウェアが見つかり、駆除に1晩かかった。開発と評価の環境は控えの対象外だった。
  • 根本の直しは、保守の入口を接続元の制限と多要素認証で閉じ、感染の前に戻れる世代の控えを本体から切り離して持つこと。

何が起きたか

7月4日6時30分の停止から、14時の全暗号化の判明、5日夜の控えの中のマルウェア、6日18時15分の全ターミナル再開まで 7月4日 6時30分 NUTS が停止、 7時30分に脅迫文 4日 14時 物理と仮想の全 サーバーが暗号化 5日 12時 ランサムウェアと 発表 5日 21時 控えから マルウェアを検知 6日 18時15分 全ターミナルで 作業を再開 搬出入 トレーラーによる搬出入が止まり、本船の荷役は紙で続ける 影響 荷役に遅れが出た船37隻、搬入と搬出に影響したコンテナ約2万本、委員会の推計 帯の長さは時間の比ではない
図1 停止から再開までの約60時間
日時発表と取りまとめの内容
7月4日 6時30分ごろNUTS の作動の停止を確認。7時15分ごろ、システムの保守会社と開発会社に調査と復旧を依頼[1]
7時30分ごろシステム専用のプリンターから、ランサムウェアの脅迫文書が印刷される。8時15分ごろ、サーバーが再起動できないと判明[1]
9時ごろ愛知県警察本部サイバー攻撃対策隊に通報。感染の可能性があるとの見解[1]。10時30分ごろ、物流を早く再開させるためシステムの復旧を優先すると判断[5]
14時ごろ物理サーバーの基盤と全仮想サーバーが暗号化されていると判明[1]
7月5日 2時ごろ物理サーバー8台が全部復旧し、仮想サーバー45台の復元を始める[5]
12時協会がランサムウェアへの感染と発表し、当日のトレーラーによる搬出入の中止を告げた[2]
21時ごろ控えのデータからウイルスを検知し、駆除のため復旧が翌日にずれ込むことが確実になった[1]
7月6日 2時ごろウイルスの検査が終わり、トロイの木馬120個、マルウェア4個、その他8件を検知し、駆除を始めた[5]
7時15分ごろ控えのデータの復元が完了したが、システムのネットワークに障害。14時15分ごろ解消し、控えとヤードの在庫の整合を確かめた[1]。協会は7時30分にシステムが復旧したと発表した[3]
15時から18時15分準備の整ったターミナルから順に作業を再開。18時15分に全ターミナルで再開[1][4]
7月26日協会が経緯報告を公表[1]
2023年7月31日から2024年1月国土交通省の委員会が4回開かれ、9月29日に中間取りまとめ1、11月30日に中間取りまとめ2、2024年1月24日の第4回を経て取りまとめ[5][6][7]
  • NUTS は、名古屋港の5つのコンテナターミナルと集中管理ゲートで運用されていた。委員会は、日本の港湾施設が受けた初めての大規模なサイバー攻撃と書く[5]。
  • 脅迫文に身代金の額は無く、協会は攻撃者に連絡していない[1]。
  • 経緯報告の時点で、外部への情報漏えいの形跡は確認されていない[1]。
  • 船との間の荷役は、紙に印刷した作業内容をもとに手作業で続け、最大24時間程度の遅れは出たが、名古屋港を飛ばした船は無かったとされる[5]。

通った道筋

インターネットから、接続元を限らない保守用VPNを通って物理サーバーに入られ、8台と仮想サーバー45台が暗号化され、5つのターミナルとゲートが止まった。USBと港運事業者からの接続も経路として否定されていない 外 攻撃者 保守用のIDと パスワードを得る USBメモリ 経路の候補2 港運事業者 NATで接続、候補3 データセンターの NUTS 保守用VPN機器 接続元の制限なし 公表済みの弱点が残る 物理サーバー 8台 公表済みの弱点が残る 全台が暗号化 仮想サーバー 45台 全部が暗号化。マルウェア対策は OS 付属のみ 5つのコンテナターミナルと集中管理ゲート 搬出入が全部止まる
図2 委員会が最も適切とした道筋。破線は否定されていない別の経路

委員会は、感染の経路として、保守用のVPN機器からの侵入、USBメモリからの持ち込み、港運事業者との連携に使うNATでの接続からの侵入の3つを挙げた。物理サーバー8台が全部暗号化されて起動しなくなったことから、アプリケーションを経ずにサーバーへ直接攻撃された可能性が高く、VPN機器からの侵入と見るのが適切とした[5]。

保守用VPNは、緊急時にすぐ対応するため接続元のIPアドレスを限らず、IDとパスワードさえ合えばインターネット上の誰でも入れる状態だった。VPN機器と物理サーバーには数か月前から脆弱性が公表されていたが、対応されていなかった[5]。

脆弱性を突かれたとは断定されていない

協会の経緯報告は、リモート接続の機器の脆弱性が確認され、そこから不正なアクセスを受けたと考えられると書いた[1]。委員会の取りまとめはさらに踏み込み、保守用VPNで未対応だった脆弱性は、いくつかの標的型攻撃で悪用が知られるだけで、この件で使われたランサムウェアの攻撃で悪用された例は知られていないとした。VPN経由だったとしても、保守用のIDとパスワードの不正な取得や推測など、脆弱性の悪用以外の方法の可能性が高いが、特定はできていない[5]。どちらの場合も、接続元を限らない入口と、IDとパスワードだけの認証が前提にある。

攻撃者の名は公表資料に無い

報道には攻撃者を特定のランサムウェアの集団とするものがあるが、協会の発表と国土交通省の取りまとめは、ランサムウェアや攻撃者の名を挙げていない[1][5]。

なぜ3日かかったか

侵入より復旧の作りが、止まった長さを決めた。委員会が挙げた問題点は次のとおり[5]。

見つかった状態何が起きたか
控えは直近3日分だけ控えの中からもマルウェアが見つかり、感染の前のきれいな状態に戻れる控えが無く、駆除をしてから戻した[5]
本番の環境だけを控えの対象にし、開発と評価の環境は対象外容量と費用のために対象を絞ったことで、かえって復旧の時間と費用が増えた[5]
システムログとアクセスログを控えていないログも暗号化され、原因を解析できなかった[5]
VPN機器のログの控えが無い入口の解析ができず、経路を断定できなかった[5]
システム障害を想定した事業継続計画が無い災害用の計画はあったが、システム障害の時の手順は事前に無かった[5]
初動でセキュリティの専門家に相談していない連絡先は保守会社と開発会社だけで、復旧の対応でもログやデータが失われた[5]

委員会は同時に、愛知県警と平時から関係を作っていたこと、協会の幹部の指示でターミナル部会が意思決定の場として働き、丸2日半で戻したこと、手作業で荷役を続けたことを、ほかのターミナルの参考になる点として挙げる[5]。ただし、システム化の前の手作業を知る人がいたから可能だったとの指摘も添えている[5]。

どこで止められたか

開いた入口、鍵だけの認証、サーバーへの直接の攻撃、共有の1点、戻せない控えの5段それぞれの下に、止める仕組みを置く 1 開いた口 接続元を限らない 2 鍵だけ IDとパスワード 3 基盤へ 8台が全部暗号化 4 共有の1点 5ターミナルが停止 5 戻せない 控えも汚染 接続元の制限 保守の会社の 決まったIPだけ 多要素認証 ロックと 異常な接続の通知 更新と対策 弱点を直す OS付属で終えない 止まる前提 障害時の計画と 手作業の手順 戻せる控え 数週間前まで 切り離して保存 1と2で入口を閉じ、4と5で止まる長さを縮める
図3 被害が進む5段と、それぞれで止める仕組み
段この件で報告されたこと委員会が推奨した対策
1 開いた口保守用VPNは緊急時のために接続元を限らなかった[5]接続元のIPアドレスを指定して限る[5]
2 鍵だけIDとパスワードが合えば誰でも入れた[5]知識、所有、生体のうち複数を求める認証。12文字以上の複雑なパスワード、アカウントのロック、通常と違うIPアドレスからの接続の通知[5]
3 基盤へVPN機器と物理サーバーの公表済みの脆弱性が未対応。マルウェア対策はOS付属のみ[5]機器のソフトウェアを定期に確かめて更新する。OS付属以外のセキュリティ対策ソフトを入れる。管理者の認証にも複数の要素[5]
4 共有の1点システム障害を想定した事業継続計画が無かった[5]障害の調査、復旧、システムを使わない荷役の手順を事前に決める[5]
5 戻せない控えは3日分で汚染され、開発と評価の環境とログは対象外[5]潜伏を考えて数週間前の分まで複数の世代を持ち、現用のシステムから切り離した場所に置く。開発と評価の環境、ログも対象にする[5]

1と2 入口。緊急の便利さで開けた口

接続元を限らなかった理由は、緊急時にすぐ対応するためだった[5]。どこからでも入れる入口は、保守の会社の担当者にとっても攻撃者にとっても同じ入口になる。委員会は、保守のような身内に潜むリスクに目を向け、外部接続の部分の対策を見落とさないよう書く[5]。

悪い例。架空の港のシステムの保守用VPNの設定

# tos-vpn.example.com  架空の設定。値は説明用
allow_from      = any                 # 緊急時にどこからでも入れるように
auth            = password
account_lockout = off
log_forwarding  = off                 # ログは機器の中だけ

直した例。同じ機器

allow_from      = 203.0.113.16/29     # 保守会社の決まった出口だけ
auth            = password + totp     # 所有の要素を足す
account_lockout = 10 回で30分
alert           = 普段と違う接続元からの成功と、失敗の連続を通知する
log_forwarding  = syslog.example.com  # 機器の外へ送り、控えも取る

緊急時の接続は、接続元の制限を外すのではなく、保守会社の側に決まった出口を用意し、そこを通して入る形にする。厚生労働省の医療向けのガイドラインも、リモート保守を正規の経路を装って入れる裏口になり得るとし、経路の制限と二要素認証を求める[8]。同じ型の入口は、半田病院 2021年 と 大阪急性期・総合医療センター 2022年 にもある。推測による入り込みは A07 認証の不備 の自動化された推測にある。

3 基盤。公表された弱点と、OS付属の対策

脆弱性は数か月前から公表されていたが、VPN機器も物理サーバーも対応していなかった[5]。委員会は、サーバー機器とネットワーク機器のソフトウェアの情報を定期に確かめ、確実に更新すること、OS付属以外のセキュリティ対策ソフトを入れることを求める[5]。攻撃を受けたネットワーク機器は踏み台になっている恐れがあるため、新品と交換するようにも書く[5]。既知の脆弱性を持つ部品の扱いは A03 ソフトウェアサプライチェーンの不備 の型1にある。

4と5 止まる長さ。戻せる控えと、止まった時の手順

控えが3日分だと、潜伏の期間がそれより長いマルウェアは控えに入る。この件では控えからもマルウェアが見つかり、駆除をしてから戻すことになった[1][5]。委員会は、変わる頻度の低いシステムのプログラムは長い期間の控えを持ち、コンテナの情報のように動くデータは取得の頻度を上げ、数週間前の分を含めて複数を持ち、現用のシステムから切り離した場所に置くよう求める[5]。

ログも控えの対象にする。ログが暗号化されると、侵入の経路も、戻したシステムに攻撃者が残っていないかも確かめられない[5]。委員会は、運用を再開する前に、感染経路を踏まえてシステムの健全性を確かめることも求めた[5]。記録と保全の置き方は A09 セキュリティログとアラートの不備 にある。

調べることと戻すことはぶつかる

協会は物流の再開を優先して復旧を選び、丸2日半で戻した。その過程で失われたログとデータもある[5]。委員会は、障害の調査には発生時の環境を残す必要があり、復旧の開始と引き換えになり得ると書き、証拠の保全を考えた対応の手順を事前に作るよう求める[5]。ログを常に外へ送っておけば、この2つは両立しやすい。

守り方

根本の直し
  • 外部からの接続の入口を全部数え、保守用を含め、接続元の制限と多要素認証を掛ける。緊急時の便利さのために制限を外さない[5]。
  • VPN機器とサーバーのソフトウェアを定期に確かめて更新し、誰が更新するかを委託の契約に書く[5]。
  • 感染の前に戻れる世代の控えを、本体から切り離して持つ。開発と評価の環境とログも含め、戻す手順を試す[5]。
緩和の策
  • アカウントのロックと、普段と違う接続元からの接続の通知を入れる[5]。
  • サーバーにOS付属以外のマルウェア対策を入れ、定義を最新に保つ[5]。
  • VPN機器、サーバー、ネットワーク機器のログを定期に取り、システムの外に控える[5]。
  • システム障害とサイバー攻撃を想定した事業継続計画を作り、システムを使わない作業の手順、セキュリティの専門家への連絡先、証拠の保全の順を入れて訓練する[5]。
  • USBメモリは使わず、使うなら本体から切り離した端末で検査してからにする[5]。
  • 身代金の支払いには応じない。委員会の推奨にも明記されている[5]。

国は取りまとめを受け、2024年3月8日に重要インフラの分野に港湾を加え、3月31日に改正した港湾運送事業法施行規則を施行し、コンテナターミナルで使うシステムの情報セキュリティの確保の状況を国が審査する仕組みを入れた。改正した経済安全保障推進法は5月17日に公布された[6]。審査の申請の項目には、外部接続のネットワーク機器の接続元の限定、アカウントのロック、ソフトウェアの定期の確認と更新、システムの外での控えの保存が並ぶ[6]。

参照

  1. NUTS システム障害の経緯報告 名古屋港運協会、名古屋コンテナー委員会、ターミナル部会、2023年7月26日
  2. 名古屋港統一ターミナルシステムのシステム障害について 名古屋港運協会ほか、2023年7月5日12時
  3. 名古屋港統一ターミナルシステムのシステム障害について 3 名古屋港運協会ほか、2023年7月6日7時45分
  4. 名古屋港統一ターミナルシステムのシステム障害について お知らせ 名古屋港運協会ほか、2023年7月7日
  5. 取りまとめ 名古屋港のコンテナターミナルにおけるシステム障害を踏まえ緊急に実施すべき対応策及び情報セキュリティ対策等の推進のための制度的措置について 国土交通省 コンテナターミナルにおける情報セキュリティ対策等検討委員会、2024年1月
  6. 情報セキュリティ対策等に関する制度的措置のフォローアップについて 国土交通省港湾局、2024年11月
  7. コンテナターミナルにおける情報セキュリティ対策等検討委員会 国土交通省
  8. 医療情報システムの安全管理に関するガイドライン 第7.0版 システム運用編 厚生労働省、2026年6月。10.2の節