SC R2 午後１問１ 情報処理安全確保支援士 解説
※個人の見解です。間違いはコメントにてご指摘ください。お手柔らかにお願いします。
IPA公式問題PDF
【問題の概要】
スマホ決済アプリを提供することになったN社のシステムを登録セキスペのYさんがレビューをした際の指摘と対策からなる問題。
利用者はスマホアプリにバーコードを表示し、店員がバーコードリーダーでそれを読み取る。店舗アプリがインストールされたタブレットを各店舗に配布し、それに合わせて無線LANを導入する。
【設問の趣旨】
（1）決済アプリにおいてなりすまし決済を可能とさせる設計
（2）無線LANの脆弱性と不適切な機器設定、決済アプリと店舗でのサーバ証明書の検証の不備
（3）パスワードリスト攻撃を助長する決済アプリの会員登録処理の挙動
【システムの概要】
【決済アプリの機能の概要、WebサーバNの機能の概要、会員登録処理、決済処理】
【Yさんの５つの指摘】
《 設問１ 》
他者に成りすまして決済アプリで決済できることを、Yさんは項番で指摘した。
【Yさんの指摘を受けた項番１への対策】
決済にメッセージ認証を用いることにした。具体的には、会員番号・WebサーバNで生成した乱数・時刻・この3つの情報を基に生成されるHMAC値をQRコードで示すことにした。
【問：項番１への対策について答えよ。】
（1）どのような手段でなりすまして決済ができるのか。想定される手段を30字以内で具体的に述べよ。また、その攻撃が成功してしまう決済アプリにおける問題を25字以内で具体的に述べよ。
（2）図3中の[a]に入れる具体的な字句を30字以内で述べよ。
【IPA公式解答】
（1）
・なりすまし決済の手段
他者のバーコードを会員番号から推測して表示する。/ 他者の会員番号を窃取してバーコードを生成し、決済する。
・決済アプリにおける問題
バーコードの内容が会員番号であること。/ バーコードが永続的に利用できること。
（2）HMAC値αとHMAC値βの一致を検証する。
【解説】
（1）このアプリでは、メールアドレスをログインIDとして登録する。会員登録すると、自動的に16桁の会員番号が発番される。この会員番号がバーコードとして表示される。店舗アプリはバーコードを読み取り、バーコードが示す会員番号に対して決済する。このバーコードに対して正しく会員情報が紐づいていないためになりすまし決済が可能となる。
例えば、レジに並んでいる時に前の客がスマホにバーコードを表示して並んでいるとしよう。そのバーコードを後ろに並んでいる別の客がスマホカメラで撮影し、撮影したバーコードの画像をレジで提示し自分の買い物の決済をする。こういった犯行は実際に起こっている。
（2）会員番号16桁をバーコード表示するだけなんて、ポイントアプリなら良いけど、決済も同じ仕様でやるなんてそりゃなりすましが起こるよねダメに決まってるでしょ。ということで会員番号・WebサーバNで生成した乱数・時刻・この3つの情報を基に生成したHMAC値をQRコードで表示する仕様に変更。WebサーバNが生成したQRコード内のHMAC値αと、リクエストを送ってきたクライアントが示すQRコード内のHMAC値βの一致を（WebサーバNで）検証する。その際、QRコード中の時刻が5分以内かどうか、過去に使われたQRコードではないかも同時に確認する。
《 設問２ 》
【無線LANルータの管理者機能の設定項目（抜粋）】
【Yさんの指摘、項番２－４の内容】
項番２：無線LANの既知の脆弱性によって管理者機能もログイン画面にアクセスできる。
項番３：管理者機能のパスワードが工場出荷時のデフォルト設定で運用される可能性がある。
項番４：決済アプリ・店舗アプリでのサーバ証明書の検証に不備がある。
この３点を解決せずに無線LANサービスを提供していると、攻撃者が無線LANルータの設定を変更して攻撃者が用意したサーバに利用者が接続してしまっても気づかない恐れがある。
【項番２－４の対策】
項番２の対策は、インターネットからの無線LANルータの管理者機能のログイン画面にアクセスされないように、無線LANルータのファームウェアを最新バージョンにアップデートしてもらうことにした。
項番３の対策は、デフォルトパスワードから変更するように運用ルールを改定した。デフォルトのパスワードから変更していない場合はパスワードを変更してもらうことにした。
項番４の対策として、サーバ証明書が以下の条件を満たしていることを検証するように、決済アプリと店舗アプリを改修した。
【問：項番２－４への対策について答えよ】
（1）「Yさんの指摘、項番２－４を解決せずに無線LANサービスを提供していると、攻撃者が無線LANルータの設定を変更して攻撃者が用意したサーバに利用者が接続してしまっても気づかない恐れがある。」とあるが、攻撃者は、どの設定項目の内容をどのように変更するのか。表5の【無線LANルータの管理者機能の設定項目（抜粋）】から項目を選び記号で答えよ。また、変更後の設定内容を25字で答えよ。
（2）[サーバ証明書の検証条件]内の [ b ] [ d ] に該当するものをア～カから選び[ c ] は5字以内で答えよ。
ア．authorityKeyIdentifier
イ．commonName
ウ．issuer
エ．serialNumber
オ．subjectAltName
カ．subjectPublicKeyInfo
【IPA公式解答】
（1）い（DNSプロキシ） / 攻撃者のDNSサーバのIPアドレス
（2） [ b ] オ [ c ] FQDN [ d ] イ
【解説】
（1）DNSのプロキシの設定が変更されて攻撃者の用意したDNSサーバに接続させられたらヤバイです、ということが答えられたら良いと思われる。
攻撃者により設定が変更された無線LANを利用した通信は、攻撃者の用意したDNSサーバを参照し名前解決を行うため、偽の情報（IPアドレス）が書き込まれていればそこに接続してしまう。この設問の場合であればwebサーバNではなく攻撃者の用意した偽サーバのIPアドレスに接続してしまう可能性があるだろう。
（2）subjectAltNameとは、サーバ証明書のサブジェクト代替名のこと。「DNS NAME＝△△△.com」といったFQDN、「IP Address=192.168.10.10」といったIPアドレスなどが記載される。今ご覧になっているQiitaの証明書では、サブジェクト代替名のフィールドには「DNS name=qiita.com,DNS Name=*.qiita.com」と記されている。
「サーバ証明書に [ b ] の dNSName があれば、アクセス先のWebサーバNの [ c ]と合致し、サーバ証明書に [ b ] の dNSName がなければ、アクセス先のWebサーバNの subject の [ d ] と合致すること。」とあるが、subjectAltName に dNSName があればアクセス先サーバのFQDNと合致するか検証し、subjectAltName に dNSName がなければ commonName フィールドの FQDN を参照せよということである。
しかしながら、RFC3280.4.2.1.7 には、subjectAltName に dNSName がなければ commonName フィールドの FQDN を参照してもいいが【推奨しない】との記載があるのでその辺りは記憶に留めておいてもらうと良いかもしれない。なお、１つの証明書で複数のサーバを証明することもできる。
《 設問３ 》
Yさんの指摘の項番５では「決済アプリの会員登録機能は、攻撃者が悪用すると、当該機能の挙動からスクリーニングができてしまう」とあり、その対策として表３の会員登録処理を修正し、２段階認証を施し、アラート通知機能の見直しを行った。
修正前の会員登録機能だと、攻撃者がスクリーニングを行って収集したパスワードリストを用いてパスワードリスト攻撃をされたとしても、WebサーバNのアラート通知機能では検知できない可能性がある。
【問：項番５への対策について答えよ】
（1）Nシステムのどのような挙動を利用してスクリーニングを実行したと考えられるか。40字で具体的に述べよ。
（2）会員登録処理の修正について、表３中の修正すべき事項の記号を答えよ。また修正後の処理を25字で述べよ。
【IPA公式解答】
（1）メールアドレスが会員登録されているかどうかで表示が異なるという挙動
（2）修正すべき処理 [ 2-b ] / 修正後の処理： 2-a と同じメッセージを表示する。
【解説】
（1）WebサーバNのアラート通知機能について確認しよう。
・同一IPアドレスから同一ログインIDでログイン失敗が短時間に連続して発生するとアラート。
・同一IPアドレスから存在しないログインIDでのログイン試行が短時間に連続して発生するとアラート。
以上から「同一IPアドレスからの、存在するログインIDであり且つ同一のログインIDでなければ、何度ログイン試行に失敗しても検知しない」ということになる。
攻撃者は情報収集を行う際、システムにリクエストを送りこみ、そのリクエストに対して吐き出されるエラー表示に着目してシステム構成を推測する。この設問も同様の手口である。攻撃者は、会員登録処理において吐き出されるエラー表示「”既に使用されているメールアドレスです。”」を基にログインIDを収集する。饒舌なエラー表示を利用するのだ。
（2）そこで饒舌なエラーとならないために会員登録処理の挙動を修正しなければならないが、これはリアルだとなかなか悩ましい問題だ。利用者に親切な表示にすると攻撃者が悪用してしまうし、利用者に不親切なエラー表示であればサポートに問い合わせが殺到するだろう。
とはいえこれは試験なので、そういったユーザビリティは考慮せずとも良い。会員登録済みのメールアドレスであろうとなかろうと「同じ挙動をすればよい」というわけなのである。