Log4jの表面的な背景問題
汎用性が高いプログラミング言語として未だ高い人気を誇り、いまや社会インフラのように浸透し、世界中に偏在するJava。このJavaで書かれたログ出力ライブラリ「Apache Log4j」（以下、Log4j）に、脆弱性が潜んでいた。
この脆弱性を突けば、攻撃者は簡単にサーバで任意のプログラムを実行させることができきる。WebサーバにApacheを使い、バックエンド処理にJavaを使っているシステムは、この脆弱性の対象となり得る。つまり、業務システムや企業ホームページ、ECサイトのほとんどが候補になるということだ。
とはいえ、すでにパッチも公開され、IPA（情報処理推進機構）やJPCERT コーディネーションセンターのサイトを見れば、脆弱性の発見方法や対策方法も調べることができる。自社に適切なCSIRT体制や専任のセキュリティ担当者がいれば、脆弱性の有無や対策方法もわかる。だが、セキュリティ担当者がいるからといって、システムのパッチや対策が問題なくできるかどうかは別の話だ。
このことも、Log4jの問題をややこしくしている。業務特化したシステムはOS、ミドルウェア、ライブラリの変更、セキュリティパッチの適用は簡単ではない。また、古いシステムで誰も（開発ベンダーでさえ）内容を把握できていないシステムが存在する。適切なIT管理者、セキュリティ担当者がいないこと（中小企業の多くが当てはまるだろう）も珍しくない。これらは、セキュリティパッチが公開されても攻撃が有効なため、攻撃者の格好の餌食となる。
なぜHeartbleedやシェルショックの再来と言われるのか
大きな問題になったのは、影響範囲の大きさに加え、攻撃が比較的簡単で実際に攻撃トラフィックも確認されているからだ。脆弱性の種類は「任意コードの実行」で、すでにランサムウェアを実行させようとする攻撃も確認されている。
攻撃者は偽のLDAPサーバ（ディレクトリサービスを行うサーバ）を立て、攻撃コードを仕込んでおく。後はLog4jの脆弱性のあるサーバに攻撃サーバを呼び出すリクエストを送ればよい。もともとは、どんなプログラム（スレッド）のログかを判別するのに、固定のコードより判別の拡張性を持たせるために外部コードを呼び出せるようにする機能を悪用するのだ。
Log4jが抱える問題は、技術的な深刻度だけではない。シェルショック（Linux・UNIX操作に必須の基本UIであるbashに発見された任意コード実行の脆弱性）やHeartbleed（暗号化通信やサーバ証明書の処理に必要なSSLプロトコルに潜んでいた脆弱性。鍵情報が盗まれる）の再来、いやそれ以上だ、といわれるのは、古くから存在するソフトウェアやシステム、あるいはプロトコルに潜んでいた脆弱性だからだ。
オープンソースソフトウェアであるApacheは、その原型（httpdというプログラム）を1995年までさかのぼることができる。一説にはLog4jの脆弱性（CVE-2021-44228、CVE-2021-45046）の外部コード呼び出し機能は2013年に実装されたという。
ApacheはASFという財団がプロジェクトを管理し、メンテナンスも行っている。枯れた技術である非常に安定したソフトウェアの1つだが、このような致命的な脆弱性がいまだに潜んでいたという事実に人々は驚かされた。
【次ページ】脆弱性がなくならない理由