令和2年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問1｜バーコードが「他人の財布」になる日——情報処理安全確保支援士で学ぶスマホ決済なりすましの実例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和2年度 10月 情報処理安全確保支援士試験 午後Ⅰ 問1
• 主なテーマ: スマホ決済のなりすまし、メッセージ認証（HMAC）、QRコード決済、DNS設定改ざんによる中間者攻撃、サーバ証明書検証、パスワードリスト攻撃とスクリーニング

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

スマートフォンに表示したバーコードやQRコードを店員に読み取ってもらうだけで、支払いが終わる。いまや当たり前になったこの決済体験は、裏側で「この画面を出している人が、本当にその会員本人なのか」をどう確かめるかという難問を抱えています。情報処理安全確保支援士試験で出題されたこの事例は、ポイントカードのバーコードをそのまま決済に転用しようとした企業を舞台に、「便利な仕組みを金銭にそのまま流用すると何が起きるのか」を正面から描いています。

この事例の主役は、攻撃の派手さではありません。むしろ「ポイントが貯まるだけなら問題なかった仕組み」が、「お金が動く仕組み」に変わった瞬間に牙をむく、という地味で怖い構造です。会員番号をそのまま表示していたバーコードは、ポイント付与の世界では誰も困らなかった。しかし決済の世界では、それは「他人の財布」を開ける鍵になり得ます。

この記事を読むと、攻撃者がどうやって他人になりすまして決済しようとするのか、HMAC（メッセージ認証符号）という仕組みがなぜそのなりすましを封じられるのか、無線LANルータの設定をいじるだけでなぜ偽サーバへ誘導できてしまうのか、そして会員登録画面のたった一言のエラーメッセージが攻撃の入口になる理由が見えてきます。受験者にとっては認証・証明書・リスト型攻撃という頻出論点が一本のストーリーでつながり、サービスを企画・発注する経営層にとっては「既存の仕組みの流用には固有のリスクがある」という判断軸が得られるはずです。

インシデントの概要

舞台は、従業員数1万名、全国に500店舗を展開する飲食業者のN社です。N社はこれまで、会員番号をバーコードとして表示するスマートフォン用のポイントアプリを使い、来店した利用者にポイントを付与してきました。店員がバーコードをバーコードリーダで読み取れば、その会員にポイントが貯まる——シンプルで、長年トラブルもなかった仕組みです。

利用者の利便性をさらに高めようと、N社はスマートフォンで支払いまで完結する独自の決済システム（以下、Nシステム）を開発することにしました。Nシステムは三つの登場人物から成ります。店舗で店員が使うタブレット端末用の「店舗アプリ」、利用者が自分のスマホで使う「決済アプリ」、そして決済・ログ取得・アラート通知といった機能をもつ「WebサーバN」です。店舗アプリと決済アプリは、いずれもHTTPS（通信内容を暗号化するHTTPの安全版）でWebサーバNとやり取りします。

決済アプリでは、利用者はメールアドレスをログインIDとして会員登録します。登録すると決済アプリ用の会員番号が自動で発番され、パスワードなどの情報も登録します。支払いのときは、利用者があらかじめログインしておき、店員が金額を入力して伝え、利用者が決済アプリにバーコードを表示し、店員がそれを読み取って、バーコードが示す会員番号に対して決済する——という流れでした。ここで重要なのは、決済アプリが表示するバーコードの中身が、ポイントアプリと同じ「16桁の会員番号そのもの」だったという点です。

そして各店舗には、利用者にも無線LANサービスを提供するため、導入済みの無線LANルータをインターネットに接続する計画がありました。ルータはすべて同一機種で、各店舗の管理者が手動で初期設定をしていました。

システムの仕様と設計が固まった段階で、開発チームのXさんが作った設計を、情報処理安全確保支援士（登録セキスペ）のYさんがセキュリティの観点でレビューします。このレビューが、後に続くいくつもの「もし攻撃者がここを突いたら」という想像の引き金になりました。

何が起きたのか

Yさんが最初に指を止めたのは、決済アプリが表示するバーコードでした。「これは、ポイントアプリのときと同じ仕組みのままですね。バーコードの中身は会員番号そのものだ」。

ポイントアプリの時代、この仕様は問題になりませんでした。仮に誰かが他人の会員番号を表示しても、できることは「その人にポイントを貯めてあげる」ことだけ。被害者はいません。ところが決済アプリは、同じバーコードで金銭を直接動かします。Yさんの頭の中で、攻撃者の動きが具体的に像を結びます。

会員番号は16桁の数字です。自動発番される番号には、しばしば連番や規則性が紛れ込みます。攻撃者は、自分の会員番号を起点に、前後の番号や規則性から他人の会員番号を推測するかもしれません。あるいは、何らかの方法で他人の会員番号を窃取し、その番号を表すバーコードを自分で生成して画面に表示する。店員はバーコードの見た目から「これは本人のものではない」とは判別できません。店員がそれを読み取れば、システムは「そのバーコードが示す会員番号に対して決済する」だけ。支払いの請求は、番号の持ち主——つまり赤の他人——に向かいます。これが、Yさんが指摘した「他者になりすまして決済できる」という第一のリスクの正体です。

この攻撃が成功してしまう原因は、決済アプリ側に二つあります。一つは、バーコードの内容が会員番号そのものであること。本人確認の根拠になるべき情報が、推測も窃取もされ得る「ただの番号」だったのです。もう一つは、そのバーコードが永続的に使えてしまうこと。会員番号は変わらないので、一度知られたバーコードは、いつでも、何度でも使えてしまいます。

Xさんが検討した対策が、メッセージ認証（通信内容が正規の相手によって作られ、改ざんされていないことを暗号的に確かめる技術）でした。具体的には、決済アプリに表示する情報として、会員番号に加え、WebサーバNが生成した乱数、時刻、そしてそれら三つを基に計算したHMAC（Hash-based Message Authentication Code、メッセージ認証符号。秘密鍵とデータからハッシュを計算し、データの正当性を保証する仕組み）の値を含めることにしました。情報量がバーコードで扱える桁数を超えるため、表示はQRコードに切り替えます。

新しい決済フローはこうです。決済アプリがWebサーバNにQRコード生成をリクエストすると、WebサーバNが乱数を生成し、自分だけが持つ秘密鍵Kを使って「会員番号・乱数・時刻」からHMAC値αを計算します。そして会員番号・乱数・時刻・HMAC値αから成るQRコードを作り、決済アプリに返します。店員がそのQRコードを読み取り、決済リクエストとしてWebサーバNに送ると、WebサーバNは秘密鍵Kを使ってQRコード中の会員番号・乱数・時刻から改めてHMAC値βを計算し、QRコードに入っていたαとβが一致するかを検証します。さらに、QRコード中の時刻が現在時刻から5分以内であること、同じQRコードが過去に使われていないことも確認してから、決済を実行します。

ここに、なりすましを封じる鍵があります。HMAC値を正しく計算するには、WebサーバNだけが持つ秘密鍵Kが必要です。攻撃者は秘密鍵Kを知りません。だから、たとえ他人の会員番号を手に入れても、その番号に対応する正しいHMAC値を自力で作ることができない。偽のQRコードを作っても、WebサーバNでαとβが一致せず、検証に弾かれます。加えて、時刻と乱数が組み込まれ「5分以内・過去未使用」の条件が課されたことで、過去に正規利用者が出したQRコードを盗み見て使い回す——いわゆるリプレイ攻撃も防げるようになりました。永続的に使えた静的なバーコードが、一回限り・短時間限り・本人のサーバだけが作れる動的なQRコードへと姿を変えたのです。

Yさんの指摘は、これで終わりませんでした。視線は、店舗に置かれる無線LANルータへと移ります。

このルータには既知の脆弱性があり、本来はインターネット側からアクセスできないはずの管理者機能のログイン画面に、外部からアクセスできてしまう恐れがありました。さらに、管理者機能のパスワードが工場出荷時のまま変更されていない可能性もありました。もし攻撃者が管理者機能に入り込めたら何ができるか——ここでYさんが想定したのが、ルータの設定改ざんによる中間者攻撃です。

攻撃者が無線LANルータの設定のうち、DNS（Domain Name System、ドメイン名をIPアドレスに変換する仕組み）に関する項目を書き換えたとします。ルータが参照するDNSサーバのIPアドレスを、攻撃者が用意したDNSサーバのものに変えてしまうのです。すると、その店舗の無線LANにつないだ利用者のスマホが「WebサーバNの住所はどこ？」と問い合わせたとき、攻撃者のDNSサーバが「ここですよ」と偽のIPアドレス——攻撃者が用意したサーバの住所——を返します。利用者は、正規のアプリを使い、正規のドメイン名にアクセスしているつもりのまま、攻撃者のサーバへ吸い込まれていく。本人は何も気付きません。問題文で「攻撃者が無線LANルータの設定を変更すると、攻撃者が用意したサーバに利用者が接続しても気付かないおそれがある」と下線が引かれていたのは、まさにこの筋書きです。

この偽サーバ誘導を最後の砦で食い止めるのが、サーバ証明書（通信相手が本物であることを証明する電子的な身分証）の検証でした。Yさんは、決済アプリと店舗アプリのサーバ証明書の検証に不備があると指摘していました。たとえ偽サーバへ誘導されても、アプリが「この証明書は本当にWebサーバNのものか」をきちんと確かめれば、攻撃者のサーバが提示する証明書では検証が通らず、接続を拒否できます。攻撃者は正規のWebサーバNになりすませる証明書を持っていないからです。

最後にYさんが指摘したのは、決済アプリの会員登録機能でした。一見ありふれた登録画面に、攻撃の入口が潜んでいたのです。利用者がメールアドレスを入力すると、そのアドレスがまだ登録されていなければ「電子メールを送信しました。」と表示され、すでに登録済みなら「既に使用されているメールアドレスです。」とエラーが出る——表示が、メールアドレスの登録有無で変わる仕様でした。

攻撃者の視点に立つと、この差は宝の地図に見えます。攻撃者の手元には、他社サービスから漏えいしたメールアドレスとパスワードの組み合わせ（パスワードリスト）があるとします。攻撃者は登録画面に大量のメールアドレスを入力し、表示の違いから「どのアドレスがN社に登録済みか」を選り分けられます。これがスクリーニング（事前選別。攻撃者が手元のリストから無効なものを取り除く作業）です。登録済みと分かったアドレスだけに絞ってパスワードリスト攻撃（漏えいした認証情報をそのまま試すログイン試行）を仕掛ければ、攻撃は格段に効率化します。しかも、N社のアラート通知機能は「存在しないログインIDでのログイン試行が短時間に連続する」場合などに発報する設計です。事前にスクリーニングして存在するアカウントだけを狙えば、この検知網にもかかりにくい。便利なはずの登録画面が、攻撃者の下調べを助ける道具になっていたのです。