Log4Shellが生まれて3年、未だに蔓延中

いつもご覧いただきありがとうございます。

今回は、アプリケーションセキュリティプラットフォームを提供する Contrast Security の12月16日のマーケティング記事（ブログ）を意訳したものとなります。意訳後に記事に関する考察を述べています。

Log4Shell: Three years later & Log4j is still burning down the house
Log4Shell： 3年後＆Log4jはまだ家を燃やしている

3年前（2021年）の今月、セキュリティ業界はLog4jライブラリにおける重大な脆弱性を発見しました。Log4Shell攻撃はその数時間後には始まり、現在も続いています。驚くべきことに、多くの組織が未だにこの問題を修正していないためです。

なぜこの問題は消えないのでしょうか？

Log4Shellは当時、最大のサイバー攻撃でした。現在でも「トップ10の攻撃」のリストに登場します。その影響は計り知れず、専門家によれば、おそらく史上最も広範囲に広がった脆弱性です。この脆弱性はCVE-2021-44228として公式に識別され、共通脆弱性評価システム（CVSS v3.1）で10点満点中の10点という重大度スコアを持っています。

「不幸な誕生日おめでとう、Log4Shell」。以下に、この脆弱性の歴史とその依然として広がっている現状、そして専門家が考える「なぜこの不死身の脆弱性を完全に排除するのが難しいのか」という理由を紹介します。

Log4Shellの簡単な歴史

中国のeコマース企業Alibabaのセキュリティ研究者、陳兆軍（Chen Zhaojun）氏が、Log4Shellの脆弱性を初めて発見し、2021年11月24日にApache財団（オープンソースプロジェクト）に報告しました。Apacheは迅速に2021年12月6日にLog4jバージョン2.15のパッチをリリースしました。しかし、このパッチでは脆弱性の一部が修正されないままでした。

その後、Apacheの研究者は2021年12月9日にMinecraftサーバーへのLog4Shell攻撃を発見し、サイバー犯罪者が少なくとも12月1日からこの脆弱性を発見し悪用していたことを突き止めました。

その後数週間にわたり、ApacheはLog4jの追加パッチをリリースしましたが、それらにも脆弱性が残っていました。バージョン2.17.1以降であれば、Log4Shellおよび関連する脆弱性は存在しませんが、サイバーセキュリティ・インフラセキュリティ庁（CISA）は、2024年11月に発表した報告書で、2023年にLog4Shellが依然として最も一般的に悪用された脆弱性のトップ15に含まれていたと述べています。

数字で見るLog4Shell

Contrastの調査によると、Log4Shellが発見されてから3年経った現在でも、Javaアプリケーションの12%が脆弱なバージョンのライブラリを使用しています。この割合は、発見から1年後に約50%が脆弱なバージョンを使用していたときに比べて低下していますが、それでも12%は依然として何百万もの攻撃の可能性を残しています。

この脆弱性が依然として存在している理由の一つは、開発者が未だに脆弱なバージョンのLog4jをダウンロードしているためです。Sonatypeが発表した月次ダウンロードデータによると、2024年7月時点でも、Log4jを使用する開発者の13%が依然として脆弱なバージョンをダウンロードしており、それらすべてがLog4Shell攻撃に対して脆弱であるとされています。

依然として標的にされるLog4j

Contrast Securityは毎月、Log4jの脆弱性を悪用しようとする犯罪者を検出し、阻止しています。同社の技術は、プローブ（探索行動）と攻撃の両方を監視しています。検出される異常の大部分はプローブであり、攻撃者が弱点や構成ミス、悪用可能な脆弱性を探る行為を指します。これらのプローブは、攻撃者がこの脆弱性を依然として重大な問題と認識しており、WAF（ウェブアプリケーションファイアウォール）を通過して探索を続けていることの最初の証拠です。

Contrast Securityのデータによれば、2024年11月だけでも、攻撃者は1つのアプリケーションあたり4,000件以上のプローブを実行しました。

通常、犯罪者はプローブで脆弱性を確認すると、攻撃を開始します。Contrast SecurityはアプリケーションやAPIを計測しているため、同社のデータは署名や理論上の攻撃ではなく、実際に発生した証拠に基づく攻撃のみを反映しています。

2024年11月、Log4jの脆弱性を悪用した攻撃はアプリケーションあたり平均2.29件記録されました。Contrastがこれらの攻撃を阻止しなければ、犯罪者はその後に実際の攻撃を実行することが可能だったでしょう。

Contrast Securityの月次攻撃報告書では、2024年11月に検出されたすべての攻撃が確認できます。

Log4jの脆弱性は今でも問題か？

Contrast SecurityのCISO（最高情報セキュリティ責任者）David Lindner氏とプロダクトセキュリティディレクターのNaomi Buckwalter氏は、Log4Shellが依然として潜在的な危険である理由を次のように説明しています。

「エンタープライズアプリケーションのコードベースは膨大です。数百、場合によっては数千ものサードパーティ依存関係を使用しており、それらがさらに多くの推移的依存関係を持っています」とLindner氏は述べています。「開発者はすべてのコードの詳細を把握しているわけではないため、Log4jは多くのアプリケーション内で開発者の認識外に隠れている可能性があります。」

「3年経った今、業界はLog4jへの注目を他の脆弱性に移してしまいました」とBuckwalter氏は同意します。「この破壊的な脆弱性は現在も標的にされていますが、もはや主要な焦点ではないため、セキュリティチームや開発者はこれを見過ごしがちです。」

なぜ排除が難しいのか？

絡み合った依存関係
依存関係は直接的なものだけでなく、Log4jが別のライブラリの一部として含まれる推移的な依存関係も存在します。
「エンタープライズソフトウェアには、推移的依存関係の層が何層にも重なっています」とBuckwalter氏は説明します。「開発チームが作成したカスタムコードはサードパーティコードを使用し、そのコードもさらに別のコードを使用している、というように続きます。カスタムコードが明示的にLog4jライブラリを使用していなくても、そのコードを支えるコードが使用している可能性があります。Log4Shellの脆弱性は、開発者が気づかないうちに使用しているソフトウェアに存在する可能性があります。」

隠れたコンポーネント
多くの組織がLog4Shellに対応するため、コードリポジトリをスキャンして脆弱なバージョンの参照を探しました。しかし、多くのライブラリはコードリポジトリには存在せず、アプリケーションやAPIサーバーに組み込まれているか、ランタイムで動的にロードされるモジュールやプラグインの一部となっています。これらのライブラリは、完全に組み立てられた実行中のアプリケーションを分析しなければ発見できません。

不十分なパッチ
初期のLog4Shellのパッチは不完全で、その後の脆弱性を招き、さらなるアップデートが必要になりました。一部のシステムは未だに未修正、あるいは誤って修正されている場合があります。Log4jは最も広く使用されているオープンソースのロギングライブラリの1つであるため、すべてのインスタンスを迅速に更新するのは困難です。その広範な使用により、未修正のシステムが少数でも、脆弱なインストールの数は非常に多くなります。
「Log4jの各インスタンスをアップグレードするときには、『壊れる修正』に遭遇します」とLindner氏は付け加えます。「つまり、それがアプリケーションを壊してしまうのです。そのため、新しいバージョンへのアップグレードが2時間で済む作業ではなく、数か月かかる場合があります。その結果、問題が発生するまで脆弱性が放置されることがよくあります。」

Log4Shell攻撃のリスクが高いのは誰か？

Log4jは世界中の数百万ものコンピュータアプリケーションで使用されており、Javaアプリケーションの約64%がこれに依存しています。

「誰もがLog4jの問題を抱えています。依然として広く存在する脅威です」とLindner氏は述べています。「厳しく規制されている業界は、より保護されているはずですが、そうではありません。この問題は無知によるものではなく、効率的に仕事を進めようとする人々の努力の中で何かが見落とされてしまうことが原因です。すべてが重要だとされると、何も重要でなくなってしまうのです」と説明しました。

Log4Shellを利用した攻撃の仕組みを詳しく理解したい場合は、「Anatomy of an Attack」を参照してください。

Log4jの脆弱性の検出と修正方法

Log4jの問題に対処するには、以下の3つの手順が必要です（詳細はLog4J CVEsへの対応の最新ガイダンスを参照してください）。

1. 脅威ハンティングを実施し、侵害の指標（IoC）を特定する
   Buckwalter氏は、過去のネットワークおよびSIEMログでJNDIネットワークトラフィックを調べることを提案しています。「Log4jが最初に話題になった2〜3年前のセキュリティ情報およびイベント管理（SIEM）ログを見直してください。過去に外部システムへのJNDI接続が大量に発生し、その後突然停止した場合、攻撃者がシステムを侵害した可能性が高いです」と述べています。「攻撃は攻撃者が諦めたから突然止まるのではありません。侵入に成功したから止まるのです。」

2. 侵害の指標（IoC）が悪意のあるものかどうかを確認し、必要に応じてパッチを適用する
   悪意のある活動を確認した後は、修正箇所を特定してパッチを適用します。

3. アプリケーションレイヤーの保護を使用して、悪意のある活動をブロックしながらパッチとアップグレードを実施する
   「ここでContrastのADR（Application Detection and Response）が重要な役割を果たします」とBuckwalter氏は述べています。「脆弱なルートがあり、攻撃が進行中の場合、そのソフトウェアを更新するか、攻撃をブロックしなければなりません。アップグレードには6か月以上かかることもあるため、その間、ContrastのADRが攻撃をブロックし、保護します。」

Contrast ADRはどのように保護を提供するのか？

ADR（Application Detection and Response）は、アプリケーション層内で深いリアルタイムの可視性と保護を提供します。これまで、リアルタイムの異常、攻撃、脆弱性を直接監視・分析する検出および対応ソリューションは存在しませんでした。

この技術により、組織のITインフラ全体で攻撃者の動きを追跡することが可能です。攻撃者は、組織の最も価値のあるデータに接続されたアプリケーションやAPIを標的にしますが、ADRを使用することで、攻撃の起点からの横移動を追跡し、持続的な侵害になる前に阻止することができます。

「ADRはアプリケーション層の大きなギャップを埋めます」とLindner氏は述べています。「『Shift left』は失敗でした。多くの企業にはセキュリティの債務と不安全なコードが溜まっています。ADRは、これまで存在しなかった運用中のアプリケーションを保護するための完璧なソリューションです。」

以上が、Contrast Security の記事の意訳になります。
　
　

この記事に関する考察

Log4Shellは、3年前（2021年12月）に話題となった Apache Log4jというJavaのログ出力ライブラリに存在した深刻な脆弱性です。
CVE-2021-44228、CVSSスコアは最高レベルの10.0、対象の Apache バージョンは、Apache Log4j 2.0から2.14.1となります。