HOME»情報処理安全確保支援士令和4年秋期»午後問題»午後Ⅰ 問1

情報処理安全確保支援士過去問題 令和4年秋期 午後Ⅰ 問1

⇄問題文と設問を画面2分割で開く⇱問題PDF

出題趣旨

製品開発においては，設計・開発時に十分なセキュリティ対策を行うことが重要である。脆弱性単体では発生し得る被害が小さいように見えたとしても，他の脆弱性と組み合わせられることで，より大きな被害が発生することもある。本問では，IoT製品の開発を題材に，開発者として脆弱性単体だけでなく，複数の脆弱性の組合せによって生じるリスクを特定する能力，及びアプリケーションプログラムのセキュリティ対策を策定する能力を問う。

設問1

    • a: DNSキャッシュポイズニング
    • b: エ
    • 権威DNSサーバからの応答よりも早く到達する。
    • サーバ証明書を検証し，通信相手がWサーバであることを確認する実装
    • c: コードサイニング
  • 〔aについて〕
    本文中の攻撃手法の名称について問われています。
    〔各機能のセキュリティ対策の検討〕に記載されている攻撃内容は、「DNSキャッシュサーバが権威DNSサーバにWサーバの名前解決要求を行ったときに，攻撃者が偽装したDNS応答を送信するという手法を使って攻撃を行う」というものです。DNSキャッシュサーバに誤ったIPアドレス情報を登録させ、利用者を偽のサーバに誘導するという特徴から「DNSキャッシュポイズニング」と判断できます。

    ∴a＝DNSキャッシュポイズニング

  • 〔bについて〕
    DNSキャッシュサーバが行う名前解決要求に使用されるプロトコル名が問われています。
    ARPとICMPでは上位層のプロトコルは何も使われないので、DNSの下位層に使用されるTCPまたはUDPが解答の候補となります。DNSの名前解決要求にはTCP/UDPのいずれも使用可能ですが、通常はコネクションレス型のUDPが使用されます。

    TCPであれば、コネクション通信でTCPコネクションを確立した通信相手のみのDNS応答しか受信しないため、攻撃者からの偽のDNS応答を受信することはありません。これに対して、UDPはコネクションレス通信で通信相手を確認しないため、攻撃者からの偽のDNS応答を受信してしまうリスクがあります。したがって、偽のDNS応答を受け入れてしまうのはDNSの名前解決要求をUDPを使って行った場合です。

    なお、上記のデメリットがあってもUDPが使用されている理由は、IPアドレスやドメイン名などの少量のデータが頻繁にやり取りされる名前解決要求では、オーバーヘッドの少ないUDPの高速性・効率性の優位性が勝るからです。

    ∴b＝エ：UDP

  • DNS応答が攻撃として成功するために満たすべき条件が問われています。
    DNSキャッシュポイズニングが成功する条件は下記になります。
    1. 偽のDNS応答が、DNS権威サーバの正規のDNS応答よりも早くDNSキャッシュサーバに送信すること
    2. DNSキャッシュサーバが正規の権威DNSサーバにDNS要求した時に、使用したIPアドレスとポート番号、DNSヘッダの識別子が一致すること
    3. キャッシュさせたい内容が、DNSキャッシュサーバのキャッシュに存在しない、またはキャッシュの有効期限が切れていること
    本文中に「DNSキャッシュサーバが通信プロトコルにbを使って名前解決要求を送信」と記載されています。DNSキャッシュサーバが権威サーバに名前解決要求を行うのは、DNSキャッシュサーバに有効なキャッシュが存在しない場合なので、これは上記の条件③を表わしています。

    次に、本文中に「攻撃者が送信したDNS応答が、当該DNSキャッシュサーバに到達できることに加えて」と記載されています。当該DNSキャッシュサーバに到達できるということは、DNS要求時に使用したIPアドレスとポート番号、DNSヘッダーの識別子が一致していることを示すため、上記の条件②を表わしています。

    残りは上記の条件①を満たすことでDNSキャッシュポイズニングが成功します。したがって、解答は「権威DNSサーバからの応答よりも早く到達する」になります。

    ∴権威DNSサーバからの応答よりも早く到達する。

  • DNSキャッシュポイズニングの被害を防ぐためのHTTPSの実装について問われています。
    フォームウェアアップデートに関して、図1の4.には「製品RからWサーバに対するフォームウェアアップデートの要求はHTTPSで行う」、また〔各機能のセキュリティ対策の検討〕には「製品Rは，Wサーバとの間の通信においてHTTPSを適切に実装している」と説明されています。

    製品RとWサーバのHTTPS通信が適切に実装されていれば、WサーバはTLSコネクションを確立するときにサーバ証明書を提示し、製品Rはその証明書を検証します。この検証は、証明書に含まれるサブジェクト代替名（SAN）やコモンネームが、Wサーバの完全修飾ドメイン名（FQDN）と一致するかを検証する手続きです。この手続きにより、製品Rは通信相手が正規のWサーバであることを確認できます。仮にDNSキャッシュポイズニングにより攻撃者のサーバに誘導された場合でも、攻撃者の用意したサーバの証明書の情報がWサーバのFQDNと一致しないため、不正な接続を防ぐことができるはずです（攻撃者はWサーバのFQDNのサーバ証明書を用意できません）。

    以上をまとめると、被害を防ぐために必要となるHTTPSの実装とは「サーバ証明書を検証し、通信相手がWサーバであることを確認する実装」が適切となります。

    ∴サーバ証明書を検証し、通信相手がWサーバであることを確認する実装

  • 〔cについて〕
    問題文では「ファームウェアの真正性を検証する」ための手段が求められています。「製品Rが証明書を検証する」とあるため、ファームウェア自体または関連する証明書が、信頼できる発行元（J社）のものであるかを確認する仕組みが必要です。ソフトウェアに対してデジタル署名を行い、これを検証することでソフトウェア開発者の身元の証明、なりすましや改ざんの検知を行う仕組みを「コードサイニング」、その検証に使用される証明書をコードサイニング証明書と言います。原理としてはサーバ証明書やクライアント証明書と同じで、開発者が認証局に対して申請を行い、発行された証明書をソフトウェアに組み込んで配布します。

    ∴c＝コードサイニング

設問2

    • d: シェルが実行するコマンドをパラメータで不正に指定できて
〔dについて〕
図3において/setvalueに渡されるパラメータと図4のIPアドレス設定を行うコマンドを見ると、図3中のパラメータ ipaddress が図4で設定されるIPアドレスに、パラメータ netmask が図4で設定されるサブネットマスクにそれぞれ対応しています。

図5中のパラメータは、図3と比べると";ping -c 192.168.1.10;"が追加されており、これが図4のIPアドレス設定を行うコマンドにそのまま渡されると、OSのシェル※に対して次の命令が発行されることになります。
ifconfig eth1 "192.168.1.101"; ping -c 1 192.168.1.10;"" netmask "255.255.255.0"
シェルはこの入力を、①eth1のIPアドレスを変更し、②192.168.1.10にpingを1回送る、と解釈します（netmask "255.255.255.0"は無視されます）。これにより、本来想定されていないpingが実行されることになります。攻撃者は、パラメータとして渡す文字列を変えることにより任意のコマンドを実行可能です。これが本文中で説明されている「IPアドレス設定機能には，任意のコマンドを実行してしまう脆弱性」です。

setvalueの処理の問題点が問われており、解答のパターンはいくつも考えられますが、模範解答のほかにも次のようなものであれば問題ないと思われます。
  • 任意のコマンドをシェルで実行されてしまう
  • パラメータを加工することで任意のコマンドを実行されてしまう
  • パラメータに記述されたコマンドをそのまま実行してしまう
∴d＝シェルが実行するコマンドをパラメータで不正に指定できて

※シェルは、ユーザーがOSに命令をするために使用するインタフェースです。windowsのPowerShell･コマンドプロンプト、macOSのターミナル、UNIX系のBshなどがこれに該当します。

設問3

    • 攻撃リクエストをPOSTメソッドで送信させるスクリプトを含むページを表示させる仕組み
    • e: 推測困難である
  • 脆弱性Bは「IPアドレス設定機能には，ログイン済みの利用者が攻撃者によって設置された罠サイトにアクセスし，利用者が意図せずに悪意のあるリクエストをWebアプリRに送信させられた場合に，WebアプリRがそのリクエストを受け付けて処理してしまう」と説明されています。いわゆるクロスサイトリクエストフォージェリ（CSRF）と呼ばれる脆弱性で、利用者が意図したリクエストかどうかを識別する仕組みをもたないWebアプリケーションが、外部サイトを経由した悪意のあるリクエストを受け入れてしまうというものです。

    クロスサイトリクエストフォージェリでは、ログイン状態の利用者を罠サイトに誘導し、利用者が意図しない特定のリクエストを標的サイトに送信させる攻撃です。製品Rは設定されたIPアドレスを使い、PCのWebブラウザからアクセスが可能なので、脆弱性Bを利用した攻撃者が/setvalueのエンドポイントに対して所定のパラメータを送信することにより、脆弱性Aを突いた攻撃を受けるリスクがあります。具体的には、攻撃者はログイン状態の利用者を罠サイト上に誘導し、そこに設置したHTMLフォームやスクリプトなどを通じて、このリクエストを送るよう利用者を仕向けます。問題文冒頭の製品Rの仕様には、IPアドレス設定機能について「製品Rに新しいIPアドレスを設定する。POSTメソッドだけを受け入れる」とあること、図3と図5のリクエストがPOSTメソッドで行われていることから、罠サイトから製品RへのリクエストはPOSTメソッドで行う必要があります。

    ∴攻撃リクエストをPOSTメソッドで送信させるスクリプトを含むページを表示させる仕組み
    <script>
    // 攻撃用のリクエストを自動で送信するコード例
    (function() {
    　// フォームを動的に作成
    　var form = document.createElement("form");
    　form.method = "POST"; // HTTP POSTメソッド
    　form.action = "https://192.168.1.100/setvalue"; // 標的サイトのエンドポイント

    　// 必要なパラメータを設定
    　var input1 = document.createElement("input");
    　input1.type = "hidden";
    　input1.name = "ipaddress"; // パラメータ名
    　input1.value = "192.168.1.101";

    　var input2 = document.createElement("input");
    　input2.type = "hidden";
    　input2.name = "netmask"; // パラメータ名
    　input2.value = "255.255.255.0\";ping -c 1 192.168.1.10;\""; // コマンドを含む値

    　// フォームにパラメータを追加
    　form.appendChild(input1);
    　form.appendChild(input2);
    　// フォームをページに追加して送信
    　document.body.appendChild(form);
    　form.submit(); // 自動送信
    })();
    </script>
  • 〔eについて〕
    クロスサイトリクエストフォージェリ脆弱性については、CSRFトークンをPOSTメソッドのパラメータに含め、それをWebアプリケーション側で検証することが根本的な対策となります※。CSRFトークンがもつべき特徴としては次の3つがあります。
    検証可能性
    各ユーザーセッションごと、またはリクエストごとに一意のトークンであること、そのセッションで発行された正しいトークンであるかどうか検証できること
    推測困難性
    推測や総当たり攻撃を防ぐために十分長くランダムな値であること、第三者に漏えいしないように設計されていること
    CSRFトークンはサーバ側で検証可能であることに加え、推測が困難でなければなりません。固定値、連番または短いトークン、ユーザ－IDやセッションIDに依存するトークンなど攻撃者が推測可能なものはトークンとして不適切です。

    ∴e＝推測困難である

    ※他にもセッションクッキーにSameSite属性を付与するなどの対策があります。

設問4

    • 脆弱性A: ア
    • 脆弱性B: オ
それぞれの脆弱性は次のようなものです。
OSコマンドインジェクション
Webページの入力項目にOSの操作コマンドを埋め込んでサーバに送信することで、サーバを不正に操作することが可能な脆弱性
クロスサイトスクリプティング（XSS）
攻撃者が悪意のあるスクリプトをWebサイトに埋め込むことで、そのスクリプトが他のユーザーのWebブラウザで実行されてしまう脆弱性
SQLインジェクション
Webページの入力項目にSQLクエリの一部を埋め込んでサーバに送信することで、データベースを不正に操作することが可能な脆弱性
コードインジェクション
外部から送信されたデータが、サーバやアプリケーション内でコードとして実行される脆弱性
クロスサイトリクエストフォージェリ（CSRF）
標的サイトでログイン状態にあるWebアプリケーション利用者を罠サイトに誘導し、罠サイトの設置されたハイパーリンクを踏ませたりスクリプトを実行させたりすることで、標的サイトでその利用者が意図しない操作を不正に行わせる攻撃
サーバサイドリクエストフォージェリ（SSRF）
攻撃者が踏み台のサーバを介して、本来は禁止されている外部または内部の他のリソースに不正にアクセスできる脆弱性
〔脆弱性Aについて〕
HTMLフォームの入力値に、OSのコマンドを埋め込まれた場合、サーバ上で任意のコマンドを実行させてしまう脆弱性なので、「ア：OSコマンドインジェクション」が該当します。

〔脆弱性Bについて〕
ログイン中の利用者を罠サイトに誘導し、罠サイトからの意図しないリクエストにより製品Rが不正に操作される脆弱性なので、「オ：クロスサイトリクエストフォージェリ」が該当します。

∴脆弱性A＝ア：OSコマンドインジェクション
　脆弱性B＝オ：クロスサイトリクエストフォージェリ
© 2014-　情報処理安全確保支援士ドットコム　All Rights Reserved.
▲
Pagetop