安全!? #PokemonGo のログインと OpenID Connect と PokeIV

こんにちは、富士榮です。

今回はもPokemon Goとアイデンティティのネタです。

前回、前々回とPokemon Goのログインの流れを見てきました。

　攻略！ #PokemonGo のログインと OpenID Connect
　http://idmlab.eidentity.jp/2016/07/pokemongo-openid-connect.html

　続！#PokemonGo のログインと OpenID Connect
　http://idmlab.eidentity.jp/2016/07/pokemongo-openid-connect_25.html


これまでのポストでは、主にGoogleでログインすることで、Googleサービスへの不要なアクセスができる状態になっていないか？という観点で調査をしてきましたので、Scopeパラメータを見る限りはメールアドレスくらいにしかアクセスしていないことが分かったので、ひとまず安心、という結論を出していました。

◆Pokemon Goのふりをするアプリの登場

しかし、逆にPokemon Go側から見ると、Pokemon GoのサービスへのアクセスはGoogleから取得したid_tokenを持っていることだけを条件にしているので、何とかしてPokemon Goアプリの”ふり”をしてid_tokenを取得してしまえば、あとは何とでもなる、という状態でもありました。

最初のポストを書く時に、OpenID ConnectでGoogleからid_tokenを取得する流れを見ていると、public clientにもかかわらずimplicitではなくcode flowを使っており、codeやclient_secretが丸見えな点にものすごく違和感を感じて、サードパーティ・クライアントでも作るつもりなのかな？？？など、色々と議論をしていたんですが、やはり出てきてしまいました。

　PokeIV : 個体値チェックサイト
　　https://pokeiv.net/

Gigazineでも紹介されていますが、Pokemon Goで使っているアカウントでGoogleにログオンし、codeを取得しPokeIVに貼り付けることでPokemon Goへアクセスして個体情報を取得するという仕組みなのですが、内部的には、Pokemon Goのclient_idとclient_secretを使ってPokemon Goのサービスへアクセスできるid_tokenを取得しているようです。

以下の同意画面を見るとクライアントがPokemon Goになっており、クエリパラメータの中のclient_idを見るとiOS版のPokemon Goで使っているclient_idと同じものが使われています。

Googleに登録されているredirect_uriがurn:ietf:wg:oauth:2.0:oobなので、redirect_uriにクエリでcodeを渡す代わりに、取得したcodeを手動（コピペ）で渡し、tokenエンドポイントを叩く、という実装はしていますが、色々とタチが悪いですね。

最近OpenID Foundation Japanの事務局長になったnov氏がoauth.jpで書いているようにcode置き換えもあるでしょうし、そもそもclient_secretが漏れている段階で今回のPokeIVのように単純にPokemon Goのふりをしてデータを取得するようなクライアントの開発が出来てしまいます。

今は集めたポケモンの情報をとってくるだけ、ということになっているので良いんでしょうが、例えば、今後Pokemon Goからユーザの位置情報の履歴を取得できたりすると、一気にホラーな話になってしまいますよね。。。

◆Pokemon Goはどうすれば良かったのか？

そもそも論、HTTPSを使っているにも関わらずFiddlerでトレースできてしまう段階でCertificate Pinningなどの対策が出来ていない、という話もありますが、ネイティブアプリ（パブリック・クライアント）として実装している段階で逆コンパイルや解析をされる前提でOpenID ConnectやOAuthの設計をすべきです。具体的にはimplicit flowを使ったり、Google Sign-In SDK for iOSを使って、client_secretを使わない方法で実装するのが一番簡単な対策だと思います。

簡単にまとめるとこんな感じかと。（他にもあるとは思いますが）

脅威	対策
通信トレースによるcodeやclient_secretの漏えい	Certificate Pinning
バイナリ解析によるclient_secretの漏えい	難読化（限界あり）
Proxyサーバの通信ログよりcodeの漏えい	PKCEの利用（Googleは既にPKCE対応してます）
client_secretの漏えいによるクライアントなりすまし	client_secretを使わないフローの採用（implicit/Google Sign-In SDKの利用）

◆現バージョンのPokemon Goはどうなっているのか？

最近バージョンが上がったクライアントはどうなっているのか？を見てみました。

Proxyを挟んだ状態でアクセスするURLなどを見て推測すると、Google Sign-In SDKを使っているみたいです。また間にfiddlerを挟んだ構成だとログオンに成功しないので、MITMもチェックもしているみたいです。（うまくトレースできなかったので深追いはしていませんが）

◆PokeIVなどのアプリを使ってしまった場合の対策

しかし、一度PokeIVなどのアプリを使ってしまった場合、id_tokenやrefresh_tokenがアプリ側に保管されている可能性もあり、勝手にPokemon Goへ不正にアクセスされてしまう可能性もゼロではありません。

このような場合は、Googleアカウントのページからアプリケーションからのアクセスを一旦取り消して、正規のPokemon Goで再度サインインをしましょう。

アクセスを許可しているアプリケーション一覧が以下のURLで確認できるので、Pokemon Goを探して、一旦削除してしまいましょう。

https://security.google.com/settings/security/permissions

Pokemon Goを起動すると再度Googleアカウントへのアクセス許可のページが表示されますので、ここで改めて許可をすることでid_tokenが取得できるので引き続きPokemon Goを楽しむことが出来ます。