GMO不正アクセス、サーバを止めてもパスワードを変えても…被害が続く“ある抜け穴”(2/4)

パスワードを変えても…被害が続く“ある抜け穴”

　まず、技術的に押さえておきたい。侵害されたサーバを止めれば、そのサーバを通じた新たな情報窃取は抑えられる。問題はその先だ。すでに盗まれた情報が使われる場所は止まらない。それは、FX会社や証券会社にある取引口座だ。

　盗まれた認証情報（IDやパスワードなど、本人であることを示す情報）が有効なままなら、攻撃者は停止したサーバと無関係に、別の端末から口座へ入れてしまう。GMOがパスワードの変更を本サービスのサーバ以外の端末で行うよう求めたのは、そのためだ（注6）。


　もう1つ、見落とされがちなのが、認証情報とセッションの違いだ。ビルにたとえると分かりやすい。パスワードは入り口の鍵であり、セッションやトークンは、その鍵で入った人に渡される入館証だ。入館証さえ持っていれば、鍵を使わなくても館内を歩ける。

　ここで入り口の鍵を付け替えても、発行済みの入館証が有効なままなら、すでに館内にいる人は締め出されない。パスワードを変えても、サービスの実装によっては発行済みの接続が残る、というわけだ。

　GMOも、取引先のサーバの仕様によってはパスワード変更後も既存の接続が残り得るとして、10月23日の第3報で全セッションの切断を求めた（注7）。ただし、本件で既存の接続が実際に悪用されたかどうかは公表されておらず、ここで述べるのは一般的な仕組みだ。





　つまり、止めるべき層は少なくとも4つある。保存された認証情報、発行済みの接続、取引口座そのもの、そして利用者の端末だ。

（図表3枚目：盗まれた情報の「層」ごとに、止める手段は異なる）

情報の層	残るもの	止める手段
保存された認証情報	ID・パスワードは、侵害環境の外でも再利用される	別の端末で変更する。使い回し先も変更する
発行済みの接続	セッション・トークン・APIキー（プログラムが接続に使う鍵）は、パスワード変更後も有効な場合がある	全セッションを切断し、トークンやキーを失効・再発行する
取引口座そのもの	サーバを止めても、口座では不正取引が続き得る	取引・出金を一時制限し、取引履歴を確認し、二要素認証を設定する
接続元の端末	感染していれば、再設定後に認証情報が再び盗まれる	フルスキャンを行い、別の端末で再設定する

　GMOは24日、取引所や証券会社にも全セッションの強制切断を要請した（注8）。


　問われるのは、外部基盤の侵害を知った時点で、該当する顧客の認証情報の失効、全セッションの切断、取引・出金の一時制限までを、利用者任せにせず金融会社が主導して実行できるか、ということだ。

　FinTech Journalによれば、金融庁も22日付でFX事業者に緊急通知を出し、パスワード変更の促しと注意喚起に加え、普段と異なるIPアドレスからの接続を即座に検知できる監視体制の強化を求めている（注9）。

パスキーなら安全？ 岩井コスモ証券の事案が示す“限界”

　パスキーは、確かに強力な対策だ。パスワードの代わりに暗号の鍵でログインする仕組みで、サービス側には公開鍵しか預けない。鍵は登録したサイトのドメインにもひも付くので、偽サイトに誘導されても使えない、という寸法だ。入力すれば偽サイトを通じて攻撃者に渡ってしまうパスワードやSMSのコードとは、この点が決定的に違う（注10）。


（図表4枚目：偽サイトに誘導されたら？ パスワード・コードとパスキーの違い（パスキーの標準化団体FIDOアライアンスの説明に基づく図解））

手順	パスワード、SMS・認証アプリのコード	パスキー
1	利用者が偽サイト（例：example-fx.test）に誘導される	利用者が偽サイト（例：example-fx.test）に誘導される
2	利用者がID・パスワードと、届いたコードを入力する	ブラウザが、鍵の登録先ドメイン（example-fx.com）と、開いているサイトが一致するか確認する
3	偽サイトが入力内容を正規サイトへ即座に中継する	一致しないため、鍵による署名は行われない
4	攻撃者が、なりすましてログインに成功する	攻撃者は、ログインに必要な情報を得られない

　しかし、パスキーを入れれば安全になる、と考えるのは早計だ。鍵そのものではなく、回復手続きや同期アカウント、端末、ログイン後のセッションといった周辺が突かれる。

（図表5枚目：パスワード・SMS・パスキー、どこが違う？ 認証方式の比較（一般的な傾向を示す筆者の整理））

方式	フィッシング耐性	サービス側が漏えいした場合	主な弱点	運用負荷	向く場面
パスワードのみ	弱い。入力させられれば渡る	使い回しや、漏えいしたハッシュ（パスワードを変換した値）の解析などで悪用され得る	使い回し、フィッシング、情報窃取マルウェア	低い	単独利用は避ける
SMSのコード	弱い。偽サイトで中継される	コード自体は漏れないが、回線側の危険が残る	リアルタイム型フィッシング、SIMの乗っ取り	低い	補助・暫定
認証アプリのコード	弱い。入力させられれば中継される	共有の秘密がサービス側に保管される	リアルタイム型フィッシング	低～中	パスキー未対応時の次善策
プッシュ承認	弱い～中。番号照合で軽減	実装による	承認の連打による誤承認	低い	補助
パスキー（同期型）	強い。登録ドメインでのみ使用可能	認証用に保管するのは公開鍵で、秘密鍵は漏れない	同期アカウント、回復手続き、弱いフォールバック（代替のログイン方式）、端末侵害	低い	一般利用者ログイン
パスキー（デバイス固定・セキュリティキー）	強い	認証用に保管するのは公開鍵で、秘密鍵は漏れない	紛失、複数登録の管理・配布費用	中～高	管理者、出金などの重要操作

　そして今回、考えておきたいのが、人が介在しない自動接続だ。人のログインをパスキーで強化しても、自動売買に使う認証情報をサーバに保存する問題まで解消するわけではない。
（図表6枚目：パスキーも万能ではない…主なリスクと対策）

リスク	起こり方	主な対策
回復手続き・同期アカウントの悪用	同期基盤（iCloudやGoogleなどのアカウント）の乗っ取りや、本人確認の緩い回復手続きを突き、攻撃者が自分の端末に鍵を復元する	回復を登録時と同等の本人確認で設計する。複数の鍵を事前に登録する。重要操作ではデバイス固定の鍵を使う
認証のダウングレード	中継サイトが「非対応ブラウザ」を装い、サービスが許すSMSなどの弱い方式へ利用者を誘導する	弱いフォールバックを段階的に廃止する。対応するOS・ブラウザで強い方式を提供する
端末・ブラウザの侵害	マルウェアや悪意ある拡張機能が、ログイン後のセッションを盗む、認証処理に割り込む	拡張機能を許可リストで管理する。セッションを端末にひも付ける。端末の状態が変われば再認証する
登録時・運用の穴	登録時の本人確認が弱いと、攻撃者が本人になりすまして鍵を登録できる。紛失・機種変更時の対応も弱点になる	登録時に強い本人確認を行う。登録・利用状況を監視する。利用者に手順を周知する
無人の自動接続	自動売買のように人が介在しない接続は、人の指紋や顔を使えず、ログイン向けのパスキー導入だけでは守れない（筆者の整理）	取引専用・出金不可の認証情報、接続元IPの制限、短寿命のトークン、出金時の追加認証を併用する

　岩井コスモ証券の事案も参考になるだろう。同社は10月21日、不正取引は「パスキー認証が突破されたものではない」と説明した。同社によれば、委託先の取引システムへの総当たり攻撃で7口座に意図しない注文が出て、5口座で約定したが、取引は原状回復されている（注11）。玄関の鍵をいくら強くしても、その外側が破られれば取引は実行されてしまう可能性があるわけだ。


　実務上の答えは、場面ごとに役割を分けることだと筆者は考える。ログインにはパスキー、自動化の接続には取引専用で出金できない認証情報と接続元IPの制限、出金や出金先の変更には追加認証を置く。仮に1つが破られても、被害が広がりにくい設計にしておくことだ。

（図表7枚目：認証は「入り口」だけでは足りない──4つの層と、今回の事案で問われた層）

層	主な対策	今回の事案での位置付け
（1）入り口：ログイン	パスキーなど、フィッシング耐性のある多要素認証。弱いフォールバックの縮小。回復手続きの厳格化	侵入経路は未公表。今回の主因かどうかは不明
（2）接続の維持：セッション・トークン	全セッションの切断、トークン・APIキーの失効、短寿命のトークン、セッションの端末へのひも付け	問われた層。GMOが全セッションの切断を要請
（3）操作：取引・出金	取引専用・出金不可の認証情報、接続元IPの制限、出金先の事前登録、出金時の追加認証	問われた層。サーバ内の認証情報が取得された可能性（GMO）
（4）検知と遮断：監視・連携	異常取引の検知、出金の保留、金融会社・クラウド事業者・業界団体での情報共有	問われた層。FX会社のOANDA Japanが出金を保留。他社は個別に注意喚起

「安全に復旧した」と言えるのはいつ？ 再開前の確認8項目

　GMOは、侵害された現行の基盤ではサービスを再開せず、別の基盤への移行を6カ月間無償で案内する方針を示した（注8）。では、同様の侵害を受けた場合、復旧を宣言する前に何を確かめるべきか。

（図表8枚目：「安全に復旧した」と言う前の確認項目）

項目	確認する内容	証跡・判断材料
侵入経路	経路を特定して閉塞する。未特定のままの再開は再侵害を招くおそれがある	原因調査報告、閉塞後の再現テスト
残存物	バックドア、追加アカウント、スケジュールされたタスク、設定の改変の有無。攻撃者は裏口を仕込んだと主張しているが未検証	全資産のスキャン、構成の差分確認
特権の認証情報	管理者アカウント、鍵、トークン、証明書を、侵害前に発行されたものも含めて総入れ替えする	更新記録、旧認証情報の失効確認
流出した認証情報	利用者側と金融会社側の双方で再設定が完了したか。使い回し先も対象に含める	再設定率、残存セッション数
ログと証拠	再構築前にイメージを取得し、保存期間を延長し、時刻をそろえて金融会社側のログと突き合わせる	保全済みログの一覧、改ざん防止措置
バックアップイメージ	復元前にスキャンして確認し、不正プログラムを持ち込まない	復元前のスキャン結果
横展開	同じ構成の他サービスを優先点検する	点検の範囲と結果
接続元の端末	利用者の端末が汚染されたままだと、再開後に認証情報が再び盗まれる	端末スキャンの実施状況（予防的対応

　このうち、侵入経路、残存物、特権の認証情報、流出した認証情報の4項目は必須だ。残る4項目も、再発防止を考えると、実施を勧めたい。

　復旧の判断では「安全を断定しないこと」が極めて重要になる。確認できた範囲と未確認の範囲を明示し、限定的な再開、監視強化期間、第三者による検証といった段階的な措置を組み合わせるのが現実的だろう。では、こうした事態が起きたとき、責任は誰が負うのか。そこには、技術だけでは片付かない問題がある。 【次ページ】誰が責任を負う？ GMO・金融会社・利用者の“継ぎ目”