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

解答の論理構成

1. 図2には「攻撃者は、①無線LANアクセスポイント、DNSサーバ及びWebサーバを用意した。」とあり、さらに「Sさんは、PC-SをホテルWi-Fiに接続しようとして、攻撃者が用意した無線LANアクセスポイントに接続してしまった。」と記載されています。
2. 被害者は本来の“ホテルWi-Fi”へ接続するつもりでしたが、実際には攻撃者が用意したアクセスポイントに誘導されています。これは正規アクセスポイントと同じ識別情報（SSID）と同じ認証情報（事前共有鍵）を設定しなければ成立しません。
3. もしSSIDや事前共有鍵が本物と異なれば、端末は自動接続せず利用者も違和感を覚えるため、図2の状況は生じにくくなります。
4. したがって、下線①の無線LANアクセスポイントには「ホテルWi-Fiと同じSSIDと事前共有鍵」が設定されていたと結論付けられます。

誤りやすいポイント

• SSIDだけを書き、事前共有鍵を失念する。接続には両方が一致する必要があります。
• 「MACアドレス偽装」など物理層の細部に着目し過ぎて、本設問が求める“アクセスポイント設定”から外れてしまう。
• 「オープンネットワークにした」と回答してしまい、正規ネットワークと同一設定である点を示せていない。

FAQ

解答の導き方

1. 図2の該当部分に「そのDNSサーバにはaのFQDNとbのIPアドレスとを関連付けるAレコードが設定されていた」とあります。Aレコードは「FQDN（ドメイン名）→IPアドレス」を返すDNSのレコードなので、aは被害者が入力したドメイン名を示し、bはそのドメイン名が向く先のサーバ（IP）の説明語句になることがわかります。
2. 被害者がどのドメインを入力したかは図1に明記されています。図1に「Sさんは、その日、メールサービスPを利用するために、WebブラウザのアドレスバーにメールサービスPのFQDNを手入力し、ログインページに利用者IDとパスワードを入力した。」とあるため、AレコードのFQDNが指す対象は「メールサービスP」です。よって a には 「メールサービスP」 が入ります。
3. 図2の説明には攻撃者が「無線LANアクセスポイント、DNSサーバ及びWebサーバを用意した」ことと、「実際にはWebブラウザは攻撃者が用意したWebサーバに接続していた」とあります。AレコードがFQDNを攻撃者側のサーバのIPに向けているため、b は攻撃者が用意したWebサーバを示す語句になります。よって b には 「攻撃者が用意したWebサーバ」 が入ります。

誤りやすいポイント

• 「FQDN」とだけ書いてしまう。設問は図中の語句で埋める形式なので、ここでは具体的に「メールサービスP」と書く必要があります。
• DNSサーバとWebサーバを取り違える。AレコードはFQDNをあるIPに紐付けるもので、その先が「攻撃者が用意したWebサーバ」のIPである点を押さえてください。
• サーバ証明書の警告が出なかったことをもって攻撃を否定する誤解。攻撃者側がブラウザに受け入れられる証明書を用意していた可能性や、利用者が警告を見落とした可能性があります。
• HSTSに関する誤解。HSTSはHTTPからHTTPSへのアクセスを強制しプロトコルのダウングレードを防ぐ仕組みですが、提示された証明書がブラウザにより信頼される場合まで「不正な証明書の提示を自動的に無効化」するものではありません（またHSTSは事前にブラウザがそのドメインのHSTS情報を持っているかプリロードされている場合に有効です）。

FAQ

解答の論理構成

1. 前提を確認
   • 問題文に「メールサービスPはHTTP over TLSでサービスが提供されている。HTTPでアクセスした場合はHTTP over TLSのURLにリダイレクトされる仕様になっており、HSTS（HTTP Strict Transport Security）は実装されていない。」とあります。
2. HSTSがない場合のブラウザ挙動
   • HSTS未実装なので、初回アクセスがhttp://で始まるとブラウザは平文HTTPで接続します。この段階ではTLSハンドシェイクを行わないためサーバ証明書の検証自体が実施されません。
3. 手口Gの状況
   • 下線②では利用者は攻撃者のWebサーバへ“HTTP”で接続しています。TLSを用いていないため、そもそも証明書エラーが発生しません。
4. 結論
   • 以上より「HTTPで接続が開始されたから」という理由になります。

誤りやすいポイント

• 「攻撃者が正規の証明書を取得していた」と誤解しがちですが、今回はHTTP接続なので証明書は送られていません。
• HSTSがあれば初回からHTTPSを強制しエラー表示になりますが、未実装である点を見落とすと理由を誤ります。
• 「自己署名証明書だから警告が出なかった」と考える受験者もいますが、自己署名であってもHTTPSなら警告が出ます。本件はHTTPゆえ警告フェーズ自体が存在しません。

FAQ

解答の論理構成

• 要求2は、偽サイトに誘導された場合でも「メールサービスPへの不正アクセスを防ぐこと」を求めています（原文引用: “要求2　手口Gに限らず、偽サイトにアクセスしてしまったときにフィッシングの手口によるメールサービスPへの不正アクセスを防ぐこと”）。
• しかし本文には“③OTP認証方式を利用し、かつ、登録処理を正しく行ったとしても、要求2を満たすことができないおそれがある”と明記されています。すなわちOTPだけではフィッシング耐性が不十分であることを示唆しています。
• 図4によるとOTP認証は
  1. Webブラウザが“認証要求（利用者ID, パスワード）”を送信
  2. 認証サーバXが“OTP要求”を返却
  3. 利用者がOTPを入力し、Webブラウザが“OTP”を送信
     という流れで完結します。
• フィッシングサイトがこの流れをリアルタイムで“中継”すれば、攻撃者は利用者が入力したOTPを即座に本物の認証サーバXへ転送できます。OTPは使い捨てであっても有効時間内に一度だけ通ればよいため、攻撃者は正規セッションを取得し“メールサービスP”を操作できます。
• したがって③が示す「OTPであっても防げないおそれ」とは「偽サイトがOTPを要求し、それをそのまま認証サーバXへ中継する」処理が成立する場合です。
• 以上より解答は「OTPの入力を要求し、OTPを認証サーバXに中継する処理」となります。

誤りやすいポイント

• 「OTPを盗む」だけでは不正アクセスは成立しません。重要なのは“リアルタイム中継”であり、攻撃者が正規サイトへ同時にアクセスする点を落としがちです。
• 「OTPを複数回入力」や「OTPを使い回す」と誤記しやすいですが、OTPは一度の中継で十分に悪用できます。
• 認証サーバXではなく“メールサービスP”へOTPを送ると誤解するケースがありますが、OTP認証を行うのは“認証サーバX”です。

FAQ

解答の論理構成

1. 鍵種別の整理
   • 図中であらかじめオーセンティケータに格納されている鍵ペアが「公開鍵A／秘密鍵A」。
   • 登録処理中にサービスごとに新規生成される鍵ペアが「公開鍵K／秘密鍵K」。
   • この区別を押さえると、どの工程でどの鍵が利用されるかが自然に決まります。
2. ｢署名Ｌ｣を生成・検証する鍵（図5）
   • 登録処理では、オーセンティケータ自身の真正性を示す必要があります。
   • そのためオーセンティケータはデバイス固有の｢秘密鍵A｣で署名Ｌを生成します。
   • 認証サーバＸは、受信した署名Ｌを｢公開鍵A｣で検証し、機器が真正であることを確認します。
   • よって
     ・c＝｢秘密鍵A｣（ウ）
     ・d＝｢公開鍵A｣（ア）
3. ｢署名Ｍ｣を生成・検証する鍵（図6）
   • 認証処理では、利用者とサイトの組み合わせにひも付く鍵ペアＫでチャレンジレスポンスを行います。
   • オーセンティケータは保存しておいた｢秘密鍵K｣で署名Ｍを生成し、 認証サーバＸは登録済みの｢公開鍵K｣で署名Ｍを検証します。
   • よって
     ・e＝｢秘密鍵K｣（エ）
     ・f＝｢公開鍵K｣（イ）

誤りやすいポイント

• 図5と図6で“どちらの鍵ペアを使っているか”を混同しやすい。登録フェーズはA、認証フェーズはKと覚える。
• ｢公開鍵A／秘密鍵A｣と｢公開鍵K／秘密鍵K｣で、公開鍵と秘密鍵を逆に当てはめてしまうケアレスミス。
• ｢公開鍵A｣をサーバが取得済みである点を見落とし、検証鍵に｢公開鍵K｣を選んでしまう。

FAQ

解答の論理構成

• 要求2は「偽サイトにアクセスしてしまったときにフィッシングの手口によるメールサービスPへの不正アクセスを防ぐこと」と規定しています。
• 図6の認証サーバXの処理には「・オリジンbとオリジンsの一致を確認」という記述があります。
• ここで
  ・オリジンb：利用者がアクセスしているWebサイトのオリジン
  ・オリジンs：認証サーバXの正規オリジン
  です。
• フィッシングサイトは正規サイトとFQDN（オリジン）が異なるため、このチェックで不一致となり、署名検証以前に認証が拒否されます。
• よって「④パスワードレス認証方式を利用すれば、要求2を満たすことができる」の理由は
  「認証サーバXでオリジンbとオリジンsの一致を確認しているから」
  となります。

誤りやすいポイント

• OTPでも二要素だから十分と考え、オリジン確認がないことを見落とす。
• WebAuthnの安全性を「公開鍵暗号を使うから」とだけ説明し、フィッシング防止機構を具体的に示さない。
• オリジン確認をブラウザ側の処理と誤解し、サーバ検証の意義を軽視する。

FAQ