SS7の脆弱性で電話番号だけでFacebookが乗っ取られる仕組み
目次
- SS7の欠陥で電話番号だけでFacebookを乗っ取られる理由
- Facebook乗っ取りの手順（攻撃の流れ）
- SS7が未修正のまま残る理由
- どんな場合に攻撃が失敗するか
- 個人と組織が取るべき対策（実践チェックリスト）
- 事後対応とインシデント復旧の流れ
- 用語集と参考情報
SS7の欠陥で電話番号だけでFacebookを乗っ取られる理由
背景の要点（1行定義）: SS7は電話網のための信号プロトコルで、通話接続・SMS配送・番号変換などを扱います。設計は1970年代で、当時の前提（相互信頼）に基づくため、現在の脅威モデルには脆弱です。
SS7（Signalling System No.7）は世界の公衆交換電話網（PSTN）で使われる一連のプロトコルです。電話接続の確立・切断、SMS配送、番号ポータビリティ、課金などを担います。多くの携帯認証やワンタイムパスコードの配送がこのネットワークを経由します。SS7には設計上の「信頼されたネットワーク同士のやり取り」を前提とした弱点があり、悪意ある者や一部の国の機関がその経路を操作することで、特定番号宛てのSMSや通話を横取りできます。
重要: SS7の問題は、電話番号だけを手がかりにワンタイム認証（SMS/通話）を受け取る仕組みを攻撃できる点にあります。エンドツーエンド暗号化が効いているアプリでも、電話番号を使った認証ルートが弱点になる場合があります。
Facebook乗っ取りの手順（攻撃の流れ）
攻撃者がとる典型的な手順（簡潔）:
- SS7の経路操作でターゲットの番号宛のSMS/通話を第三者機器へ転送するか、あるいは一時的に受け取れるようにする。通信事業者の経路を偽装することで実施されます。
- Facebookログイン画面の「アカウントを忘れた場合」機能を使い、ターゲットの電話番号を入力してワンタイムパスコード（OTP）を要求する。
- OTPがSS7経路の操作により攻撃者側に届く。攻撃者はそのコードでアカウントへログインする。
- ログイン後、メールアドレスや二段階認証の設定を変更して被害者のアクセスを遮断する。
研究者が公開した実証は、このシンプルな流れで電話番号だけからアカウント制御を奪えることを示しています。攻撃の実装にはSS7経路にアクセスする技術と手順が必要です。
動画での詳細な実演（原著リンク）:
SS7が未修正のまま残る理由
技術面だけでなく政治・運用面の制約が影響します:
- 広域分散：SS7の修正は世界中の各通信事業者側で順次行う必要があり、グローバルな一斉更新が困難です。
- 政府の関与：一部の政府機関はこの脆弱性を監視・諜報目的で保持したいという圧力をかける場合があります。
- レガシー制約：旧式のネットワークや互換性の要求が、抜本的な改修を難しくします。
参考として、2014年の報道ではSS7を利用した追跡の成功率が約70%とする報告もありました（当時の調査報道の引用）。
重要: SS7の恒久的な修正は単一組織で完了するものではなく、通信事業者、機器ベンダー、規制当局、そしてプラットフォーム事業者の協調が必要です。
どんな場合に攻撃が失敗するか
攻撃が必ず成功するわけではありません。失敗するケースの例:
- ターゲットがSMSや通話ベースの認証を使っていない場合（例: 認証アプリやハードウェアトークンを使用）。
- 通信事業者側でSS7への検知・遮断対策を導入している場合。
- プラットフォーム側で電話番号ベースの回復フローに追加の検証（メールの二重確認、セッション履歴の検査、生体情報、ログイン通知など）を入れている場合。
- 多要素認証（MFA）でSMSではなく、アプリ/ハードウェアキーを使っている場合。
個人と組織が取るべき対策（実践チェックリスト）
個人向けチェックリスト:
- 電話番号だけの認証に依存しない。可能なら認証アプリ（Google Authenticator、Authyなど）やFIDO2準拠のセキュリティキーを使う。
- アカウントのログイン通知と不審なセッションの確認を有効にする。
- リカバリー用メールを最新かつ難読化しておく（常にアクセスできる個人メールを設定）。
- SIMスワップやSMS不達の疑いがある場合は通信事業者に即連絡する。
通信事業者向けチェックリスト:
- SS7の異常なシグナリングやルーティング変更を検知する仕組みを導入する。
- 異常検知時に該当番号のSMS/通話転送をブロックする緊急フローを整備する。
- 顧客向けにSIM交換や番号移行の厳格な認証プロセスを実施する。
プラットフォーム（例: Facebook）向けチェックリスト:
- 電話番号ベースの回復に追加の検証（デバイス履歴、地域、IP、既知のログイン挙動）を組み込む。
- SMSによるアカウント回復を補助的手段に限定し、認証アプリやセキュリティキーを推奨／必須化するオプションを提供する。
- 異常ログインの自動検知とアカウント保護（ロックや追加質問）を強化する。
事後対応とインシデント復旧の流れ
SOP（簡易インシデント復旧手順）:
- 侵害疑いの認知: ログイン通知、メール不達、アカウント設定変更の警告で発覚。
- まず行うこと: 可能ならば即座にアカウントのパスワード変更と二次認証の無効化チェック。セキュリティキーが登録済みならそれを使ってロック解除。
- 通信事業者に連絡: SIMスワップの痕跡やSS7経路の不審操作について報告し、該当セッションのブロックを依頼。
- プラットフォームに報告: Facebookなどに不正アクセスの報告を行い、復旧手順とログの保存を依頼する。
- 証拠保全: ログ、受信したOTP、通話履歴、通信事業者からの受領書などを保存する。
- フォローアップ: 侵害の影響範囲（連絡先、連携アプリ、保存データ）を確認し、必要に応じて連絡先へ注意喚起する。
ロール別優先アクション（短いチェック）:
- ユーザー: 認証アプリに切替、パスワード更新、金融アカウント監視。
- 通信事業者: 異常なシグナリング遮断、SIM変更の一時停止。
- プラットフォーム: アカウント凍結、ログ解析、被害報告窓口の案内。
セキュリティ強化の具体案（実用的対策）
- 認証の最優先は「認証アプリ／ハードウェアキー」。SMSは補助手段にする。
- 重要なアカウントには保護されたリカバリーパスワードや回復コードを紙で保管する。
- 通信事業者やプラットフォームには、ユーザーがMFA方式を選べるよう公表を求める（透明性の圧力）。
- セキュリティ企業や研究コミュニティと連携してSS7の異常検知ルールを共有する取り組みを支援する。
反例・この手法が向かない場面
- SMSを使わずに完全にオフラインの2段階認証（例: ハードウェアトークン）の場合、SS7経由のプロンプトは無効です。
- 小規模ローカルネットワークやクローズドなVoIPインフラではSS7が関与しない場合もあり、その場合はこの攻撃経路は使えません。
法的・プライバシー上の注意（簡潔）
- 国や管轄によってはSS7経由での監視やデータ取得が合法的に行われることがあります。個人情報保護やGDPRの観点からは、通信事業者とプラットフォーム双方の説明責任が重要です。
事実ボックス（要点まとめ）
- SS7: 電話網の信号プロトコル（1975年採用）。
- リスク: 電話番号だけでOTPを横取りされる可能性。
- 個人対策: 認証アプリ・セキュリティキーの利用を最優先。
- 組織対策: SS7異常検知、回復フローの追加検証。
用語集（1行定義）
- SS7: 電話網で使われるシグナリングプロトコルの集合。
- OTP: ワンタイムパスコード、一回限りの認証コード。
- SIMスワップ: 攻撃者が携帯番号を自分のSIMに移す詐取手法。
- MFA: 多要素認証、複数の認証要素を要求する手法。
終わりに（要約と次のアクション）
まとめ: SS7の脆弱性は電話番号ベースの認証を危険に晒します。今すぐできる最も効果的な対策は、SMS認証から認証アプリやハードウェアキーへの移行です。通信事業者とオンラインサービスは、ユーザーが安全に認証方式を選べる仕組みを整え、SS7の異常検知と緊急対応フローを確立する必要があります。
関連記事: This Hack Tool Uses SS7 Flaw to Trace Call, Location Of Every Single Mobile Phone
Also read: This Hack Tool Uses SS7 Flaw to Trace Call, Location Of Every Single Mobile Phone
