Gallagher入退室アプリに脆弱性、トークン平文保存

Gallagher入退室アプリに脆弱性、トークン平文保存 脆弱性・脅威情報
2026.08.18

【更新 2026-08-19】本記事を見直し、修正しました。主な修正点：攻撃の前提条件を「端末を物理的に手にする必要がある」としていた記述を、ベンダーのアドバイザリの記載（“access to a logged-in Operator’s mobile device”）および CVSS v3.1 の攻撃元区分（ローカル AV:L は物理 AV:P とは別区分）に合わせ、「端末にアクセスできる状態」に改めました。

入退室管理システムのモバイルアプリに、セッショントークンを平文で保存する脆弱性が公表されました。対象は Gallagher Group の「Command Centre Mobile」（Android／iOS）で、バージョン 9.40.123 より前が影響を受けます。ログイン済みの警備担当者の端末にアクセスできる第三者が、トークンを抜き出して一定時間なりすませる可能性があります。

深刻度は CVSS v3.1 で 5.7（中）と控えめですが、奪われるのが「ドアを開ける権限」である点が、通常の情報漏えい系の脆弱性と決定的に違います。JVN／JVNDB では2026年8月17日に情報が更新され、あらためて日本語で周知されました。

この記事でわかること

  • Gallagher Command Centre とは何をするシステムで、誰が使っているのか
  • CVE-2025-47147 で何が漏れ、何ができてしまうのか
  • 深刻度「中」でも情シスが軽視すべきでない理由
  • 自社に該当するかの確認手順と、更新以外に打てる手

Gallagher Command Centre とは何者か

Gallagher Command Centre とは、入退室管理（アクセスコントロール）・侵入警報・外周（フェンス）警備を1つの画面で運用するための、施設セキュリティ管理プラットフォームです。ニュージーランドの Gallagher Group が提供しています。

導入するのは総務・ファシリティ部門や警備会社であることが多く、大学、データセンター、医療機関、官公庁、鉱山などで使われています。カードキーで社員証をかざして入室する、あの仕組みの「頭脳」にあたる部分だと考えてください。

ここが情シスにとって重要な点です。ベンダー公式の技術資料によれば、Command Centre の本体は Windows サーバー上で動くサービスであり、ログオンには Command Centre 独自の資格情報だけでなく Active Directory のユーザー名・パスワードも利用できます。モバイルアプリとの通信も社内ネットワーク経由（既定はデータ用ポート 8901、端末登録用ポート 8902）か、ベンダーのクラウドAPIゲートウェイ経由です。

つまり「物理セキュリティの機器だから総務の管轄」と思っていても、実体は社内のWindowsサーバーとADに繋がったIT資産です。IT資産台帳に載っていないだけで、情シスが守るべき範囲の中で動いています。

Command Centre Mobile では何ができるのか

スマートフォン用の Command Centre Mobile は、警備担当者が巡回中やデスクを離れているときに使うクライアントです。ベンダー資料に挙げられている主な機能は次のとおりです。

  • アラームの確認と対応
  • ドア、アクセスゾーン、アラームゾーン、フェンスゾーンの状態確認とオーバーライド（強制解錠・強制施錠など）
  • マクロのリモート実行
  • カードホルダー（入館者）の検索と詳細表示（顔写真、所属アクセスグループ、個人データ項目を含む）
  • カードホルダーのスポットチェック記録
  • モバイルアクセスリーダー（スマホをカードリーダーとして使う）
  • 避難時のモバイル点呼

要するに、このアプリのセッションを握るということは、建物のドアを操作し、誰がどこに入れるかを閲覧できるということです。

何が起きたのか

Gallagher は自社のセキュリティアドバイザリ（CVE-2025-47147）で、Android版およびiOS版の Command Centre Mobile クライアントに重要情報の平文保存（CWE-312）があることを公表しました。ログイン済みオペレーターのモバイル端末にアクセスできる攻撃者が、セッショントークンを抽出し、限られた時間そのアクセスを悪用できるという内容です。

項目 内容
CVE番号 CVE-2025-47147
脆弱性の種類 CWE-312（重要な情報の平文保存）
影響を受ける製品 Command Centre Mobile Client（Android／iOS）
影響を受けるバージョン 9.40.123 より前のすべて
修正版 9.40.123 以降
CVSS v3.1 基本値 5.7（中）／CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N
発見・報告 Gallagher 社内（ベンダー自身による発見）
悪用の確認 アドバイザリ公表時点で確認なし
回避策 提示なし（修正版への更新のみ）

CVSSベクタを読むと、攻撃元区分はローカル（AV:L）、攻撃条件の複雑さは高（AC:H）、必要な特権レベルも高（PR:H）です。ネットワーク越しに一斉に狙える種類の脆弱性ではありません。攻撃者はまず、ログイン済みのオペレーター端末にアクセスできる状態にたどり着く必要があります（アドバイザリの記載は「access to a logged-in Operator’s mobile device」で、端末を物理的に手にすることまでは条件とされていません。CVSS v3.1 で物理的な接触を要する場合の攻撃元区分は物理〈AV:P〉であり、本件のローカル〈AV:L〉とは区別されます）。

なぜ「設計意図とのズレ」が気になるのか

ここが今回いちばん考えさせられた点です。Gallagher が公開している技術資料「Command Centre Mobile App – Security」（Edition 7.1、2026年2月）には、アプリのデータ保存方針としてこう書かれています。

  • アプリはできる限りデータを保存しない設計で、安全な保管はサーバー側に任せる
  • 鍵素材（端末をサーバーに識別させるための証明書と鍵）はOSが提供するセキュアストレージ（多くの場合ハードウェア支援のあるもの）に格納する
  • ユーザー設定などの非機微データのみ、端末のファイルシステムに置く

つまり「守るべきものはセキュアストレージへ」という方針自体は最初から立っていました。にもかかわらず、セッショントークンがその保護の枠から外れていたのが今回の脆弱性です。方針が悪かったのではなく、「これは機微データに当たるか」という分類の網から1つこぼれ落ちた、という形です。

自社の内製アプリや委託開発でも、まったく同じ抜け方は起こり得ます。「パスワードは Keychain に入れています」で安心し、そのパスワードと同じ効力を持つトークンやキャッシュの置き場所を誰も確認していない、という状況は珍しくありません。認証情報そのものより、認証の結果として発行されるものの方が見落とされやすいのです。

AndroidとiOSで前提が違う点にも注意

同じ技術資料は、iOS がファイルシステムの内容を常に暗号化するのに対し、Android は端末側でその機能が有効な場合に暗号化することがある、と書き分けています。平文保存されたトークンが端末のストレージからどれだけ取り出しやすいかは、OSと端末の設定に左右されます。私物端末やMDM未管理の端末を業務に使っている場合、条件はさらに悪くなります。

深刻度「中」をどう扱うか

結論から言えば、スコアの数字ではなく「奪われた後に何ができるか」で優先度を決めるべき事例です。

CVSS 5.7 は、月次のパッチ対応リストの中では下位に沈む数字です。実際、攻撃条件は厳しく、悪用も確認されていません。それでも次の点は押さえておく価値があります。

  • 被害が物理空間に出る：情報が漏れて終わりではなく、ドアが開く可能性がある。サーバールームや書庫の扉が対象に含まれていれば、他のあらゆる論理的対策の前提が崩れます。
  • 入館者の個人データが見える：カードホルダー検索では顔写真や所属、個人データ項目まで表示されます。名簿としての価値があります。
  • 端末の紛失・盗難とセットで効いてくる：単独では使いにくい脆弱性ですが、「警備担当者がスマホを落とす」という、実際にそこそこ起きる事象と組み合わさると現実味が出ます。

なお、ベンダーはトークンの悪用可能期間を「限られた時間（limited duration）」とだけ表現しており、具体的に何時間有効なのかは公開されていません。ここは未確認情報として扱い、「短いから大丈夫」と読み替えないほうが安全です。

現場目線の課題

この手の脆弱性がやっかいなのは、技術的な難しさではなく持ち主が誰なのかがはっきりしないことだと感じています。

入退室管理システムは、多くの場合、建物の工事や移転のタイミングで総務・ファシリティ部門が施工会社経由で導入します。運用は警備会社に委託していることもあります。情シスは導入時の稟議にも保守契約にも登場しない。結果として、ベンダーがアドバイザリを出しても、それを読む人が社内に誰もいないという状態が起こります。

さらに、アプリを入れているのは警備担当者や施設管理の担当者であって、情シスが配布したものとは限りません。MDMの管理下にない端末に入っていれば、バージョンを一覧で確認する手段すらありません。「更新してください」と言うためには、まず誰が使っているのかを聞いて回るところから始めることになります。

正直なところ、情シスの人員でここまで手を伸ばすのは簡単ではありません。だからこそ、今回のようにJVNで日本語の情報が出たタイミングを、総務・ファシリティ部門に声をかけるきっかけとして使うのが現実的だと思います。すべてを引き取る必要はなく、「こういう情報が出ているので、保守ベンダーに確認してみてください」と橋渡しするだけでも、放置されるよりはるかにましです。

情シスはどうすべきか

自社が該当するかをどう確認するか

まず「使っているかどうか」を確定させます。次の順で確認するのが早道です。

  1. 入退室管理システムのメーカー名を確認する：総務・ファシリティ部門、または保守契約書を見る。カードリーダー本体や管理端末に貼られたロゴでも判別できます。
  2. Command Centre を使っている場合、モバイルアプリの利用者を洗い出す：警備担当者・施設管理者にヒアリングします。
  3. アプリのバージョンを確認する：9.40.123 より前であれば影響を受けます。App Store／Google Play から更新します。
  4. 管理側で登録端末を棚卸しする：Command Centre Client の「Device Management」画面に、接続を許可された端末が一覧表示されます。ベンダー資料によれば、紛失・侵害された端末はこの画面から削除することで以後の接続を遮断できます。登録コードを再発行して再登録を強制することも可能です。

4番目は今回の脆弱性への直接の対処ではありませんが、退職者や交代した担当者の端末が登録に残ったままになっていないかを見る良い機会です。トークンが平文で残る端末が「使われていないが登録は生きている」状態で放置されているのは、更新漏れよりたちが悪いかもしれません。

対策の考え方は公的指針に沿えばよい

今回のような「端末を失うと権限も失う」類のリスクは、目新しいものではありません。自前で長大なチェックリストを作る前に、公的機関の指針にあたるのが確実です。

  • IPA「中小企業の情報セキュリティ対策ガイドライン」…情報資産の洗い出しと管理責任者の明確化について、様式付きで解説されています。今回のような「所管が曖昧な資産」を棚卸しする際の出発点になります。
  • IPA「対策のしおり」…端末の紛失・盗難対策を利用者向けに説明する資料として使えます。警備担当者や施設管理者など、情シス以外の部署に説明するときに便利です。
  • IPA「セキュリティインシデント対応 机上演習教材」…「業務用スマホを紛失した」というシナリオは、部署をまたいだ連絡経路の弱さを可視化するのに向いています。

あわせて、地道な啓発も効きます。「スマホを落としたらすぐ申告する」「業務アプリが入った端末には画面ロックを必ずかける」といった基本が守られていれば、今回のようにローカルアクセスを前提とする脆弱性の実効性は大きく下がります。技術的な修正と違って即効性はありませんが、次に似た脆弱性が出たときにも効き続けます。

まとめ

  1. Gallagher Command Centre Mobile（9.40.123より前）にセッショントークンの平文保存の脆弱性（CVE-2025-47147）があります。修正版は 9.40.123 以降で、回避策は提示されていません。
  2. CVSS 5.7（中）ですが、奪われるのはドア操作と入館者情報の権限です。スコアではなく「奪われた後に何ができるか」で優先度を判断してください。
  3. 入退室管理システムは総務所管でも、実体はADに繋がったWindowsサーバーとモバイルアプリです。IT資産台帳への追加と、Device Management画面での登録端末の棚卸しを、この機会に進めることをおすすめします。

関連記事

出典

タイトルとURLをコピーしました