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

解答の論理構成

1. 【問題文】には
   「ホスト名nas-aに割り当てているIPアドレスを変更するために、aレコードを更新する。」
   とあります。IPアドレスとホスト名の対応を書き換えるのは DNS の “A レコード” であるため、a には “ア：A” が入ります。
2. 続けて
   「そのレコードの**b**は、300秒に設定されていた。」
   とあります。DNS レコードにおける “300 秒” のような数値はキャッシュ有効期間を示す “TTL（Time To Live）” 値です。したがって b は “エ：TTL” になります。

誤りやすいポイント

• 「IP アドレスを書き換える＝MX レコード？」と混同しやすいですが、MX はメール交換用のレコードでありホスト名と IP アドレスの紐付けには使いません。
• TTL の概念を「DNS サーバ自身の生存時間」と誤解して TTY や TLS を選択してしまうケースがあります。TTL はキャッシュの寿命です。
• ダイナミック DNS という用語から TXT レコード（Let’s Encrypt などの DNS での所有確認に利用）を連想し誤選択することがあります。

FAQ

解答の論理構成

• 【問題文】表2には「UPnP機能　LAN側：有効」とあり、さらに下線①として「WAN側は、本機能を有効にできない仕様になっている」と記載されています。
• UPnPは「認証なしでリクエストを受け付ける仕様のプロトコル」であり、LAN側の機器が「ポートフォワーディングの設定とファイアウォール機能の設定を行う」と説明されています。
• したがって、WAN側でもUPnPが有効になれば、インターネット上の攻撃者が認証なしでルータ-Aに UPnP リクエストを送信し、任意の「ポートフォワーディング」や「ファイアウォール機能」の変更を行えます。
• その結果、「インバウンド通信：全て拒否¹）」という本来のファイアウォール設定を形骸化させ、外部からLAN側機器へのアクセスを許可してしまう危険が生じます。
• よって、ルータ-Aの設定が外部から書き換えられ、LAN側への不正通信を許可してしまうことが問題となります。

誤りやすいポイント

• 「UPnP＝便利機能」とだけ捉え、認証なしで設定変更が可能というリスクを見落とす。
• 「ポート開放」だけに意識が向き、ファイアウォール規則自体も変更され得る点を失念する。
• WAN側 UPnP の危険性を「設定漏えい」や「DoS」などと誤解し、通信経路の開放という本質を外す。

FAQ

解答の論理構成

• 【問題文】には「ファイル共有機能でも Web 操作機能でもアクセスできない/root ディレクトリ配下のファイルも暗号化されていた。」とあります。
• /root は NAS-A のローカル OS で root 権限を持つプロセスしか書換えできない領域です。
• 一方、A 社の PC からのアクセスは「ファイル共有機能」または「Web 操作機能」を経由します。これらはユーザ権限で公開された共有ディレクトリに限定され、/root には到達できません。
• にもかかわらず /root が暗号化されていた事実は、暗号化処理が NAS-A 内部で実行されたことを示唆します。
• したがって、下線②の判断「A 社のPC がランサムウェアに感染したのではなく、NAS-A 自体がランサムウェアに感染した」が導かれます。

誤りやすいポイント

• 「英語で書かれた脅迫文のテキストファイル」が NAS-A にあったことを主因と誤解する。脅迫文は PC からも書込めるため決定打ではありません。
• 「ファイル名が変更された」だけで PC ではなく NAS と決め付ける。これは共有フォルダ越しでも起こり得ます。
• /root ディレクトリの特殊性を忘れ、SMB や Web 操作で閲覧できると勘違いする。

FAQ

解答の論理構成

1. 図2の説明には「URLに “..%2f” を使用した攻撃手法であり、c と呼ばれる。」とあります。
2. “..%2f” は URL‐エンコードされた “../” であり、上位ディレクトリへ移動して本来アクセスできない場所を参照する典型的な不正要求です。
3. 「../」を使ってディレクトリを横断する攻撃は一般に「パストラバーサル」（Directory Traversal）と呼ばれます。
4. よって c には「パストラバーサル」が入ります。

誤りやすいポイント

• 「ディレクトリトラバーサル」など英語直訳風に書いてしまうと日本語表記が設問とずれる恐れがあります。
• SQL インジェクションや OS コマンドインジェクションと取り違えるケースがありますが、問題文の “..%2f” という相対パス記法が決め手です。
• URL エンコード (%2f) に目を取られて「URL デコード攻撃」と誤記する例もあります。

FAQ

解答の論理構成

1. 【問題文】では、脆弱性2について「任意のOSコマンドを実行できてしまう」と記載されています。
2. さらに図2の説明文に「これは、dと呼ばれる攻撃手法である。脆弱性1と脆弱性2を組み合わせると、認証なしで任意のOSコマンドの実行が可能になる。」とあり、攻撃手法の名称を尋ねています。
3. 任意のOSコマンドを攻撃入力に混入させて実行させる典型的な手法は「OSコマンドインジェクション」です。
4. よって d には「OSコマンドインジェクション」が入ります。

誤りやすいポイント

• SQL や LDAP など他のインジェクション系攻撃と混同してしまう。OS コマンドの実行が書かれている点を見落とすと誤答しやすいです。
• 脆弱性1と脆弱性2の組合せに気を取られ、ディレクトリトラバーサル（パストラバーサル）と早合点してしまうケースがあります。
• 図2のPOST例「ping 127.0.0.1;whoami」を読まずに解答を決めてしまい、キーワードを特定できないことがあります。

FAQ

解答の論理構成

1. 原因となった脆弱性
   問題文は「脆弱性1」において「URLに『..%2f』を使用したcと呼ばれる攻撃手法」で除外リストを迂回できると示しています。..%2f は URL エンコードされた ../ であり、まず「URLデコード」を行わないとパス名の実体が見えません。
2. パッチＭで追加された処理
   「パッチMでは、脆弱性1の対策として、認証なしアクセスの処理の流れにパス名の正規化の処理を加え、さらに、図3に示す順序にした」とあります。
   つまり従来の「URLデコード → 除外リストとの比較」という 2 段階に「パス名の正規化」を挟み、3 段階化したことが読み取れます。
3. 処理の正しい並び順
   a) URL 文字列をデコードして本来のパスを得る
   b) ../ などの相対記法を取り除く「パス名の正規化」を実施
   c) 正規化済みパスを「除外リストとの比較」でチェック
   以上より、e は「ア：URLデコード」、g は「イ：除外リストとの比較」が妥当です。
4. 模範解答との一致
   提示された「模範解答」で e: ア、g: イ と示されており、論理的にも整合します。

誤りやすいポイント

• 正規化の位置を誤り「URLデコード→除外リスト→正規化」と考えてしまう。先に比較すると ../ を含む異常パスを見逃す原因になります。
• 「パス名の正規化」を単なる大文字・小文字変換と混同し、不要と判断してしまう。
• URLエンコードとパーセントエンコードの呼び名の違いで迷い、選択肢を取り違える。

FAQ

解答の論理構成

1. 【問題文】は、まず表3の結果について
   　「表3からは、GETメソッドを使用して実行されたOSコマンドの内容は分かったが、③POSTメソッドを使用して実行されたOSコマンドの内容は分からなかった」
   　と明示しています。
2. ここから「GET はリクエスト行の URL 部にパラメータが入り、そのままログへ出力される」一方で、「POST はメッセージボディにパラメータが格納される」ため、多くの Web サーバは標準設定ではボディをアクセスログに記録しません。
3. したがって、POST で送られた「cmd=～」などの実際の OS コマンドはログに残らず、閲覧できなかったことが “分からなかった” 理由になります。
4. よって解答は「POSTメソッドで送信したボディがアクセスログに残っていなかったから」となります。

誤りやすいポイント

• 「WebShell が暗号化したので内容が読めない」と勘違いし、ログと暗号化を混同する。
• 「ステータスコードが 200 なので問題ない」と判断し、ログ出力対象を意識しない。
• GET と POST のパラメータ送信箇所（URL かボディか）を覚えていても、サーバ側の “ログに残る部分” まで連想できない。

FAQ

解答の論理構成

1. 問題文は、攻撃者が「“tarコマンドのオプションを悪用”」して root 権限を取得し、書込み不可ディレクトリを変更して WebShell を配置したと説明しています。
   • 引用：「K氏は、“攻撃者が、Web管理機能の脆弱性とtarコマンドのオプションを悪用し…WebShellを配置した後、WebShellを使用してランサムウェアを実行した”と推測した。」
2. その原因は、図4に示される sudoers 設定により、一般権限の www アカウントでも tar を無制限に root で実行できる点です。
   • 引用：「製品Xでは、sudoコマンドの設定ファイルが図4のようになっている。」
   • 図4の内容：「www ALL＝NOPASSWD：/bin/tar」
3. さらに、tar には「任意のOSコマンドを実行できるオプション」が存在し、ファームウェア更新では本来不要と明示されています。
   • 引用：「このtarコマンドには、任意のOSコマンドを実行できるオプションがある。ただし、ファームウェアのアップデート時にこのオプションは使用していない。」
4. よって、root 化を防ぐには、sudo で実行を許可する tar に「安全なサブコマンド・オプションだけ」を許可し、危険なオプションを拒否する必要があります。
5. したがって、「sudoコマンドの設定ファイルで、tarコマンドのオプションを受け付けないように設定する」という解答になります。これは sudoers のコマンド指定（/bin/tar --safe-opts などの形）で実現でき、ファームウェア更新の必要最小限に限定できるため適切です。

誤りやすいポイント

• 「tar を sudo から完全に外す」とするとファームウェア更新機能まで停止してしまう。必要最小限のオプション許可という視点を忘れがちです。
• WebShell削除や UPnP 無効化だけでは「tar での権限昇格」を根本的に塞げない点を見落とすことがあります。
• tar バイナリを削除／リネームなど OS 依存の対症療法を書くと、運用品質を損なうため減点対象になりやすいです。

FAQ

解答の論理構成

1. 問題文の確認
   • 「インターネットの検索エンジンで検索されないようにするために、各Webページのセクションに<meta name="robots" content="h">を記載することを検討した。」とあります。
   • ここで h には検索エンジンに対して「ページをインデックスしないでほしい」という指示を与える値を入れる必要があります。
2. 検索エンジンが理解する代表的なディレクティブ
   • noindex … 検索結果に表示しないよう指示する。
   • none … noindex, nofollow と同義で、やはり検索結果に表示されません。
   • nofollow や noarchive はインデックスの制御とは異なる目的なので本問の意図に合いません。
3. 結論
   • インデックスさせない代表語として「noindex」あるいは同義語の「none」が該当し、模範解答でも「h：・noindex　・none」と示されています。

誤りやすいポイント

• 「nofollow でもクロールされなくなる」と誤解するケース。nofollow はリンクの評価を渡さない指示であり、ページ自体のインデックス抑止にはなりません。
• robots.txt と meta robots を混同し、ディレクティブ名を誤記するケース。robots.txt はサーバ側ファイル、meta robots はページ内タグです。
• noindex と no-index のようにハイフンを挿入してしまう記述ミス。

FAQ