Facebookのゼロデイで任意のFacebookページを乗っ取れる脆弱性が発見された
概要
Facebookの「ページ」は企業や公人が顧客と接触する重要な窓口です。Business Managerは広告アカウントやページなどの資産を安全に共有・管理するための機能です。しかし、権限付与やオブジェクト参照の扱いが不適切だと、攻撃者が本来アクセスできないページを操作できる状態になります。
インドの研究者 Arun Sureshkumar 氏は、このBusiness Managerのリクエスト処理に存在する不適切な直接オブジェクト参照（IDOR）を突き、任意のFacebookページを乗っ取れるゼロデイ脆弱性を発見しました。彼は自身のブログで検証内容とPoC（実証コード／動画）を公開し、Facebookへ報告しました。
脆弱性の仕組み
IDOR（Insecure Direct Object References）とは、システム内のリソースを識別するパラメータ（ID）だけでアクセス制御を行っているため、本来参照できないリソースが参照可能になる脆弱性です。1行定義: 参照IDだけを信頼すると、他者のリソースにアクセスされる。
このケースでは、Business ManagerのAPIや管理用エンドポイントがリクエスト中のオブジェクトIDを十分に検証しなかったため、あるリクエストを細工することで別の組織のページへ紐づけを作成したり、管理権限を取得したりできました。攻撃は次の流れを取ります:
- 標的ページの識別子（page_id）を特定する
- Business Managerのリクエストを細工して、攻撃者のアセットにそのpage_idを紐づけさせる
- 紐づけが成功すると、Business Manager経由でページの操作権限を獲得する
PoCと報告経緯
Arun氏は詳細な検証手順と実証動画を公開しました（元記事内にPoC動画のリンク）。研究者は脆弱性をFacebookに報告し、Facebookのセキュリティチームは重大度を認めて一時的対処と恒久対応を実施しました。
影響範囲
- 大企業や政府関係のページ、著名人のページなど、あらゆるFacebookページが理論上攻撃対象になり得ます。
- 実際の悪用があれば、ページ投稿の改ざん、広告設定の悪用、フォロワーへの偽情報配信などの被害が発生します。
重要: 実際に広範な悪用が観測されたという公開情報はなく、今回の報告は研究者の検証とFacebookの対応に基づきます。
Facebookの対応と報奨金
Facebookは脆弱性報告を受け、まず当該エンドポイントを一時的に無効化しました。その後1週間以内に恒久的な修正を導入したと報告されています。研究者には16,000ドルのバグバウンティが支払われました。
管理者（ページ所有者）向けの即時対策
- 管理者権限を持つメンバーを見直す。不要な管理者や古い権限は速やかに削除する。
- Business Managerのアカウントとアセットの関連付けを定期的に監査する。第三者の予期しない関連付けがないか確認する。
- ログと変更履歴を有効にし、疑わしい操作を検出したら直ちに権限を再設定する。
- 2段階認証を管理者アカウントに強制する。
- Facebookからのセキュリティアラートや更新情報に注視する。
開発者とプラットフォーム設計者向け推奨
- オブジェクトレベルのアクセス制御を実装し、パラメータだけでアクセス許可を決定しない。
- サーバー側での認可チェックを各APIエンドポイントに必ず入れる。
- 可能なら参照トークンを短命化し、IDの直接公開を避ける。
- 権限変更の監査ログを細かく取り、自動検出ルールを作成する。
インシデント対応手順（簡易ランブック）
- 影響範囲の特定: どのページ／アカウントが関連しているかを確認する。
- 一時隔離: 該当のビジネスマネージャ連携やAPIキーを一時停止する。
- 権限のリセット: 全管理者の再認証と権限再付与を行う。
- ログ解析: 変更履歴と操作ログを調査し、不正アクセスの痕跡を確認する。
- 通知と開示: 該当する顧客や関係者に状況を通知する（法的要件に従う）。
- 恒久対策: 修正が適用されたことを確認し、再発防止策を導入する。
リスクマトリクス
| リスク | 発生確率 | 影響度 | 優先対策 |
|---|---|---|---|
| ページ乗っ取りによる投稿改ざん | 中 | 高 | 管理者監査、2FA強制 |
| 広告アカウントの不正利用 | 低〜中 | 高 | 支払い情報の分離、監視アラート |
| 個人情報漏えい | 低 | 中 | アクセスログと監査 |
いつこの手法が通用しないか（カウンター例）
- 強固なオブジェクトレベル認可が全てのAPIエンドポイントに実装されている環境では、IDOR攻撃は成立しません。
- APIトークンやIDが暗号化・非推測的に設計されている場合も困難になります。
- 権限付与が二段階で検証されるワークフロー（人の承認が入る）だと自動化された乗っ取りは防げます。
1行用語集
- IDOR: リクエスト内のオブジェクト識別子だけでアクセスを許可すると起きる脆弱性。
まとめ
今回の事例は、SNSプラットフォーム上での権限管理とオブジェクト参照の重要性を改めて示しました。管理者は権限の最小化と監査を徹底し、開発者はサーバー側の認可チェックを厳格化してください。Facebookの迅速な対応と報奨金支払いは研究者とプラットフォームの協業が有効に機能した良い例です。
重要: 公開情報に基づく要約です。実際の攻撃有無や影響範囲はFacebookの公式発表に従ってください。
