高木浩光＠自宅の日記

■ 再掲：au携帯電話のバーコードリーダでジャンプ先URLが偽装される（2005年4月）

一昨年4月23日の日記からリンクしていた、BUGTRAQ-JPの記事「au携帯電話のバーコードリーダでジャンプ先URLが偽装される」が文字化けして読めない状態になっている*1ので、以下にHTML化して再掲しておく。

Date: Fri, 15 Apr 2005 05:17:16 +0900
From: Hiromitsu Takagi <略>@takagi-hiromitsu.jp
To: bugtraq-jp@securityfocus.com
Subject: au携帯電話のバーコードリーダでジャンプ先URLが偽装される

au携帯電話のバーコードリーダでジャンプ先URLが偽装される

以下は、JVN#9ADCBB12の事例について、ユーザおよび開発者が知っておくべきと考えることがらについて、発見者の立場からその発見内容および考察を公表するものである。

概要

au携帯電話の「バーコードリーダ」機能でQRコードを読み取り、そこに含まれるURLにEZwebでアクセスする際、特定のQRコードを読み取ると、画面上で選択したのとは異なるURLにジャンプしてしまう。この挙動は、リアル世界で配布される悪意あるQRコードによって、バーチャル世界で偽サイトに誘われてしまうという、いわば「ユビキタスフィッシング」の危険性をもたらしている。

この挙動が生じないよう修正された「バーコードリーダ」BREWアプリの新バージョンがKDDIより提供されているので、ユーザは最新版をダウンロードすることでこの問題を解決できる。また、ダウンロードしない場合でも、以下に述べるとおり、この問題の原因を知って使い方に注意することで被害を回避できる。

履歴

2005年2月3日 IPA脆弱性情報届出窓口に届け出た。
2005年4月14日 JVNにて公表された。

対象

4月14日付の「auからのお知らせ」に、該当機種が記されている。

• バーコード (2次元コード) リーダーご利用にあたっての注意点, KDDI, 2005年4月14日

「バーコードリーダ」BREWアプリの該当バージョンは不明であるが、少なくとも、発見者は「BARCODE READER MEDIASEEK/KDDI Version 2.0.5h」と表示されるバージョンにおいてこの現象を確認し、また、現時点で最新版の「BARCODE READER MEDIASEEK/KDDI Version 3.0.1a」と表示されるものについて、この現象が起きないことを確認した。

現象

以下の1行の内容をQRコードとして作成すると図1の画像が得られる。

MEBKM:TITLE:http://www.au.kddi.com/;URL:http://i.nttdocomo.co.jp/;;

図1

このQRコードを当該BREWアプリ「バーコードリーダー」で読取ると、携帯電話は図2の画面となる。

図2

ジャンプ先として表示されている1つ目のものが「http://www.au.kddi.com/」となっていることを確認しつつ、「選択」ボタンを押す。すると、メニューが現れる（図3）。

図3

ここで「URLを参照する」を選択すると、「URLへ接続します。よろしいですか？」という確認画面が現れる（図4）。

図4

「はい」ボタンを押すと、www.au.kddi.com ではなく i.nttdocomo.co.jp へジャンプしてしまう。

問題点と原因

一般に、携帯電話のWebブラウザにはアドレスバーがない。一部の携帯電話会社のブラウザでは、メニューからURLを確認できるようになっているものもあるが、アドレスバーがないため、携帯電話のユーザは、今見ているページがどこのドメインのサイトであるかを普段意識せずに使うのが通例となっている。特に、auのブラウザでは、メニューにも現在のURLを確認する機能が用意されていない。

現在の画面のアドレスを確認できない（確認しにくい）ことは、フィッシング詐欺など、偽サイトに騙されやすくなる危険性をもたらしかねないところであるが、携帯電話では一般的に、メールはテキストメールである（HTMLメール機能がない）ため、メールで誘われたジャンプ先はテキストとしてURLがはっきりと見えるようになっているうえ、さらに、メールからWebサイトへのアクセスが発生する直前の段階で、ジャンプ先URLを表示させて、本当にここへアクセスしてよいかを確認する機能が搭載されているのが通例である。

このように、携帯電話のWebブラウザでは、ジャンプ前にジャンプ先のサイトのドメイン名を確認するという使い方をユーザに習慣付けることによって、偽サイトへの誘導を防止しているのが現状であると言える。

しかしながら、「バーコードリーダ」の当該バージョンでは、図4 のように、ジャンプ前の確認ステップは存在するものの、本当のジャンプ先URLが表示されない。

また、図2 に示したように、QRコードを読取った直後の画面では、リンク先があたかも http://www.au.kddi.com/ であるかのように表示されているが、この部分の本当のジャンプ先は http://i.nttdocomo.co.jp/ となっている。このような現象が起きる原因は次の通りである。

今回使用したQRコードのデータは、

MEBKM:TITLE:http://www.au.kddi.com/;URL:http://i.nttdocomo.co.jp/;;  

• NTTドコモのバーコード機能における「ブックマーク登録機能」

「TITLE:」以降に記述する部分は表題であり、「URL:」以降がジャンプ先のURLである。これをNTTドコモの携帯電話で読取ったときの表示を図5に示すが、このように、「TITLE:」で指定した部分はリンクとしてではなく、そのままテキストとして表示されるのが本来の挙動である。

図5

auの携帯電話のバーコード機能の仕様には、この「MEBKM:」の書式は存在しないが、当該ソフトウェア「BARCODE READER MEDIASEEK/KDDI Version 2.0.5h」は、NTTドコモ仕様の「MEBKM:」も解釈するように作られている。

• auのバーコード機能における書式

通常の使用においては、読み取り結果の画面は図6のようになる。これは、「TITLE:」欄にURLでないテキスト「au by KDDI」を記入したQRコードを読取ったときの画面である。タイトル部分がリンクとなり、ジャンプ先は「URL:」欄に指定したURLとなっている。

図6

しかしながら、タイトル部分がURL形式である場合においても同様に動作してしまうため、図2 のように、あたかも www.au.kddi.com へのリンクであるかのように誤認させる形で、i.nttdocomo.co.jp へのリンクを表示させることができてしまう。これは、PC用のHTMLメールで昨今横行しているフィッシング詐欺の手口と同じ仕組みである。

またこのとき、図2のように、画面には偽のジャンプ先と、本物のジャンプ先の2つが並んで表示されることになるが、この表示は、「MEBKM:」機能を使用せずに、単に2つのURLが記載されているQRコードの場合と違わない表示形式であるため、「MEBKM:」により偽装されているのか、通常の2つのURLなのか、区別がつかない。

したがって、ユーザがジャンプ先を誤認したままアクセスを許可してしまうおそれがある。

回避策

こうした挙動の事実を知っていれば、図2の段階で、2つのURLが表示されているときには、2つ目のURLが怪しいアドレスでないかを目視確認することで、そのQRコードがジャンプ先偽装を企んだものではないかと疑うことができる。

また、図3の段階で、「URLを参照する」ではなく「アドレス帳に登録する」を選択し、一旦アドレス帳に登録したうえで、アドレス帳からURLにジャンプするようにすれば、アドレス帳では本物のURLを目視確認できる。

修正内容

4月14日にリリースされた最新バージョンでは、図2の部分が図7のように表示されるようになった。

図7

つまり、NTTドコモの書式に非対応となった。これにより、TITLE:欄に記述されたURLは、単独のURLとして解釈されることとなり、http://www.au.kddi.com/ として表示されるリンクのジャンプ先は http://www.au.kddi.com/ となるように改善された。

また、http://www.au.kddi.com/news/information/au_info_20050414.html に記されているように、ジャンプ直前の接続確認画面に、ジャンプ先のURLが表示されるように改善された。

脅威と考察

今後、本格的なユビキタス社会が到来すれば、チラシ広告や街角のポスターなどに記載されたQRコードから、携帯電話で目的のWebサイトへアクセスするといったことが日常化してくると考えられる。

このとき、銀行や著名なネットショップへのジャンプ用のQRコードを読み取ったつもりが、フィッシング詐欺用の偽サイトへと誘導されてしまうといった事態が起きかねない。本物のポスターに偽サイトのURLを記したQRコードのシールを貼られて誘導されるという恐れもあるので、QRコード画像が掲載された媒体の物理的な真偽を見極めるという対処は現実的でない。

携帯電話ユーザの自衛策は、PCの場合と同様に、ジャンプ先のURLが信頼できるドメインのサイトになっているかを確認することに尽きる。

しかしながら携帯電話にはアドレスバーが存在せず、ジャンプ後ではなく、ジャンプ前にURLを確認せざるを得ない。当該「バーコードリーダ」のこの挙動は、ジャンプ前のURL確認を誤認させるものであるため、ユーザがそのまま偽サイトにパスワード等の重要情報を入力してしまうおそれがあった。

根本的な問題解決のためには、携帯電話のWebブラウザにアドレスバーを設けるべきである。それが当面実現しないのであれば、それまでの間は、外部からの入力によって指定されるURLにジャンプする機能を持つソフトウェアを作成する際には、必ず、ジャンプ前にジャンプ先のURLを表示して、ユーザに確認を求めるよう設計する必要がある。

この公表の必要性と妥当性

auからの発表文「バーコード (2次元コード) リーダーご利用にあたっての注意点」では、なぜこの事象に注意しなくてはならないのかが説明されておらず、悪意ある第三者からの攻撃に対して弱いという性質を持つ問題点であることがユーザにわかりにくくなっている。QRコードを介したフィッシング詐欺のおそれがあることは、ユーザに伝える必要があると考える。

こうした種類の脆弱性は現時点では珍しいものであるため、こうした設計や実装がこのような懸念を生じさせるものであることを、開発者に広く知らせることで、類似の脆弱性が今後再び生じないよう促す意義は大きいと考える。

この脆弱性が悪用されるには複数のプロセスを踏む必要があり、また、利用者による能動的な操作が必要となるものであるので、現時点で直ちに攻撃の現実性が高いものではないと考える。また、ユーザの現実的な回避策も存在する。脆弱性を公表することによって生ずるリスクよりも、事実を公表することによって将来の安全を確保する長期的なメリットの方が上回ると判断する。

以上

--
高木 浩光＠自宅