情報処理安全確保支援士 2014年 春期 午後1 問03

解答の論理構成

1. 【問題文】では、G部長が
   「利用者を『①偽 Web サイト』に誘導するものではないね。」
   と述べています。ここで強調されているのは「偽 Web サイト」に利用者を誘導して認証情報を窃取する典型的な攻撃です。
2. インターネット上で「偽 Web サイト」に誘導し、IDやパスワードなどを詐取する行為は、一般に「フィッシング」と呼ばれます。
3. したがって、「偽 Web サイト」を総称する言葉として最も適切なのは「フィッシングサイト」です。

誤りやすいポイント

• 「スパイウェア」や「マルウェア」と誤答するケース
  偽サイトへ誘導する行為そのものを指す用語ではありません。
• 「詐欺サイト」「偽装サイト」などの曖昧表現
  一般的かつ情報セキュリティ分野で定着した用語を選ぶ必要があります。

FAQ

解答の論理構成

• 【問題文】で G 部長は「法人利用者については、利用者 ID、パスワードを盗まれたとしても、金銭的な被害が発生する可能性は低い」と述べています。
• その理由を示す手がかりは図1にあり、法人利用者はログイン前に「クライアント証明書によるTLS接続」を行います。
• さらに図1の注記には「法人利用者の使用するクライアント証明書に対応する秘密鍵は、エクスポートできない状態でPCにインストールされる」とあります。
• 攻撃者が PC 内のマルウェアで「利用者 ID、パスワード」を奪取しても、「クライアント証明書」および対応する秘密鍵を取得できなければ TLS ハンドシェイクが成立せずログインできません。
• したがって「攻撃者はクライアント証明書がなく、ログインできない」が理由となり、被害発生の可能性が低いと結論付けられます。

誤りやすいポイント

• 個人利用者と法人利用者で認証フローが異なることを見落とし、乱数表の有無にだけ注目してしまう。
• クライアント証明書を使っていても、秘密鍵がマルウェアに奪われると誤解する。実際には「エクスポートできない状態」で保護されている。
• 「TLS 接続＝安全」と短絡的に考え、証明書所有の有無がログインの要件である点を忘れる。
• OTP やリスクベース認証のような追加要素と混同し、法人側も同じ対策と誤認する。

FAQ

解答の論理構成

• 【問題文】には、「メネットサービスのドメイン名はx-bank.jpであり、HTTP over TLS用にEVSSL証明書（以下、サーバ証明書という）を使用している。」とあります。正規サイトは“EVSSL”の証明書を提示できるため、ブラウザは正常に緑色バーや錠前アイコンを表示します。
• ところがG部長は「x-bank.jpへのアクセスを偽Webサイトに誘導して行われる中間者攻撃であれば、③最新のブラウザを使っている利用者は攻撃に気付くことができる」と述べています。この状況では偽サイトが正しい“サーバ証明書”を用意できないため、TLSハンドシェイクが失敗し、ブラウザは警告画面を表示します。
• したがって利用者は、表示された「接続が安全ではない」「証明書に問題がある」などの警告画面を確認することで攻撃に気付きます。
• 以上より、模範解答の「利用者のブラウザに表示される警告画面を見て気付くことができる」が導かれます。

誤りやすいポイント

• 「偽Webサイトに誘導しない攻撃だから証明書警告は出ない」と早合点する。中間者攻撃＋DNSスプーフィングのケースでは依然として偽サイト側が証明書を提示できず、警告は出ます。
• 錠前アイコンの“有無”だけに注目し、警告画面を読み飛ばす。証明書失効やコモンネーム不一致でも警告は出るため、メッセージ内容を確認する必要があります。
• 「最新ブラウザ限定」という条件を忘れ、古いブラウザや警告表示を無効にした環境でも同様に気付けると誤答する。

FAQ

解答の論理構成

1. 【問題文】図3の“送金内容入力画面”には「口座番号： [123456]」「送金額： [10000] 円」と示されています。したがって a は「123456」、b は「10000」です。
2. 同じく図3の“＜マルウェアKの動作＞”には「ブラウザの動作に介入し、攻撃者が意図した送金内容に書き換える。」とあり、書き換え後の値として「口座番号： 999999」「送金額： 500000」が提示されています。
3. さらに「ブラウザの動作に介入し、送金内容確認画面を書き換える。」とも記載されています。これは利用者が最終確認時に“改ざん済みの値”を見せないための操作であると読み取れます。
4. 以上より、送金内容確認画面を書き換える目的は「マルウェアKが書き換えた口座番号と送金額を利用者に隠すこと」と整理できます。

誤りやすいポイント

• “送金内容入力画面”と“書き換え後の送金内容”を取り違え、a と b に「999999」「500000」を書いてしまう。
• 「確認画面を書き換える目的」を“改ざんするため”などとだけ書き、利用者視点の“隠蔽”を明記しない。
• マルウェアKを“中間者攻撃”と誤認し、通信経路上で改ざんすると説明してしまう（実際は“Man-in-the-Browser”）。

FAQ

解答の論理構成

1. マルウェアJの攻撃内容
   • 会話文より「利用者ID、パスワード、乱数表の情報（以下、併せて認証情報という）を盗もうとするもの」
   • 図2の破線枠でも「入力された利用者ID、パスワードを攻撃者に送信」「乱数表情報の入力を促す」と明記
     → マルウェアJは“利用者の入力を盗む”だけで、ブラウザ内で送金内容を書き換える機能はない。
2. ワンタイムパスワード認証（表1）
   • 「認証のたびに、要求するパスワードが変わる方式。入力すべきパスワードは、専用デバイスに表示される。」
   • 盗まれても次回には無効になる一次性が利点。
   • マルウェアJは“後で”不正送金に再利用するために認証情報を収集するが、一次性ゆえ再利用できない。
     → c は「対策になる」。
3. 送金内容認証（表1）
   • 「利用者とネットバンキングのWebサイト間で…共通鍵…HMAC計算ツール…送金内容に対して、メッセージ認証コードを用いる方式。」
   • 攻撃者は送金手続きを実行する際、正しい HMAC 値を計算できなければサーバが受け付けない。
   • マルウェアJは共通鍵もツールも奪っていないため、後日ログインしても送金を完了できない。
     → d も「対策になる」。
4. 評価の整合性
   • 表2の他列との比較
     ・マルウェアK列でワンタイムパスワードは「対策にならない」とされている（同一セッション内の書き換えは防げない）
     ・送金内容認証はマルウェアKにも「対策になる」とされている（改ざん検知が可能）
   • よってマルウェアJ列では少なくともワンタイムパスワード・送金内容認証が「対策になる」とするのが最も矛盾がない。

誤りやすいポイント

• 「盗まれる＝即アウト」と短絡し、一次性資格情報の再利用不可という本質を見落とす。
• 送金内容認証を“送金操作時だけ有効”と誤解し、ログイン後の再利用攻撃を想定できず評価を下げる。
• マルウェアJとマルウェアKの挙動を混同し、ブラウザ改ざん型（K）の話をJにも当てはめてしまう。

FAQ

解答の論理構成

1. 問題文では「項番1」として引用されている「利用者ID・パスワード認証」は“知識要素”のみを用いる方式です。
2. 「項番4」として引用されている「ワンタイムパスワード認証」は、問題文の表1で「入力すべきパスワードは、専用デバイスに表示される」と説明されており、“所持要素”を必要とします。
3. 本文中の該当箇所は「項番1と項番4の認証を組み合わせたe認証といわれる認証方式」と記載されています。
4. 異なる2種類の認証要素（知識＋所持）を組み合わせる方式は一般に“二要素認証”と呼ばれます。
5. 以上より、eに入る適切な字句は「二要素」と結論付けられます。

誤りやすいポイント

• 「多要素」と記述してしまう。二要素は多要素の一種だが、設問は「項番1と項番4の“2つ”を組み合わせた方式」に限定している。
• ワンタイムパスワードを“知識要素”と誤認する。専用デバイスで生成されるため所持要素に分類される。
• 「二段階」と書くミス。二段階認証は手順の回数を表す用語で、要素の種類を示す“二要素”とは文脈が異なる。

FAQ

解答の論理構成

1. 問題文は「マルウェアKは、ブラウザの動作に介入し、攻撃者が意図した送金内容に書き換える。」と述べ、さらに「利用者は、マルウェアJ、マルウェアKの感染に気付くことができないことを前提」としています。
2. 下線④で「HMAC計算ツールをPC用のプログラムではなく、専用デバイスの形態で利用者に提供する」とあるのは、PC上のツールではマルウェアに干渉され得ることを示唆しています。
3. HMAC計算ツールが「PC用のプログラム」であれば、同じPC内で動作するマルウェアが
   ・送金先口座番号や送金額などツールへ渡す入力値を改ざん
   ・計算後に得られたHMAC値を盗み再利用
   ・ツール自体を差し替え
   などの攻撃を行えるため、送金内容認証の前提が崩れます。
4. したがって「マルウェアに感染したPCでは、HMAC計算ツールの入力内容や計算結果が改ざん・窃取される」という点がセキュリティ上の問題であり、専用デバイス化によってPCと物理的に分離する必要があります。

誤りやすいポイント

• 「PC上でHMACを計算するから暗号的に安全」と考え、マルウェアによる入力改ざんリスクを見落とす。
• マルウェアKがTLSを破る攻撃だと誤解し、HMAC計算ツールの安全性と直接結び付けてしまう。
• 「HMAC値が盗まれても一度限り」と誤認し、同じ入力の再送攻撃や入力値改ざんの影響を軽視する。

FAQ