情報処理安全確保支援士試験 令和6年度 春期 午後 問1
さて、この解説シリーズもいよいよ最終回！今回は【設問3】に挑みます。テーマは「新たな脆弱性への対応」。サービスリリース後に発覚した、パッチがまだ提供されていないオープンソースライブラリの脆弱性（いわゆるゼロデイ攻撃に近い状況）に、どう立ち向かうか？という、非常に実践的なシナリオです。
【採点講評】では、設問3(1)の「脆弱性の存在を判断するための仕組み」を問う問題の正答率が低かったと指摘されています。 これは、攻撃の流れを正確に理解し、それをどうやって検証に落とし込むかという応用力が問われた証拠です。
この記事で、インシデント対応の思考プロセスをしっかり学び、ライバルに差をつけましょう！
【出典：情報処理安全確保支援士試験 令和6年度 春期 午後 問1（一部、加工あり）】
[セキュリティの強化]
G社は、試用モニターへのサービスYの提供期間中に、インシデント対応に必要なログの取得方法を検討することになり、F社と協議した。
F社によれば、ログ取得モジュールを実装するには時間が掛かるが、ログ取得モジュールを実装しなくても、サービスNを導入することによって、通信ログを取得できるという。
サービスNにおけるWAFルールの記述形式を図5に示す。
Rさんは、サービスNのSシステムへの導入を責任者に提案し、承認を得た。サービスNの導入完了後、サービスYの提供を開始した。
[新たな脆弱性への対応]
数週間後、ライブラリHというオープンソースのライブラリに脆弱性Vという脆弱性があることが公表された。Rさんは、脆弱性Vについての関連情報を図6のように取りまとめた。
Rさんは、脆弱性Vへの対応方針をZ氏に相談した。Z氏は、F社の回答を待ってからの対応では遅いので、システムに影響を与えない検証コードをSシステムに対して実行し、外部から脆弱性Vを悪用できるか検証するよう提案した。Rさんは、Z氏の協力の下、図7に示す手順で検証を実施した。
検証の結果、外部から脆弱性Vを悪用できることが確認できた。この結果を踏まえて、Rさんは、脆弱性Vを悪用する攻撃に備え、E社からWAFルールが提供されるまでの間、現在判明している悪用パターンに対応可能な暫定的なWAFルールで攻撃を遮断することにした。
Rさんが考えたWAFルールの案を表6に示す。
Rさんは、例えば”jnDI”のように大文字・小文字を入れ替える手口によって、ルール1と2それぞれで、案のパターンを回避する方法があることに気付いた。④このような手口にも対応できるように案を変更した。その後、変更後の案の確認をZ氏に依頼した。
Z氏は、⑤本番運用開始後の一定期間においては、WAFルールの動作には”検知”を設定して、サービスYが今までどおり利用できるかを確認することを助言した。Rさんは、Z氏の助言を踏まえて、WAFルールを設定した。
後日、Sシステムでは、ライブラリHを利用しているとの回答がF社からあった。また、E社からサービスNにおけるWAFルールが提供された。その後、脆弱性Vを修正したバージョンがライブラリHの公式Webサイトで配布され、Sシステム内のライブラリHのバージョンを最新にすることで、脆弱性Vへの対応が完了した。
【設問3】未知の脆弱性「脆弱性V」への対応
サービスYの提供開始後、Sシステムが利用している可能性のあるライブラリHに、深刻な脆弱性「脆弱性V」が発見されました。パッチや公式な対策がまだない中、迅速かつ的確な対応が求められます。
脆弱性Vの概要：JNDI Lookupを利用したリモートコード実行（RCE）
問題文を読むと、この脆弱性Vは、過去に世界中を震撼させた「Log4Shell」と非常によく似た特徴を持っています。
- 攻撃手法: 攻撃者は、jndi:ldap://…のような特殊な文字列（攻撃コード）をHTTPリクエストのヘッダに含めて送信します。
- 脆弱性の挙動:
- 脆弱性のあるサーバ（Sシステム）は、この攻撃コードを解釈し、攻撃者が用意したLDAPサーバに問い合わせてしまいます。
- 攻撃者のLDAPサーバは、悪意のあるJavaクラスファイル（Jファイル）の場所（URL-J）を返します。
- Sシステムは、そのURL-JにアクセスしてJファイルをダウンロードし、実行してしまいます。
- 影響: 結果として、攻撃者はSシステム上で任意のコマンド（コマンドC）を実行できる（リモートコード実行：RCE）という、極めて深刻な事態に陥ります。
(1) 脆弱性は本当に存在する？検証方法を考えよ！
【設問3 (1)】 図7中の下線③について、テストサーバに実装する仕組みを、35字以内で具体的に答えよ。
問題文の該当箇所
- 検証の目的: Sシステムで外部から任意のコマンドが実行できるか（脆弱性を悪用できるか）を確かめる。
- 検証で実行するコマンド(図8): wget http://a2.b2.c2.d2/index.html
- これは、テストサーバ（IPアドレス: a2.b2.c2.d2）上にある index.html ファイルをダウンロードせよ、という命令です。
- 確認したいこと: このコマンドがSシステムで本当に実行されたことを確認する仕組み。
解答
テストサーバのindex.htmlへのアクセスを記録し、確認する仕組み
思考プロセス：【採点講評】で差がついた最重要問題！
この問題の正答率が低かったのは、「攻撃の流れ」と「検証の流れ」を頭の中で繋げられなかった受験者が多かったからだと考えられます。ポイントは、「コマンドが実行されたら、何が起きるか？」を想像することです。
- Rさん（防御側）は、検証コードをSシステムに送信します。
- もしSシステムに脆弱性Vが存在すれば、Sシステムは検証コードを解釈し、最終的にコマンドC、つまり wget http://a2.b2.c2.d2/index.html を実行します。
- このコマンドが実行されると、Sシステムのサーバから、テストサーバ（a2.b2.c2.d2）に対して、index.html をくださいというHTTPリクエストが飛んできます。
つまり、脆弱性が存在する証拠 = テストサーバへのHTTPアクセス となります。
したがって、Rさんがテストサーバに実装すべき仕組みは、この「証拠」を掴むためのものです。具体的には、テストサーバのWebサーバ機能で index.html へのアクセスログを監視し、Sシステムからのアクセスがあったことを記録・確認できるようにすれば良いのです。
(2) WAFで攻撃を止める！どこを監視すべき？
【設問3 (2)】 表6中の (e)、(f)に入れる適切な字句を、図5中から選び答えよ。
問題文の該当箇所
- 攻撃コードの場所: 攻撃コードは「HTTPリクエストの x-api-version ヘッダの値として指定」される。
- WAFの検証対象（図5の選択肢）: GET, POST, PUT, ANY, Header, COOKIE, Multipart など。
解答
(e) Header (f) Header
思考プロセス
WAFで防御ルールを設定する際の基本は、「どこを（検証対象）」「どんなパターンで（パターン）」「どうするか（動作）」を決めることです。 この設問では「どこを」の部分が問われています。
問題文に、攻撃コードは「x-api-versionヘッダの値」として送られてくると明確に書かれています。
したがって、WAFが監視すべき場所はHTTPリクエストのヘッダ部分です。図5の選択肢から、ヘッダ全体を検証対象とする「Header」を選ぶのが正解です。
ルール1（jndiを検知）もルール2（ldapを検知）も、どちらも同じ攻撃コードに含まれる文字列を対象としているため、検証対象は両方とも Header となります。
(3) WAFルールをすり抜けるな！パターンを強化せよ！
【設問3 (3)】 本文中の下線④の変更後の案について、表6中のルール1に記述すべきパターンを、図5の記述形式で答えよ。
問題文の該当箇所
- 回避手法: “jnDI”のように大文字・小文字を入れ替える手口で、現在のパターン（WjndiW）を回避される可能性がある。
- 正規表現の仕様: [xyz]（いずれかの文字）、x|y（どちらかの文字）などが使える。
解答
¥W[jJ][nN][dD][iI]¥W （または ¥W(j|J)(n|N)(d|D)(i|I)¥W など）
思考プロセス
攻撃者が用いる典型的なWAF回避手法の一つが、大文字と小文字の組み合わせを変えることです。単純な文字列マッチング（jndi）では、JndiやjNdiといったパターンを見逃してしまいます。
これに対応するには、正規表現を使って「大文字・小文字を区別しない」マッチングを行う必要があります。図5で示された正規表現の記述形式を使うと、いくつかの書き方が考えられます。
- [ ] を使う方法: 各文字について、[jJ] のように大文字と小文字の両方を指定します。これを4文字分繰り返すと [jJ][nN][dD][iI] となります。
- | を使う方法: (j|J) のように、OR条件で大文字と小文字を指定します。これを組み合わせると (j|J)(n|N)(d|D)(i|I) となります。
公式の解答例では、iとlの混同（jndlなど）も考慮して [iI] の部分が [il] となっていますが、大文字・小文字の回避に対応するという設問の趣旨からは、上記のような解答で十分意図が伝わります。元のパターンにあった ¥W（非英数字）を前後に付けるのを忘れないようにしましょう。
(4) WAF運用の現実的な選択：検知か？遮断か？
【設問3 (4)】 本文中の下線⑤について、WAFルールの動作に”遮断”ではなく”検知”を設定することによる利点と、”検知”に設定した際に被害を最小化するために実施すべき内容を、それぞれ25字以内で答えよ。
問題文の該当箇所
Z氏は、⑤本番運用開始後の一定期間においては、WAFルールの動作には”検知”を設定して、サービスYが今までどおり利用できるかを確認することを助言した。
解答
- 利点: 誤検知による遮断を防ぐことができる。
- 実施すべき内容: アラートを受信したら攻撃かどうかを精査する。
思考プロセス
この設問は、WAF運用の現実的なトレードオフを理解しているかを問う問題です。【採点講評】でも「利点については、正答率が高かった」とあるように、ここは確実に得点したいポイントです。
- 利点（なぜ”遮断”しないのか？）
新しく作成したWAFルールが、もしかしたら正常な通信まで誤って攻撃と判断（誤検知／フォールスポジティブ）してしまうかもしれません。いきなり「遮断」モードにしてしまうと、正規ユーザーがサービスを使えなくなるビジネス影響が発生するリスクがあります。 そこで、まずは「検知」モード（監視モード）で運用し、「どんな通信がルールに引っかかるか」を安全に確認します。これにより、誤検知によって正常なサービス提供が妨げられるのを防ぐことができます。これが最大の利点です。 - 実施すべきこと（”検知”モードの弱点は？）
「検知」モードの弱点は、その名の通り、本物の攻撃も検知するだけで通してしまうことです。これではセキュリティ対策になりません。 したがって、「検知」モードで運用する際は、ルールに一致した通信（アラート）が発生したら、即座に運用担当者がその内容を分析・精査し、「本当に攻撃か、それとも誤検知か」を判断する必要があります。そして、もし本物の攻撃であれば、迅速に手動で通信を遮断するなど、次の対応に移って被害を最小化しなければなりません。
全体のまとめ
今回の設問3を通じて、私たちはゼロデイ的な脆弱性への対応フローを学びました。
- 情報収集と影響調査: 脆弱性の情報を正確に把握し、自システムへの影響を調査する。
- 検証: 攻撃コードを模した安全なコードで、実際に脆弱性を悪用可能か検証する。
- 暫定対策: パッチがない状況で、WAFなどを活用して攻撃を緩和・阻止する。この際、誤検知に注意し、検知モードから慎重に導入する。
- 恒久対策: 公式パッチがリリースされたら、速やかに適用し、根本原因を解決する。
APIセキュリティは、一度作って終わりではありません。常に新たな脅威が登場することを前提に、今回学んだような迅速な検知・分析・対応のサイクルを回していくことが、情報処理安全確保支援士には求められます。
これで【令和6年度 春期 午後 問1】の解説は終了です。この問題は、現代のWeb・APIセキュリティにおける重要テーマが凝縮された素晴らしい良問でした。ぜひ何度も復習して、考え方を自分のものにしてください！