高木浩光＠自宅の日記

■ EMOBILEのX-EM-UID、はじめから破綻

昨日の「SSL接続で得たX-JPhone-UIDを認証に使ってはいけない」から導かれる当然の帰結であるが、EMOBILEの X-EM-UID: についても同様に、SSL接続で得たものを認証に使ってはいけない。

「IDがSSLで使えない」ではなく「SSLで得たIDを使ってはならない」である点に注意。つまり、http:// のページしか提供していないつもりでも、実はWebサーバが https:// でもアクセスできるようになっていて、同じWebアプリケーションプログラムにリクエストが渡るようになっていたりすると、https:// 経由でなりすましログインされてしまうということ。

EMOBILEの「EMnet」はProxyサーバ wm.internal.emnet.ne.jp:8080 によって提供されており、これをProxyとしてSSL接続すると、Webサーバでのアクセス元は、「IPアドレス帯域 Webアクセス時（EMnet）技術情報 | イー・モバイル」に掲載のIPアドレスになる。そして、これはごく普通のend-to-endのSSL接続なのだから、そのリクエストの内容がいかなる内容であれ、それがProxyサーバで書き換えられることはない。

図1: EMnetのProxy経由でSSL接続し、偽の契約者固有IDを送信した*1ときの様子

私のEMnetの契約者固有IDは下3桁が「000」であるが、これを「001」にして送信してみたところ、図1のように、そのままWebサーバに到達した。

これは、イー・モバイル側ではどうともしようがない。これは仕様としか言いようがない。したがって、すべてのWebアプリケーション開発者は、SSL接続で受信した X-EM-UID: の値を認証に使ってはいけないことを知っておく必要がある。イー・モバイルはこの事実を周知するべきだろう。*2

加えて、（SSLを使わない）http:// の場合でも、X-EM-UID: は（多くのWebアプリケーションに対して）偽装できてしまう方法が存在することに気づいた。これは誰の脆弱性なのか。各Webアプリケーションの脆弱性と呼ぶにはあまりに酷な話だ。といって、（携帯電話端末の）ソフトウェア製品の脆弱性でもない。EMOBILEのProxyサーバ上で可能な処置はあり（それが完全な解決になるのかは疑問だが）、SoftBankではその処置をしているようなので、通報して修正を促すことにし、どんな方法でそれが可能なのかについては当面伏せておく。

それにしても、過去の失敗例がまったく共有されていない様子がうかがえる。EMOBILEが X-EM-UID: の送信を開始したのは、docomoがiモードIDの送信を開始したのとほぼ同時だった。ろくに技術検討をすることもなく始めてしまわざるをえないような、何らかの力がこのような結果をもたらしているのではないか。

■ 追記

上記の「http:// のページしか提供していないつもりでも、実はWebサーバが https:// でもアクセスできるようになっていて……」という事態は、次のようなケースでも起き得るので注意が必要。

たとえば、「イー・モバイル公式サイト」は、http://emobile.jp/ にあるが、ここは https:// でのアクセスを想定して作られていない。ここをあえて https:// でアクセスしてみると以下のように、サーバ証明書の都合でSSL接続がエラーになる。

図2: https:// でのアクセスを想定していないが、SSLでの接続が可能なサイトの例

これは、同社の別サイト store.emobile.jp とサーバが共用になっていて同じSSLサーバ証明書が置かれているためにこうなるのだが、こういうことはよくあることで、これ自体はとくに問題でない（想定されていないページなので、見なければよい話）。

このようなとき、通常はブラウザがアクセスをブロックするが、攻撃者はこの証明書エラーを無視してSSL接続することができる（Proxy経由であっても）のであるから、もし、このサーバ上に設置されたWebアプリケーションが、携帯電話の契約者固有ID（X-EM-UID: や X-JPhone-UID: など）を取得して認証に用いるようになっていた場合*3には、なりすましアクセスを許してしまう。