高木浩光＠自宅の日記

2010年04月27日

■ まだまだ他でも破綻しているケータイID認証

前回の補足。以下は、私が気づいたことではなく、2009年夏に「かんたんログインが危うい」との話題で持ち切りだったときに、既に公に語られていたことである。

SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ, Perlとかmemoとか日記とか。, 2009年8月1日

特にUserAgentからIMEI番号を正規表現などで抜き取ってそれだけを利用している場合は、この方法を使えば偽装可能。uidの方を使うようにした方がいいかも。
モバイル用GWのIPアドレスを気にしてた時代もあったなぁ, コメント欄#1, 匿名の臆病者, 2009年8月6日

透過プロクシという仕組みはご存じない? あ、ということは少なくともhttpsにx-jphone-uidが乗っていたら擬装の虞か。(端末はuidを吐かないので)

しかし、携帯電話会社がこの仕様について何ら公表していないせいで、「かんたんログイン」実装者らに周知されていないのではないかと危惧される。事実を検証の上、少なくとも避けなければならないことを以下に書いておく。

端末シリアル番号を認証に使ってはいけない

X-JPhone-UID: などの、キャリアのゲートウェイ（やProxyサーバ）で付与される契約者固有IDは、偽IDが送信されても、ゲートウェイが本物のIDに差し替えてサーバに渡す（オーバーライドする）ようになっているらしいが、User-Agent: 内に記載された端末シリアル番号（IMEI番号）のオーバーライドはなされていない。

図1: 左: 偽の端末シリアル番号と偽の契約者固有IDを送信した*1ときの様子
右: 使用した端末のIMEI番号

図1のように、私の端末のIMEI番号は末尾3桁が「357」であるところ、最後を「8」に変えた「偽の」端末シリアル番号を User-Agent: に載せて送信したところ、Webサーバにその文字列がそのまま届いている。

（一方、私のSoftBankの契約者固有IDは末尾3文字が「Wc0」であるところ、「Wc1」に変えた「偽の」契約者固有IDを X-JPhone-UID: に載せて送信したところ、これは「Wc0」にオーバーライドされてサーバに届いている。）

そして、アクセス元のIPアドレスは、「Yahoo!ケータイにて利用するIPアドレス帯域」のものになっている。

したがって、端末シリアル番号を認証に使っているとなりすましログインされてしまう。端末シリアル番号を認証に使ってはいけない。

このように端末シリアル番号をオーバーライドしないのは、仕様なのだろう。なぜなら、X-JPhone-UID: はヘッダの値フィールド全体が値なので仕様が暗黙的に自明だが、User-Agent: の途中に埋め込まれた端末シリアル番号は、どの部分が当該IDなのかその仕様が明確に定義されていない。感覚的には「4つ目の『/』の次の文字から次の空白まで」なのだろうけども、仕様が明確に定義されなかったせいで、Webアプリケーション側の実装は、「『SN』で始まり次の空白の前までの文字列」など、それぞれ思い思いのテキトーなやりかたがされているだろう。そのため、いくら、偽の端末シリアル番号らしき文字列をオーバーライドしようとしても、すべてのWebアプリ実装に対応できるようなパターンマッチが不可能になっている。

ネットの評判を検索して見てまわると、比較的最近に発売されたSoftBankの機種では、この端末シリアル番号の送信がデフォルトでOFFに設定されているらしい。そのため「かんたんログイン」が動かないということで、この設定をONに変更するように促しているサイトがあるが、危険なので、端末シリアル番号での「かんたんログイン」をやめるべきだ。

デフォルトでOFFに変更したということは、ソフトバンクモバイルは、この問題を知っていて、使うのをやめさせる方向でデフォルトOFFにしたのではないのか。

どうしてソフトバンクモバイルはこの事実を周知しないのか。いまだに「ユーザエージェントについて」のページに「端末シリアル番号」の使い方が掲載されている。無責任極まりない。

図2: 端末シリアル番号の使い方が解説されている様子

SSL接続で得たX-JPhone-UIDを認証に使ってはいけない

sbwapproxy.softbank.ne.jp:8080 をProxyサーバとして、SSL接続で（直接の https:// アクセスで）WebサーバにHTTPリクエストを送信した場合、end-to-endのSSL接続なのだから、そのリクエストの内容がいかなる内容であれ、それがゲートウェイ（Proxyサーバ）で書き換えられることはない。

図3: SSL接続で偽の契約者固有IDを送信した*2ときの様子

図3のように、私のSoftBankの契約者固有IDは末尾3文字が「Wc0」であるところ、それを「Wc1」に変えた「偽の」契約者固有IDを X-JPhone-UID: に載せて送信したところ、Webサーバにその文字列がそのまま届いている。

そして、アクセス元のIPアドレスは、「Yahoo!ケータイにて利用するIPアドレス帯域」のものになっている。

したがって、SSL接続で受信した X-JPhone-UID: の値を認証に使っていると、なりすましログインされてしまう。SSL接続で受信した X-JPhone-UID: の値を認証に使ってはいけない。

たとえそのつもりがなくても、結果的にそうなっている場合がありそうなので注意が必要。つまり、http:// のページしか提供していないつもりで、所定のIPアドレスから送られてきた X-JPhone-UID: の値を認証に使用しているときに、管理者の与り知らぬところで実はWebサーバが https:// でもアクセスできるようになっていて、同じWebアプリケーションプログラムにリクエストが渡るようになっている場合、https:// 経由でなりすましログインされてしまう。

これも仕様だろう。キャリア側ではどうしようもない。なぜ携帯電話会社はこの事実を周知しないのか。無責任極まりない。

同様に、ゲートウェイ付与型の契約者固有IDを提供しているdocomoの場合はどうなのか。これは私から言うことではない。NTTドコモが周知することだろう。

先日のサイボウズOfficeの件のように、パッケージ製品として「かんたんログイン」機能を提供する場合、これに該当するアクセスについて、https:// では動かないようにする必要がある。それを、製品購入者の責任で安全に設定せよというのはあまりにも無理な話すぎる。