"なんちゃら iOS SDK" でありそうな被害例

Author: Nov Matake
Date:

昨日の続き。「ソーシャルゲームなんて3000万人の特殊な人しかやってない」という意見もあるようなので、今日は iOS アプリ版。

登場人物

  • iOS SDK 出してるプラットフォーム
  • iOS SDK と連携するプラットフォームの公式 iOS アプリ
  • プラットフォーム上で “まっとうな” アプリを運営してる攻撃者
  • 攻撃者が自作した攻撃用アプリ
  • iOS SDK 使って開発された被害アプリ
  • あいかわらず無邪気な被害ユーザ

前提

プラットフォームが提供する iOS SDK は、

  1. プラットフォームが指定するカスタムスキーマ (ex. “xyz-connect://”) で始まる URI にアクセスすることで
  2. プラットフォーム公式 iOS アプリに access token 取得のフローを delegate し
  3. 公式アプリが被害アプリの指定するカスタムスキーマ (ex. “foobar-rowial://”) で始まる URI にユーザーを戻すことで、アプリに access token を返す。

被害アプリは、

  1. iOS SDK から受け取った access token を自身のバックエンドサーバに送り
  2. バックエンドサーバはプラットフォームが提供する Profile API (GET /me とか) にアクセスして
  3. レスポンスに含まれる user_id をもとにユーザを認証する。

シナリオ

  1. 攻撃者はプラットフォームが指定するのと同じカスタムスキーマで delegate を受け取る攻撃用アプリを自作する (なり誰かから買うなり..)
  2. 攻撃者は自分の iPhone/iPad に攻撃用アプリをインストール (xcode 経由だと、Apple の承認必要ないんですよね、たしか？)
  3. 攻撃者は自分が運営する “まっとうな” なアプリの DB から被害ユーザのアクセストークンを取って来て攻撃用アプリに埋め込む
  4. 攻撃者は被害アプリを起動して “なんちゃら ID でログイン” とかいうボタンを押す
  5. 被害アプリはプラットフォーム攻撃者が自作した攻撃用アプリに delegate 開始
  6. 攻撃用アプリは被害ユーザのアクセストークンを被害アプリに返す
  7. 攻撃者は被害ユーザのアカウントで被害アプリを使う

対策方法

プラットフォームの iOS SDK は “response_type=token code” に対応する。

被害アプリは、”response_type=token code” を使い、サーバーサイドへは access token ではなく authorization code を送る。(そしてサーバーサイドでは client authentication して code を token と交換する)

ただいかんせんプラットフォーム側の iOS SDK が対応してくれなかったり、既にアプリを公開していて古いバージョンもサポートしなければならなかったりすることもあるので、そういう場合はバックエンドサーバーで対応。

被害アプリのバックエンドサーバは、どうしてもアプリ側から access token を受け取らざるを得ないのであれば、昨日の記事と同様に access token 発行先アプリが自身であることを確認する。

追記

いくつか気になるtweetがあったので、載せときます。