情報処理安全確保支援士 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

解答の導き方

1. まず事実の確認です。本文には「ファイル共有機能でもWeb操作機能でもアクセスできない/rootディレクトリ配下のファイルも暗号化されていた。」とあります。
   これは、通常のSMBや一般利用者権限のWeb操作によるファイル操作では/root配下に到達できず、そうした操作でその領域を暗号化することはできないことを意味します。
2. 次に攻撃の痕跡です。本文には「外部からHTTPSリクエストを使用してOSコマンドを実行する攻撃ツール（以下、WebShellという）がNAS-Aに配置されており、OSコマンドが実行されたことが分かった。」ともあります。
   NAS上でOSコマンドが実行されていれば、root権限での操作やファイル属性変更を行い、/root配下のファイルを暗号化することが技術的に可能です。
3. 以上を合わせると、PCの通常のファイル共有／Web操作では届かない領域が暗号化されており、しかもNAS上でOSコマンドが実行された痕跡があるため、NAS自身がランサムウェアにより暗号化された可能性が高いと判断できます。要点は、PCからの通常のファイル操作ではアクセスできない領域のファイルが暗号化されていたことです。

誤りやすいポイント

• 共有ファイルが暗号化されている＝すぐにPC感染を結論付ける点。/rootの暗号化有無を必ず確認してください。
• 「/rootが暗号化されているからNAS単独感染と断定」すること。脆弱性やWebShellを経由して外部（PC等）からNAS上でroot権限を奪われる可能性はあり、完全に排除できません。
• アクセスログの見落とし（表3でGETに実行内容が残る一方、POSTの内容は分からない点）を軽視しないこと。
• 「一般利用者権限」と「root権限」を混同し、到達可能領域の誤認をしないこと。

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ページの<head>セクションに<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