情報処理安全確保支援士(情報セキュリティスペシャリスト) 試験情報＆徹底解説

RESTful APIは、WebサービスやAPIを設計するためのアーキテクチャであるREST(Representational State Transfer)の原則に基づいて設計されたAPIです。RESTful APIの設計原則は一般的とは次の4つをいいます。クライアントサーバ方式とオンデマンドコードの2つを追加して6原則とすることもあります。

統一インターフェイス

GET(取得)、POST(入力)、PUT(更新)、DELETE(削除)の4つのHTTPメソッドを使用して情報を操作する

アドレス可能性

サーバ上のデータやサービスは一意なURIによって識別する

ステートレス

サーバはクライアントの状態を保持せず、リクエストは独立して完結する

接続性

レスポンスとしてリソースの状態と操作可能なリンクを含む

「セッション管理を行わないという性質」ですから、空欄aには「ステートレス」が当てはまります。

ステートレスは、サーバはクライアントのセッション情報や過去のリクエストの状態を保存しないという性質です。クライアントから送信されるリクエストはそれ自体が完全な情報を持っていて、サーバはリクエストを受け取るたびにそのリクエストの内容だけをもとに処理を行います。これにより容易な負荷分散やシンプルなサーバ実装が可能となります。ステートレスとは逆に、サーバがクライアントの情報を保持し続け、その内容が出力にも反映される性質を「ステートフル」と呼びます。

∴a＝ステートレス

本問で題材となっている脆弱性Vは、Log4Shell（CVE-2021-44228）として知られるものです。Log4Shellは、Javaで書かれたオープンソースのロギングフレームワークであるLog4jに存在する脆弱性です。この脆弱性は、Javaアプリケーションが外部サーバにアクセスしてデータやオブジェクトをダウンロード＆実行する仕組みであるJNDIルックアップと、ログメッセージ中の変数をルックアップ置換するLog4jの機能を組み合わせて、外部から任意のコードを実行するものです。大まかな攻撃のシナリオとしては次のようになります。

1. リモートからLDAP経由で参照先を取得するJNDIコマンドを用意する。これは、$(jndi:ldap://・・・)という形式になる
2. 1.で用意したコマンドを、HTTPヘッダーのX-Api-Versionなどに含めて攻撃対象サーバに送信する
3. 攻撃対象サーバがHTTPヘッダーをログに記録する際、Log4jの機能により変数が置換えされる。この時にJNDIルックアップが実行される
4. LDAPサーバは、攻撃コードを含むファイルを参照先として返す
5. 攻撃対象サーバは、攻撃コードを含むファイルをダウンロードし、実行する

• 図8の文字列をパラメータに含むHTTPリクエストを攻撃対象サーバが受信すると、そのログが記録される際に「ldap://」で始まるURLで外部の攻撃用LDAPサーバにアクセスが行われます。図6の手順(4)～(6)にはその後、攻撃対象サーバでコマンドが実行されるまでの流れが説明されています。
  1. LDAPリクエストWから、デコードした状態のコマンドCを取り出す
  2. 攻撃用HTTPサーバに、コマンドCを実行するJavaクラスファイル（Jファイル）を配置する
  3. 攻撃対象サーバに、JファイルのURL（URL-J）を返す
  4. 攻撃対象サーバは、URL-Jにアクセスして、Jファイルをダウンロードし、記述されたコマンドを実行する
  図8で指定したコマンドCは「wget http://a2.b2.c2.d2/index.html」となっています（wgetは指定されたURLからファイルをダウンロードするLinuxのコマンドです）。テストサーバが図8のコマンドを受け取った場合、テストサーバ上に「wget http://a2.b2.c2.d2/index.html」を実行するJavaクラスファイルが作成され、それが攻撃対象サーバ上にダウンロードされて実行されることになります。
  
  一連の流れが成功すると、テストサーバ（a2.b2.c2.d2）の「index.html」にアクセスが発生します。このアクセスを記録・確認できる仕組みを実装すれば、指定したコマンドが攻撃対象サーバで実行されたことを確認できます。
  
  ∴テストサーバのindex.htmlへのアクセスを記録し，確認する仕組み
  
  
• 図5のWAFルールの記述形式を見ると、検査対象に指定できるのはGET等の7種類です。図6の手順(3)に「準備した攻撃コードをHTTPリクエストのx-api-versionヘッダの値として指定したHTTPリクエストを攻撃対象サーバに送信する」とあるように、この攻撃ではHTTPヘッダーに$(jndi:ldap://・・・)という形式の不正な値を指定することで、ログに書き込ませようとします。したがって、jndi、ldapのいずれもWAFの検査対象はヘッダー部であり、これを可能とするWAFルールの指定は「Header」となります。
  
  なお、x-api-versionは一例で、Referer、Accept-Language、Cookie、User-Agentなどのヘッダーフィールドも攻撃に使用されます。
  
  ∴e＝Header
  　f＝Header
  
  
• 現在のパターンである¥Wjndi¥Wは、"jndi"という小文字にのみマッチするため、1文字でも大文字が含まれるとマッチしません。大文字・小文字を問わずにマッチさせるには、jとnとdとiの4文字に分け、それぞれを大文字・小文字両方にマッチするように記述する必要があります。図5の正規表現のパターンを参考にすると、これを実現するには次の2つのいずれかを使うことになります。
  • x|y　x又はyとマッチする
  • [xyz]　x、y又はzのいずれかにマッチする
  大文字Jと小文字jのいずれかにマッチする正規表現は[jJ]または(j|J)と記述できるので、同様にnとdとiの文字を順に並べて[jJ][nN][dD][iI]または(j|J)(n|N)(d|D)(i|I)とすれば、それぞれの小文字または大文字とマッチするようになります。[Jj]→[Jj]のように大文字と小文字の前後は逆でも構いません。一応、¥W(jndi|Jndi|JNdi|JnDi|…|JNDI)¥Wというように全16パターンを全部記述しても正しく動作はします。
  
  補足として、前後に¥Wを付けているのは、英単語の一部に含まれているのではなく、"jndi"と単独で存在している場合にマッチさせる必要があるからです。また、実際の攻撃では変数を入れ子にして難読化するなどしてWAF回避策がとられますので、R氏が行った正規表現の変更は一時的な回避策という位置付けで、E社から網羅的な正規表現パターンが提供されたら、そちらを適用することになります。
  
  ∴¥W[jJ][nN][dD][iI]¥W 又は ¥W(j|J)(n|N)(d|D)(i|I)¥W
  
  
• 図5によると、WAFルールに指定できる動作には『許可』『検知』『遮断』があり、『検知』は「通信を通過させ，ログに記録し，管理者にアラートを送信する」、『遮断』は「通信を遮断し，ログに記録し，管理者にアラートを送信する」とあります。すなわち、『遮断』と『検知』の違いは、通信を通過させるか遮断させるかの違いとなります。
  
  セキュリティの観点からは、通信を遮断する方がより安全です。しかし、WAFルールに指定した「Header」では全てのヘッダーの値を検証対象とするため、誤検知が発生する可能性があると考えられます。必要な通信まで遮断されてしまった場合、サービスYの提供に支障を来たすおそれがあります。本来であれば、事前に十分なテストを行うことが望ましいですが、図6によると、すでに脆弱性Vが悪用された事例が報告されており、時間的な余裕がありません。このような背景より、WAFの動作を『検知』として通信は通過させつつも、ログへの記録と管理者へのアラート送信で攻撃を監視する折衷案を採用したものと考えられます。この設定により、サービスへの影響を抑えつつ、脆弱性を突いた攻撃への対策をとることができます。
  
  ∴利点：誤検知による遮断を防ぐことができる。
  
  次に、被害を最小化するために実施すべき内容ですが、『検知』は通信を通過させているので、もしその通信が攻撃だった場合、何も対策を講じなければ攻撃者に後続の攻撃を許してしまう可能性があります。このリスクを防ぐためには、検知された通信が攻撃であるかどうかを確認し、攻撃と判断された場合には適切な対処を実施する必要があります。検知した場合は管理者にアラートが送信されるので、アラートを受信したタイミングでその通信内容をチェックして攻撃であるかどうかを調べ、攻撃と判断した場合はしかるべき対応をとることが求められます。
  
  ∴内容：アラートを受信したら攻撃かどうかを精査する。