水無月ばけらのえび日記

bakera.jp > 水無月ばけらのえび日記 > どこかで聞いたようなiPad情報流出

どこかで聞いたようなiPad情報流出

2010年6月10日(木曜日)

どこかで聞いたようなiPad情報流出

公開: 2010年6月12日22時10分頃

アップル最悪のセキュリティブリーチ。iPad所有者11万4000人分のデータ流出 (www.gizmodo.jp)」というお話が。

HTTPリクエストの一部としてICC-IDを提供する際、このスクリプトはそれに付属するメールアドレスも返してくるんですね。

(~中略~)

AT&Tのサーバーから応答してもらう部分は、単にウェブリクエスト内にiPad風の「User agent」のヘッダを入れて送るだけで良かったそうですよ。 この手のヘッダはユーザーのサイトのブラウザ種別を特定するものです。

ICCID (Integrated Circuit Card ID) というのは、SIMカードについている固有のIDです。WikipediaのSIMカード (ja.wikipedia.org)の項を見ると、ICCIDは19桁の番号のようですが、国や発行者を示す部分が7桁、チェックディジットが1桁あるので、残り11桁でユーザを識別していることになります。「iPad:シリアル番号、UDID、IMEI、ICCID、およびデータ通信契約番号を確認する (support.apple.com)」を見ると、iPadの場合、「情報」画面でICCIDの値を確認できるようです。

そして、AT&TのサービスにこのICCIDを送ると、対応するメールアドレスを返してくれる仕組みがあったと。この機能はiPad用のもので、通常のPCなどからはアクセスできないようにしていた……つもりが、単にUser-Agentを見て蹴っているだけだったので、User-Agentの偽装であっさり貫通、任意のICCIDを送り放題だったということのようですね。

認証らしい認証はしておらず、端末からニセのICCIDが送られてこないことを前提とした設計。……何なのでしょうか、この強烈な既視感(デジャ・ヴュ)は。

……って、言うまでもなくガラパゴスケータイの世界でさんざん見てきた光景ですね。

日本のフィーチャーフォンの世界では、通信がキャリアのゲートウェイを通ることが保証されており、そのゲートウェイで契約者固有IDが改変できないような処理を行っています。そのため、キャリアのゲートウェイ以外から来た通信は拒否することで、契約者固有IDが改竄されない前提でサービスを設計することができました (……が、その処理にも穴があることが指摘され始めている状況です。参考: どうするケータイ認証)。

ですが、スマートフォンやiPadの場合、そのような特殊なゲートウェイを通るとは限らないわけですから、リクエストが改竄されないことを前提とする設計には無理があります。日本のケータイサイト専門業者が作ったならともかく、AT&Tのサービスがというのは、ちょっとビックリしますね。

関連する話題: セキュリティ / モバイル / Apple

最近の日記

関わった本など

インクルーシブHTML+CSS & JavaScript 多様なユーザーニーズに応えるフロントエンドデザインパターンデザイニングWebアクセシビリティ - アクセシブルな設計やコンテンツ制作のアプローチコーディングWebアクセシビリティ - WAI-ARIAで実現するマルチデバイス環境のWebアプリケーション体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践ウェブの仕事力が上がる標準ガイドブック 5 WebプログラミングWeb Site Expert #13Dreamweaver プロフェッショナル・スタイル [CS3対応] (Style for professional)

その他サイト