半田病院 2021年 保守用VPNからのランサムウェア

電子カルテの保守のために置いたVPN装置は、導入から一度も更新されず、そこから漏れた管理者の資格情報も世界に公開されたままだった。中では5桁のパスワード、ロックアウト無し、全員が管理者、ウイルス対策の停止が重なり、40台に広がった。閉じた網という前提が、入口と中の両方の守りを外させていた。

つるぎ町立半田病院のコンピュータウイルス感染事案有識者会議が2022年6月7日付でまとめた調査報告書と技術編に沿って書いています[1][2]。病院は2022年1月4日に電子カルテを再稼働して通常診療に戻り、報告書は示した技術的な対策を病院で実施する予定と書く[1]。それより後の実施状況は公表されていない。ログが残らず、侵入の経路は報告書でも推定にとどまります。

要点

  • 2021年10月31日未明、院内のプリンタが一斉に犯行声明を印字して発覚した。LockBit 2.0 で電子カルテのサーバーと端末が暗号化され、通常診療に戻るまで約2か月かかった。
  • 入口は保守用の FortiGate 60E と見られる。CVE-2018-13379 が放置され、2021年9月に公開された約8.7万台分の資格情報の一覧に、病院のIPアドレス、ID、パスワードが載っていた。接続元の制限も無かった。
  • 中では、パスワードの最小桁数が5、ロックアウト無し、ドメインユーザーが全員 Administrators、ウイルス対策と Windows Update と Windows Defender が止められていた。
  • 電子カルテの事業者が Windows Update とファイアウォールを止めるよう指示し、VPN装置を入れた事業者は脆弱性を知りながら病院に伝えなかった。誰も全体の守りを持っていなかった。
  • 根本の直しは、保守の入口を更新、多要素認証、接続元の制限の付いた管理下の物にし、閉じた網の中でも更新と最小の権限を保つこと。

何が起きたか

VPN装置の脆弱性の公表から、資格情報の一覧の公開、10月31日の暗号化、1月4日の再開までの流れ 2019年5月 開発元が脆弱性の 修正を告知 2021年9月 約8.7万台分の 資格情報が公開 10月30日深夜 端末にリモート デスクトップの跡 10月31日未明 プリンタが声明を 印字して発覚 2022年1月4日 電子カルテを 再稼働、通常診療 VPN装置の更新 導入から一度も更新されず、資格情報も変えられず 病院の機能 救急と新患を止め、約2か月 帯の長さは時間の比ではない
図1 入口の弱点が知られてから、発覚と再開までの流れ
日付報告書と発表の内容
2019年5月から2021年9月Fortinet が CVE-2018-13379 について、2019年5月、2019年8月、2020年7月、2021年4月、2021年6月、2021年9月に是正を告知した[1][4]
2021年9月8日Fortinet が、約8万7千台の FortiGate SSL-VPN の接続の情報が公開されたと告知し、更新と全パスワードの再設定を求めた[4]。報告書は、その一覧に病院のグローバルIPアドレス、ID、パスワードが含まれていたことを確かめている[1]
2021年10月30日 23時57分物品払い出しの端末に、リモートデスクトップの操作の跡。攻撃者はこれより前に入っていたと見られる[1]
10月31日 未明複数のプリンタが、データを窃取し暗号化したという文書を大量に印字。0時30分に電子カルテの不具合を確認し、3時に電子カルテのネットワークを遮断、8時に感染を確認、8時55分に県警へ相談し被害届が受理された[1]
10月31日 10時地震を主に想定した事業継続計画に沿って災害対策本部を置き、救急と新患の受け入れを止めた。16時に記者会見[1]
11月3日VPN装置のファームウェアを更新。ログの保全は確かめられていない[1]
11月22日身代金は求められていないが、支払わない方針を正式に決めた[1]
2022年1月4日電子カルテを再稼働し、通常診療を再開[1][3]
2022年6月6月7日付の有識者会議の調査報告書、技術編、セキュリティ・コントロールのガイドラインを病院のサイトで公表[3]
  • 攻撃を受けた、または影響を受けた端末とサーバーは、ログオンの成功だけが確かめられた9台、暗号化だけの15台、両方の16台で、合計40台[1]。電子カルテのAPサーバー、DBサーバー、バックアップサーバー、ADサーバー2台、医事会計のDBサーバーが暗号化に含まれる[1]。
  • 2018年までにオフラインで保管していたバックアップは暗号化を免れた[1]。データの多くは復旧を請け負った事業者が戻したが、その方法は報告書でも分かっていない[1]。
  • 情報の漏えいは確かめられていない。ただし報告書は、ADサーバーへのログオンも成功しており、漏えいの可能性は高いとも書く[1]。
  • 身代金の要求は、最初にプリンタから出た脅迫文だけで、データの公開による二重の脅迫は見られなかった。病院は支払っていない[1]。

通った道筋

インターネットから、更新されていない保守用VPN装置を漏れた資格情報で通り、共通の管理者で院内の端末とADサーバーへ広がり、40台が影響を受けた インターネット 病院の中。閉じた網とされていた 攻撃者 公開された一覧の IPとIDとパスワード 接続元の制限が 無く、どこからでも 保守用VPN装置 FortiGate 60E CVE-2018-13379 導入から更新なし 院内の業務端末 ウイルス対策は停止 パスワードは最小5桁、ロック無し Administrator は共通か類似 資格情報を取り PsExec で広がる ADサーバー 2台 ログオン成功 ポリシーも初期の まま 電子カルテ、医事会計、部門 サーバーのファイアウォールは無効 バックアップサーバーも同じ網 LockBit 2.0 で40台に影響
図2 報告書が最も可能性が高いとした道筋。VPN装置のログは更新で失われ、入口は推定

報告書は、電子カルテ系ではメールを使わず、Webの閲覧は別のセグメントで、公開されたRDPも無く、ソフトウェアの供給網からの侵入も考えにくいとして、ほかの入口を消していった。残るのは医療機器と電子カルテの保守に使うVPNだけで、侵入の可能性が極めて高いとした[1]。

CVE-2018-13379 は、FortiOS の SSL VPN のWebポータルで、認証の無い者が細工したHTTPの要求でシステムのファイルを読める経路の横断である。NVD が付けた CVSS 3.1 の基本値は9.8[5]。報告書の言葉では、これで管理者のIDとパスワードが手に入り、インターネットから閉域網に入れる[1]。修正の版を入れても、それ以前に取られた資格情報は生きている。Fortinet が更新とあわせて全パスワードの再設定を求めたのはこのためである[4]。病院の装置は、更新も資格情報の変更もされていなかった[1]。

中に入った後の横展開は、高度な手法が要らなかった。ドメインユーザーは Built-in Administrators に属し、ビルトインの Administrator も全台で共通で、Mimikatz で資格情報を取り出せる状態だった。PsExec の使用も指摘されている[1]。

設定見つかった状態
パスワードの方針最小桁数5。ロックアウトは無効。Administrator の名前は変えず、攻撃の流れにある端末は共通か類似のパスワード[1]
権限ドメインユーザーが Built-in Administrators に所属。UACは既定のまま[1]
更新グループポリシーで Windows Update を止め、Silverlight と Acrobat DC の更新も止めていた[1]
マルウェア対策入れたウイルス対策は電子カルテの導入時の不具合で止め、Windows Defender もグループポリシーで無効[1]
サーバーの通信サーバーのファイアウォールはすべて無効。端末とサーバーの間は平文のHTTP[1]
VPN装置VPN接続と管理画面に、接続元のIPアドレスの制限が無い[1]
ログが無いので断定できない

VPN装置は、事故の後に事業者がログを保存せずにファームウェアを更新し、端末も調査の前に初期化が進んでいた。報告書は侵入の経路を断定できず、内部の動きも、復旧の事業者が市販の道具で取った情報からの推定にとどまる[1]。

なぜ止められていたか

弱い設定は、偶然ではなく指示の結果だった。報告書が事業者に質問した結果は次のとおり[1]。

  • 電子カルテの事業者は、Windows Update を無効にし、パーソナルファイアウォールを動かさないよう、インフラの事業者に指示していた。どちらも、動かして不具合が出た報告は無いとしながらの指示だった。
  • 電子カルテは IE7 互換、ActiveX、Silverlight を前提にした2000年の設計で、ActiveX の自己署名の部品を黙って入れる設定と、システムの全サーバーを信頼済みサイトにする設定が要った[1]。
  • アプリは電子カルテの事業者、機器とOSの設定はインフラの事業者と、病院は別々に契約していた。インフラの事業者は設定の責任は電子カルテの事業者にあると考え、稼働後の保守の契約も無かった。
  • 両社とも CVE-2018-13379 の存在は知っていた。電子カルテの事業者は担当外とし、VPN装置を入れた事業者は病院に説明していなかった。
  • 病院の情報システムの担当は事実上1人だった[1]。

報告書はこれを、閉域網の安全神話による思考停止と呼ぶ。VPNで外とつながり、事業者の更新が入ってくる網は、閉じた網ではない[1]。

どこで止められたか

入口の弱点、漏れた鍵、中での推測、横展開、暗号化の5段それぞれの下に、止める仕組みを置く 1 弱い入口 VPN装置を更新せず 2 漏れた鍵 どこからでも入れる 3 中で推測 5桁、ロック無し 4 横に広がる 共通の管理者 5 止まる 約2か月 台帳と更新 保守の入口を数え 担当を決める 入口の認証 多要素と接続元 漏れたら全部変更 中の認証 長いパスワード 試行の制限 権限と分離 標準ユーザー 台ごとの管理者 戻す手段 切り離した控え ログの保全 1と2が入口、3と4が中、5は入られた後に戻す力
図3 被害が進む5段と、それぞれで止める仕組み
段この件で報告されたこと止める仕組み
1 弱い入口VPN装置は導入当初から更新されず、6回の告知が届いていなかった[1]外とつながる機器を台帳に載せ、誰が脆弱性の情報を見て更新するかを契約で決める[6][7]
2 漏れた鍵公開された一覧に病院の資格情報があり、変えていなかった。接続元の制限も無い[1]多要素認証、接続元の制限。漏れた疑いがあれば全員のパスワードを変える[4][6]
3 中で推測最小5桁、ロックアウト無し、名前を変えない Administrator[1]長いパスワードと試行の制限。アプリと OS のログインにも二要素認証[7]
4 横に広がる全員が管理者、共通の Administrator、サーバーのファイアウォールは無効、ウイルス対策は停止[1]利用者は標準ユーザー。ローカルの管理者は台ごとに別のパスワード。サーバー間の通信を要る物に絞る
5 止まるオンラインのバックアップサーバーも暗号化。オフラインの控えは2018年まで[1]影響が及ばない場所に数世代の控えを置き、戻す手順を試す[6]。サイバー攻撃を想定した事業継続計画

1と2 入口。保守の経路を管理下に置く

この件の入口は、利用者の側ではなく、保守の側にあった。保守の経路は事業者が置いて事業者が使うため、病院の台帳に載らず、更新の担当も決まりにくい。厚生労働省のガイドラインは、リモートメンテナンスを、正規の経路を装って入れる裏口になり得ると書き、二要素認証、管理者の共通アカウントの禁止、端末とIPアドレスでの経路の制限、RDPやVNCを直接インターネットに開かないこと、ログの定期のレビュー、委託先の管理を求める[6]。同じガイドラインは、情報機器の脆弱性の情報を常に集め、事業者に対応の可否を確かめ、難しければ代わりの策を協議して講じるよう求める[6]。

脆弱性の修正は、取られた資格情報を取り消さない。修正の告知を受けたら、更新と同時に、その機器のすべての資格情報を変える。漏れた資格情報の扱いは 秘密の鍵の扱い の漏れたときの順と同じで、無効化が最初である。既知の脆弱性を持つ部品を使い続ける型は A03 ソフトウェアサプライチェーンの不備 の型1にある。

3と4 中。閉じた網でも外と同じ設定にする

入口を越えられた後の広がりは、Windows の設定でほぼ決まった。報告書は、最新の修正が当たり、ウイルス対策が動き、適切なロックアウトと標準ユーザーでの運用がされていれば、少なくとも攻撃を遅らせるか止められた可能性があると書く[1]。

悪い例。架空の病院の、初期のまま運用されたドメインの方針

# 架空のドメイン hospital.example.com の方針を書き出したもの。値は説明用
MinimumPasswordLength      : 5
LockoutThreshold           : 0          # 0 は試行の上限なし
Builtin\Administrators     : Domain Users
WindowsUpdate              : Disabled by policy
DefenderAntivirus          : Disabled by policy
ServerFirewall             : Off

直した例。同じドメインの方針

MinimumPasswordLength      : 13         # 二要素認証を入れるまでの期間
LockoutThreshold           : 10
Builtin\Administrators     : 保守の担当者ごとの管理用アカウントだけ
LocalAdminPassword         : 台ごとに別の値を自動で回す
WindowsUpdate              : 事業者と検証して適用する
ServerFirewall             : On、要る通信だけ許す

13桁という値は、厚生労働省の令和8年度版のチェックリストが、二要素認証を入れるまでの期間に求める長さである。同じチェックリストは、パスワードの使い回しの禁止、管理者権限を持つ人の明確化、不要なアカウントの無効化、セキュリティパッチの適用、アプリと OS へのログインの二要素認証を並べる[7]。ロックアウトは、IDごとに掛けるだけでは多くのIDに少しずつ試す攻撃を止めきれない。推測の止め方は A07 認証の不備 の自動化された推測にある。

事業者の指示で守りを外さない

更新やファイアウォールを止める指示は、動作の保証を優先した結果だった[1]。守りを外さないと動かない製品は、外す前にその理由と代わりの策を文書で求める。厚生労働省のガイドラインも、脆弱性の対策が難しいときは事業者と代わりの策を協議するよう求める[6]。設定を事業者に任せきりにしない。

5 戻す。控えと証拠

オンラインのバックアップサーバーは、ほかのサーバーと同じ網、同じ管理者で暗号化された。無事だったのは2018年までのオフラインの控えだけだった[1]。技術編は、整合性のあるオフライン、オフサイトの控えからの復旧を対策の柱に置き、必要な世代の復旧を実際に試し、手順書を作るよう書く[2]。厚生労働省のガイドラインも、重要なファイルを数世代、複数の方式で控え、一部はマルウェアの影響が及ばない手段で管理するよう求める[6]。

VPN装置のログは、更新の前に保存されなかった。その結果、入口は推定のまま残った[1]。入られたと分かったら、更新や初期化の前に、装置とサーバーのログを外へ写す。ログを装置の外へ送り続けておけば、この順を誤っても証拠が残る。記録と保全の置き方は A09 セキュリティログとアラートの不備 にある。

守り方

根本の直し
  • 外とつながる機器と保守の経路を、すべて台帳に載せる。機器ごとに、脆弱性の情報を見る者、更新する者、期限を、事業者との契約に書く[6][7]。
  • 保守の入口は、多要素認証と接続元の制限を付け、使うときだけ開ける。共通のアカウントをやめ、保守の担当者ごとのIDにする[6]。
  • 閉じた網の中でも、修正の適用、マルウェア対策、標準ユーザーでの運用を外さない。外さないと動かない製品は、調達の時点で選ばない[1]。
緩和の策
  • 機器の脆弱性の告知を受けたら、更新と同時にその機器の全部の資格情報を変える[4]。
  • ローカルの管理者のパスワードを台ごとに別にし、ドメインの管理者は管理専用の端末からだけ使う。
  • サーバーのファイアウォールを有効にし、端末からサーバーへ通す通信を要る物に絞る[1]。
  • 控えを数世代、影響の及ばない場所に置き、戻す手順を試しておく[2][6]。
  • VPN装置、AD、サーバーのログを装置の外へ送る。事故の時は、更新と初期化の前にログを保全する[1]。
  • サイバー攻撃で全システムが止まる前提の事業継続計画を作る。この病院は地震用の計画を流用して紙の運用へ移れた[1]。

医療法施行規則14条2項は、病院の管理者に、医療の提供に著しい支障を及ぼすおそれがないようサイバーセキュリティを確保する措置を求める[8]。同じ型の件が、翌年、給食の委託先を経由して起きた。大阪急性期・総合医療センター 2022年 を続けて読むと、入口が委託先に移っても中の設定が同じだったことが分かる。

参照

  1. 徳島県つるぎ町立半田病院 コンピュータウイルス感染事案 有識者会議調査報告書 つるぎ町立半田病院 コンピュータウイルス感染事案有識者会議、2022年6月7日
  2. コンピュータウイルス感染事案 有識者会議調査報告書 技術編 同会議、2022年6月
  3. コンピュータウイルス感染事案有識者会議調査報告書について つるぎ町立半田病院、2022年6月7日
  4. Malicious Actor Discloses FortiGate SSL-VPN Credentials Fortinet PSIRT、2021年9月8日
  5. CVE-2018-13379 NIST NVD
  6. 医療情報システムの安全管理に関するガイドライン 第7.0版 システム運用編 厚生労働省、2026年6月。8.2、10.2、11の節
  7. 医療機関・薬局におけるサイバーセキュリティ対策チェックリスト 令和8年度版 厚生労働省、2026年6月
  8. 医療法施行規則 第14条第2項 e-Gov法令検索