<前の日記(2010年04月27日) 次の日記(2010年04月29日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 3010   昨日: 4374

2010年04月28日

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には、なりすましアクセスを許してしまう。

*1 自分の管理下にあるサーバに対して送信。

*2 イー・モバイルは、この問題を解決しようとして、secure.softbank.ne.jp と同様の策をとろうとするかもしれないが、それは、より悪い事態に陥る(しかも、SoftBankのケースよりもさらに悪い事態になる)ので、その道を選んではいけない。

*3 図1で例に挙げた emobile.jp はそのような処理をしていないようだが。

検索

<前の日記(2010年04月27日) 次の日記(2010年04月29日)> 最新 編集

最近のタイトル

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
<前の日記(2010年04月27日) 次の日記(2010年04月29日)> 最新 編集