今回はも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を楽しむことが出来ます。
0 件のコメント:
コメントを投稿