楽天銀行アプリがUDIDを使用していた件 - UDID使用の是非とSSL利用目的の変遷

ROCA @rocaz

セキュリティクラスタな皆さんに質問。ログイン時のユーザーIDの入力省略のためユーザーIDだけをCookieやランダム生成文字列などではなくて携帯端末の固定的なUDIDなどに紐付けてサーバーサイドで保持することは妥当？僕はよりよい方法があるのに採用しないなら脆弱という立場なんですが

徳丸 浩 @ockeghem

@rocaz 好ましくはないが、脆弱とまではいえない、くらいの判定ですかね

徳丸 浩 @ockeghem

脆弱性診断やっていると、お客様の中には、高危険度しか対処しない企業から、低危険度でも対処する企業があるので、その企業のセキュリティの取り組みの指標になるかもしれない。「弊社は低危険度の脆弱性にも対処します」、とか…まぁ、危険度判定の基準がベンダーによってまちまちなんですけどね

ちーきく 下北沢ときどき神楽坂 @bywaysideway

@rocaz UDIDのなりすましリスクをどう扱うか次第かと。http://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIDevice_Class/Reference/UIDevice.html

ROCA @rocaz

@ockeghem そうなんですよね。脆弱と言い切ると語弊があるかも。ただ、単に紐付けるのならランダムな文字列生成するだけでいい訳で、決して秘密情報とは言えないUDIDを用いる理由もない、という微妙な感じではあるんですよねぇ

徳丸 浩 @ockeghem

@rocaz 同感です

ROCA @rocaz

@bywaysideway 基本的には他者のUDIDが分かればなりすましが出来ると思います。ただその結果手に入れられるのはログインに用いるメールアドレスだったりするところが判定の悩みどころです(認証には更にパスワードは必要)

ちーきく 下北沢ときどき神楽坂 @bywaysideway

@rocaz 攻撃側の立場なら、UDID（や紐付けられているメアド）とは別に、パスワードを盗みとるアダルト偽サイトをつくって、合わせ技でなりすますとか。ここは考え出すとキリがないので、リスクとメリットのバランスではないかと。

ROCA @rocaz

ブログ書きました: 楽天銀行アプリのセキュリティについて http://goo.gl/fb/wbBP7

Hiromitsu Takagi @HiromitsuTakagi

@rocaz 同アプリのヘルプの「ライセンス情報」に「SFHFKeychainUtils」とありますよ。それを使って何かを /private/var/mobile/Application/… 以外の場所に保管しているのでは。> 「そちらで確認された点は事実とは異なる」

ROCA @rocaz

@HiromitsuTakagi App以下へ置いていない可能性はあり得ると思っていました。但し再インストールで戻るのでだとしても恐らくUDIDだけではないのでしょう。多分guid付近と踏んでいます。あるいはそれらのハッシュなどで紐付けかも。キーチェーン調べられるか試してみます

Hiromitsu Takagi @HiromitsuTakagi

@rocaz 実験結果からの推論がいろいろと論理的に変ですよ。アンインストールしたからといってkeychainのアイテムも同時に消えるとは限りませんし。実験手順も系統立てられてなくて良くない。正しい手順：(1)適当に試してあたりをつける。(2)どうなっているか仮説を立てる…

Hiromitsu Takagi @HiromitsuTakagi

@rocaz …(3)仮説を否定するテスト計画を立てて実施、否定されないことを確認 (4)その仮説以外で同じ結果になる別の仮説の存在を検討。以下繰り返し。

ROCA @rocaz

@HiromitsuTakagi ですね。手慣れてないですね。(3)-(4)にかけてが方法が見つけられなかったこともあり手薄なのは認識していました。嘘をまき散らすだけになると最低なので、たとえ間違っていてもきちんと公表し批判は批判で受けるつもりです

ROCA @rocaz

@HiromitsuTakagi ビンゴでした。REGIST_KEYとUDIDの文字が見えますね。それぞれBLOB HEX換算で96Byteと80Byte。問題はここからのテストですね

ROCA @rocaz

うーん、KeychainだとやっぱりiOSが暗号化するから、分かるのはアプリがデータをInsert/Deleteするタイミングと大体のデータサイズぐらいだなぁ。ちょっと厳しい感じ

ROCA @rocaz

UDIDといいつつKeychain内の暗号化後サイズが80バイト、つまりブロック暗号として5ブロックを占めるのでやはりUDID以外の情報も付加されていそうではある

ROCA @rocaz

ただシナリオとして先方の主張でも矛盾無く説明できることは分かった。但し同時にだからこそUDIDを送信していないまたは間接的にも使っていないこともまだ否定できるところまで至っていない

ROCA @rocaz

ああそうか、楽天銀行アプリは端末確認をしていないのではないか。フロー上結果として他の端末が入り込めないようにしているだけか。であるなら端末情報を送信する必要性も無くなるけど、そうするとUDID他のチェックの意味が不明瞭・・

ROCA @rocaz

楽天銀行アプリのプロトコル解析ようやく着手。で結論から言うと、クイックログイン時に思いっきりUDID送ってるじゃ無いかよ、どういうことだ。結局嘘だったのか。SSLで守られてるから分かりっこないと踏んでたのかも知れないけど、せっかくだからこれ全プロトコル調べてあげて公表しようかな

ROCA @rocaz

SSLでも頑張れば何とでも解析できるんだな。いい勉強になった。隠し通せるものなど何もないと言うことだ

ROCA @rocaz

まる半日かかりっきりだった。疲れた･･。後はのんびりやります。。

ROCA @rocaz

UDIDを送っているタイミングは2回。初期のログイン時と、クイックログイン時には毎回送る

ROCA @rocaz

クイックログインはクイックログイン設定時にサーバーで発行した固有トークンあたりとパスを送っているのかと思ったらそうじゃなかった。支店番号と口座番号、パスにUDIDを送っている。つまりどうもアプリから一方的に送られた支店・口座・パスワードをそのまま信じて認証してるように見えるのだ

ROCA @rocaz

クイックログインの箇所抜粋 VER=1_0_2&CMD=SMP_CMD_0005&CID=SMP_CID_0005&TKN=1e499034eaa3ac81231ec6a4accfcd35&BCHNO=支店番号&ACNO=口座番号&PASSWD=XXXX&UDID=f1…25