情報処理安全確保支援士 2022年 秋期 午後1 問01

解答の論理構成

• 問題文には「DNSキャッシュサーバが権威DNSサーバにWサーバの名前解決要求を行ったときに、攻撃者が偽装したDNS応答を送信するという手法を使って攻撃を行うケースがある。」と記載されています。
• 偽装した応答をキャッシュサーバに送り込み、誤った名前解決結果を保存させる攻撃は、一般に「DNSキャッシュポイズニング」と呼ばれます。
• さらに問題文は「この攻撃手法はaと呼ばれる。」と続いており、ここに該当する語を答えればよいことが分かります。
• したがって、解答は「DNSキャッシュポイズニング」となります。

誤りやすいポイント

• DNSリバインディングと混同する。リバインディングはブラウザを介した攻撃であり、キャッシュサーバを書き換える本問とは異なります。
• DNSスプーフィング（DNS偽装）を直接書く受験者がいますが、本問はキャッシュへの毒入れを強調しているため「DNSキャッシュポイズニング」が最適です。
• 問題文に「キャッシュサーバ」が明示されている点を見落とし、単に「DNSポイズニング」と答えてしまう。正式名称で解答する必要があります。

FAQ

解答の論理構成

1. 本文には「DNSキャッシュサーバが通信プロトコルにbを使って名前解決要求を送信し」とあります。ここに当てはまるのは、DNS標準のトランスポート層プロトコルです。
2. 一般的な名前解決要求は 53 番ポートで行われ、接続確立のない非同期通信方式を取ります。この特徴をもつのは「UDP」です。
3. DNS では TCP も利用されますが、それは「ゾーン転送」や「大きな応答を返す場合」など限定的なケースです。攻撃文脈で述べられている「偽装したDNS応答を送信する」という手法は、三者間ハンドシェイクが無い UDP の方が成立しやすいことと整合します。
4. 解答群のうち該当するものは「エ：UDP」であり、模範解答とも一致します。

誤りやすいポイント

• 「DNS ＝ TCP/53 も使う」という知識だけで「ウ：TCP」を選んでしまう。TCP ではコネクション確立が必要なため、本文で説明される容易な偽装攻撃と齟齬があります。
• ARP や ICMP はネットワーク層・データリンク層のプロトコルであり、「DNSキャッシュサーバが通信プロトコルに――を使って名前解決要求を送信」には当てはまりません。
• “DNS over HTTPS” や “DoT” など最新の保護手段を連想して混乱し、本質である従来の DNS 問い合わせプロトコルを見落とす。

FAQ

解答の論理構成

1. 攻撃の前提
   【問題文】では「攻撃者が偽装したDNS応答を送信するという手法を使って攻撃を行うケースがある」と述べ、これは典型的な DNS キャッシュポイズニング攻撃です。
2. 成功条件の列挙
   同じ段落に「攻撃者が送信したDNS応答が、当該DNSキャッシュサーバに到達できることに加えて、①幾つかの条件を満たした場合に成功する」とあります。
3. “幾つかの条件”の中身
   DNS は問い合わせごとに識別情報（トランザクションIDや送信元ポートなど）を付与し、その情報が一致した最初の応答を採用します。よって攻撃者は
   ・識別情報を推測し一致させる
   ・正規の応答より先に到達させる
   という二つのハードルを越える必要があります。
4. 本問で問われている条件
   ①の空欄は“条件の一つ”を 30 字以内で答える設問です。識別情報の一致と先着性のうち、より明快で 30 字以内に収めやすいのが「正規応答より先に届くこと」です。
5. 解答
   したがって「権威DNSサーバからの応答よりも早く到達する」となるわけです。

誤りやすいポイント

• 「トランザクションIDを一致させる」だけを書き、先着性を見落とす
• 「キャッシュが空の場合に限り有効」など条件を限定し過ぎる
• 「DNSSEC を使わないこと」など“回避策”を書いてしまう
• 30 字以内を超える長文を記述してしまう

FAQ

解答の論理構成

1. 攻撃シナリオの前提
   • 本文では、DNSキャッシュ汚染によって偽サイトへ誘導されるケースを想定しつつ、Fさんは
     「②『製品Rは、Wサーバとの間の通信においてHTTPSを適切に実装している』ので、この攻撃の影響は受けない」
     と判断しています。
2. “HTTPSを適切に実装”の意味
   • HTTPSの安全性は暗号化だけでなく、サーバ証明書の検証を行い「通信相手が真正か」を確かめる点にあります。
   • DNSが偽情報を返しても、デバイスが提示されたサーバ証明書を検証し、正当な“Wサーバ”の証明書と一致しなければ TLS ハンドシェイクが失敗し、ファームウェアはダウンロードされません。
3. 証明書検証以外の実装では不十分
   • 例えば暗号化のみや自己署名証明書の許容では、フィッシングサイトでも通信は成立してしまいます。
   • 従って「偽のファームウェアをダウンロードしない」条件を満たすには、証明書の妥当性確認が不可欠です。
4. 以上より、②の具体的な実装は
   「サーバ証明書を検証し、通信相手がWサーバであることを確認する」
   という記述が最も的確となります。

誤りやすいポイント

• 「HTTPSだから安全」として暗号化のみを連想し、証明書検証の工程を回答から漏らす。
• クライアント証明書相互認証と混同し、不要な“クライアント証明書の提示”を含めてしまう。
• 「IPアドレスが正しいかどうか」を確認すると誤解し、DNS上書きを見抜けると勘違いする。

FAQ

解答の論理構成

1. 本文には、攻撃者が W サーバ内部に侵入して「ファームウェアを直接置き換える」場合を想定し、G主任が
   「ファームウェアにcを導入しましょう。まず、製品Rではc証明書がJ社のものであることを検証します。その上で、検証されたc証明書を使って、ダウンロードしたファームウェアの真正性を検証しましょう。」
   と提案しています。
2. ここで求められているのは、 ・証明書を発行・検証して製造元を確認する
   ・証明書に基づきファームウェア自体の真正性（改ざん有無）を確認する
   という二段階を実現する仕組みです。
3. ソフトウェアの配布時に公開鍵基盤を用いてコードに署名し、受信側で署名を検証して改ざんやなりすましを防ぐ技術は「コードサイニング」と呼ばれます。
4. よって c に入る適切な字句は「コードサイニング」となります。

誤りやすいポイント

• TLS 証明書やサーバ証明書と混同し、「SSL証明書」「HTTPS証明書」などと書いてしまう。TLS は通信路の安全性を担保しますが、配布ファイルの改ざん検知までは行いません。
• 「デジタル署名」とだけ答えるケース。デジタル署名は技術要素ですが、ソフトウェア配布での具体的な運用概念としては「コードサイニング」を用いるのが正答です。
• 「公開鍵暗号方式」など広すぎる概念を書いてしまう。問題文は証明書の存在まで明示しており、具体的導入手法を問うています。

FAQ

解答の論理構成

1. 【問題文】では、図3の正常リクエストを受け取った setvalue が
   　「図3中のパラメータを含むコマンド文字列をシェルに渡す」と記述されています。
   　つまり、利用者入力がそのまま OS のシェルコマンドに埋め込まれる実装です。
2. 続けて、細工されたリクエスト（図5）では
   　ipaddress=...";ping -c 1 192.168.1.10;"...
   　というように複数コマンドを連結しています。
   　シェルは区切り文字 ; を解釈し、意図外の ping を実行してしまいます。
   　これは、パラメータで自由にコマンドを注入できる実装上の欠陥です。
3. 問題文の空欄 d は「setvalue の処理には、_____ しまうという問題点がある」と指摘しており、図5の例から「コマンドをパラメータで不正に指定できる」点が問題であることが明白です。
4. 以上より、d に入る字句は
   　「シェルが実行するコマンドをパラメータで不正に指定できて」
   　が適切となります。

誤りやすいポイント

• 「シェルコマンドを実行してしまう」だけでは、何が問題かを具体的に述べていないので減点対象になりがちです。
• 注入されるのは“パラメータ”経由である点を落とすと、単なる OS コマンド実行脆弱性の指摘として不十分です。
• 「SQL インジェクション」と混同しやすいですが、本問はシェルコマンドの連結であり OS コマンドインジェクションです。

FAQ

解答の論理構成

• 【問題文】には、罠サイト経由で「③図6の攻撃リクエストを送信させる」と明示されています。
• 図6のリクエスト先は /setvalue であり、【図1】の「IPアドレス設定機能」は「POSTメソッドによる入力だけを受け付ける」と記載されています。
• また脆弱性Bの説明は「ログイン済みの利用者が攻撃者によって設置された罠サイトにアクセスし、利用者が意図せずに悪意のあるリクエストをWebアプリRに送信させられた場合」とあり、典型的な CSRF（Cross-Site Request Forgery）の状況です。
• CSRF を成立させる代表的手法は、罠サイトに
  ①
  
  ② 必要なパラメータを hidden で埋め込む
  ③
  のようなコードを置き、ブラウザに自動で POST させる仕組みです。
• よって「攻撃リクエストをPOSTメソッドで送信させる仕組み」とまとめるのが適切です。

誤りやすいポイント

• 「リンクをクリックさせる」など GET を想定した回答にしてしまう。IPアドレス設定機能は POST 限定 のため不適切です。
• 「CSRF」とキーワードだけを書き、どのように送信させるかを具体的に述べない。設問は「仕組み」を要求しています。
• Java アプレットや Flash など古い技術名を書く。現行ブラウザで動作しづらく現実味が低いです。

FAQ

解答の論理構成

1. 本文では脆弱性Bへの対策として、 「利用者からのリクエストのパラメータに、セッションにひも付けられ、かつ、eという特徴をもつトークンを付与」
   と明記されています。
2. セッションに結び付いたリクエスト偽造対策といえば、代表的なのが CSRF トークン方式です。CSRF トークンの要件は、 • 外部の攻撃者が値を事前に知ることができない
   • 推測や列挙が現実的に不可能
   であることです。
3. したがって e に入るべき語は、攻撃者が値を当てられないことを表す「推測困難である」となります。
4. まとめると、セッション ID とペアで「推測困難である」トークンを検証することで、本文が示す脆弱性B（利用者の「意図せずに悪意のあるリクエストを…」）を防止できるため、解答は「推測困難である」と導かれます。

誤りやすいポイント

• 「セッションにひも付けられ」と並んでいるため「一意である」や「乱数である」などを記述してしまいがちですが、乱数でも推測可能な短い値では意味がありません。
• CSRF 対策と XSS 対策を混同し、「入力無害化」や「エンコード」と答えるケースがあります。
• 「秘密である」を選択する受験者もいますが、秘密性は必須条件の一部であり、問題が求めているのは外部から値を当てられない点＝「推測困難である」です。

FAQ

解答の論理構成

• 脆弱性Aの特徴
  • 【問題文】には「IPアドレス設定機能には、任意のコマンドを実行してしまう脆弱性がある」と明記されています。
  • さらに図5のリクエストでは ";ping -c 1 192.168.1.10;" という文字列がパラメータ中に混入しており、シェルに渡されたコマンド列に連結されることで想定外の OS コマンドが実行されます。
  • 以上より、利用者入力がシェルコマンドとして解釈・実行される「OS コマンドインジェクション」に該当します。
  • 解答群で該当するのは「ア：CWE-78 OSコマンドインジェクション」です。
• 脆弱性Bの特徴
  • 【問題文】では「ログイン済みの利用者が攻撃者によって設置された罠サイトにアクセス」し「利用者が意図せずに悪意のあるリクエストをWebアプリRに送信させられた場合に、WebアプリRがそのリクエストを受け付けて処理してしまう」と記述されています。
  • これは典型的な「利用者の認証済みセッションを悪用して不正リクエストを発行させる」攻撃であり、クロスサイトリクエストフォージェリ（CSRF）に一致します。
  • 修正策として「利用者からのリクエストのパラメータに、セッションにひも付けられ、かつ、eという特徴をもつトークンを付与」して検証する方法が採用されており、まさに CSRF トークンの導入です。
  • 解答群で該当するのは「オ：CWE-352 クロスサイトリクエストフォージェリ」です。

誤りやすいポイント

• 脆弱性Aを「コードインジェクション（エ）」と誤認する
  • コマンド文字列がそのまま OS シェルに渡る点に注目し、「プログラムコードの注入」と勘違いしやすいですが、実際には OS コマンドを注入しているため CWE-78 が正解です。
• 脆弱性Bを「クロスサイトスクリプティング（イ）」と混同する
  • 罠サイト経由というキーワードで XSS を連想しがちですが、利用者ブラウザでスクリプトが実行されるのではなく、認証済みリクエストが偽造される点が決定的に異なります。
• 修正策のトークンを「セッション ID」と思い込み、別概念と誤解する
  • CSRF トークンは「セッションにひも付けられ、推測困難」であり、ブラウザ自動送信の Cookie とは区別すべきものです。

FAQ