Log4Shell: 3年後も燃え盛るLog4j脆弱性の危険

3年前の今月、セキュリティ業界はLog4jライブラリに存在する巨大な脆弱性を知った。Log4Shell攻撃は数時間のうちに始まり、そして驚くべきことに、多くの組織が未だに対処していないため、攻撃は止んでいない。

なぜ、この脅威は消えないのだろうか？

Log4Shellは当時最大のサイバー攻撃であり、今日でも攻撃トップ10リストに名を連ねている。その影響は甚大で、全容はまだ解明されていない。専門家は、Log4Shellが史上最も広範囲に拡散した脆弱性である可能性が高いと指摘する。正式にはCVE-2021-44228として識別され、共通脆弱性評価システム(CVSS)のバージョン3.1では、10点満点の深刻度スコアが付けられている。

嬉しくないHappy birthdayのようだ、おめでとう、Log4Shell。以下では、この脆弱性の歴史と、Log4Shellがいかに蔓延しているかを示す数字、そして、このゾンビのような脆弱性を根絶するのがなぜ難しいのかについての専門家の見解を紹介する。

Log4Shellの簡単な歴史

中国のeコマース企業Alibabaのセキュリティ研究者であるChen Zhaojunが、Log4Shellの脆弱性を最初に発見し、2021年11月24日にApache Foundation(オープンソースプロジェクト)に報告した。

Apacheは2021年12月6日にLog4jバージョン2.15のパッチを迅速に発行した。しかし、このパッチでは脆弱性の一部が修正されなかった。その後、Apacheの研究者は2021年12月9日にMinecraftサーバーに対するLog4Shell攻撃を発見し、サイバー犯罪者が少なくとも2021年12月1日からこの脆弱性を発見して悪用していたことに気づいた。その後数週間、Apacheは脆弱性を含むLog4jのパッチをいくつかリリースした。2.17.1以降のバージョンはLog4Shellとその関連する脆弱性から解放されているが、サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)は2024年11月に、2023年もLog4Shellが最も悪用された脆弱性トップ15に入っていると報告した。

数字で見るLog4Shell

Contrastの調査によると、Log4Shellが発見されてから3年が経った今日でも、Javaアプリケーションの12%が依然として脆弱なバージョンのライブラリを実行している。この割合は、Log4Shell発見から1年後の約50%からは減少しているものの、12%でも数百万件の攻撃を受ける可能性がある。

この脆弱性が依然として存在する理由の一つは、開発者が脆弱なバージョンのLog4jをダウンロードし続けていることだ。Sonatypeが毎月公開しているダウンロードデータによると、2024年7月時点で、Log4jを使用している開発者の13%が脆弱なライブラリバージョンをダウンロードしており、すべてLog4Shell攻撃に対して脆弱である。

標的であり続けるLog4Shell

Contrast Securityは毎月、この脆弱性を悪用しようとする犯罪者を発見し、阻止している。我々の技術は、プローブと攻撃の両方を検知する。検知された異常の大部分はプローブ、つまり、攻撃者が弱点、設定ミス、悪用可能な脆弱性を探してドアノブをガタガタと揺らすようなものだ。これらのプローブは、攻撃者がLog4Shellが依然として主要な脆弱性であり、WAFをすり抜けて脆弱性を探すことができると認識していることの証拠となる。

Contrast Securityの測定によると、2024年11月だけで、攻撃者はアプリケーションごとに4,000回以上のプローブを実行した。

通常、犯罪者はプローブを使用して脆弱性があるかどうかを判断した後、攻撃を開始する。Contrast Securityはアプリケーションやアプリケーション・プログラミング・インターフェース(API)をインストゥルメント化しているため、当社の数値はシグネチャや理論的な攻撃を反映したものではなく、実際に発生する証拠に基づく攻撃のみを反映している。

11月のContrast Securityの技術は、Log4jの脆弱性を利用したアプリケーションごとに平均2.29回の攻撃を示している。Contrastがこれらの攻撃をブロックしていなければ、犯罪者はエクスプロイトを実行できていただろう。

Contrast Securityが2024年11月に検知したすべての攻撃を見るには、攻撃レポートを参照してほしい。

Contrastの顧客は、Log4Shellが悪用されることを心配する必要がない。Contrast Securityは、Log4Shellが知られるようになる何年も前から、この攻撃を阻止していたのだ。その方法については、ADRがLog4Shellをどのように検知し、防御するかを中心とした攻撃の仕組みを参照してほしい。

Log4jの脆弱性は依然として問題なのか？

Contrast SecurityのCISOであるDavid Lindnerと製品セキュリティ担当ディレクターのNaomi Buckwalterは、Log4Shellがなぜ潜在的な危険であり続けるのかを説明した。

「エンタープライズアプリケーションのコードベースは巨大だ。数百、あるいは数千ものサードパーティ製の依存関係を使用しており、それらの依存関係はさらに多くの推移的な依存関係を使用している」とDavidは述べている。「開発者はすべてのコードを把握しているわけではないので、Log4jは多くのアプリケーションに気づかれずに隠れている可能性がある。」

「3年が経過し、Log4jへの注目は薄れている。業界は他のエクスプロイトに移行している」とNaomiは同意する。「この破壊的な脆弱性は、今日も標的にされ続けている。しかし、もはや主要な焦点ではないため、セキュリティチームや開発者は見過ごしがちになる。」

根絶が難しい理由：

• 複雑な相互依存関係: 依存関係は直接的なものと推移的なものがあり、Log4jが別のライブラリの一部として含まれている場合がある。
  「エンタープライズソフトウェアに存在する推移的な依存関係の層の多さを考えてみてほしい。開発チームはカスタムコードを記述し、それは借用した(サードパーティの)コードを使用して構築され、そのコードはさらに別の借用したコードを使用している、といった具合だ」とNaomiは説明する。「カスタムコードが明示的にLog4jライブラリを使用していなくても、コードをサポートするコードが使用している可能性がある。Log4shellの脆弱性は、気づかないうちにコードが使用しているソフトウェアに存在する可能性がある。」
• 隠れたコンポーネント: 多くの組織は、コードリポジトリで脆弱なバージョンの参照をスキャンすることでLog4Shellに対応した。 残念ながら、多くのライブラリはコードリポジトリに存在しない。TアプリケーションやAPIサーバーに組み込まれていたり、実行時に動的にロードされたり、ランタイムモジュールやプラグインの一部であったりする。これらのライブラリは、完全に組み立てられ、実行されているアプリケーションを分析することによってのみ発見することができる。

Contrast Securityの創設者、Jeff Williamsによる本番環境のAppSec解決策

• 不適切なパッチ:  Log4Shellの初期のパッチは不十分で、さらなる更新が必要な脆弱性が残っていた。残念ながら、一部のシステムはパッチが適用されていないか、時間の経過とともに誤ってパッチが適用されている。Log4jは最も広く使用されているオープンソースのロギングライブラリの一つであるため、すべてのインスタンスが迅速に更新されていることを確認することは困難だ。広く使用されているということは、パッチが適用されていないシステムがわずかであっても、脆弱なインストールの数が相当なものになる可能性があることを意味する。ソフトウェアコンポーネントを包括的に把握していなければ、企業は古いバージョンのLog4jを見落としてしまう可能性がある。「Log4jの異なるインスタンスをアップグレードする場合、必ず「破壊的な修正」があるバージョンに遭遇する。つまり、アプリケーションが壊れてしまうということだ」とDavidは付け加えた。「多くの場合、新しいバージョンへのアップグレードは2時間で終わる作業ではない。何ヶ月もかかることがある」と彼は述べ、問題が発生するまでチームは脆弱性を放置してしまうことになる。

Log4Shell脆弱性を被害リスクが最も高いのは誰か？

Log4jは世界中で何百万ものコンピュータアプリケーションに存在し、Javaアプリケーションの約64%がLog4jに依存している。

「誰もがLog4jの問題を抱えている。Log4Shellは依然としてどこにでもある脅威だ」とDavidは言う。「規制の厳しい業界はもっと保護されているはずだが、そうではない。これは無知の問題ではない。人々は可能な限り効率的に仕事をしようとしているだけだ。そのため、物事が見落とされる。すべてが重要になると、何も重要ではなくなる」と彼は説明する。

Log4Shellを使用した攻撃の仕組みを完全に理解するには、「攻撃の仕組み」を参照してほしい

これは問題だ。しかし、この問題はContrast SecurityのADRで対処できる。詳細はこちらを参照してほしい。

Log4jの脆弱性を検知し、修復するにはどうすればよいのか？

Log4jの修復には、以下に概説する3つのステップが必要だ。(これらのステップの詳細については、 [Upgrade to 2.17] Updated Guidance on Addressing Log4J CVEs.) を参照してほしい。

1. 脅威ハンティングを実施して、侵害の痕跡(IoCs)を発見する。
   Naomiは、過去のネットワークログとSIEMログでJNDIネットワークトラフィックを探すことを提案している。「2、3年前、Log4jが初めて登場した頃のセキュリティ情報・イベント管理(SIEM)ログを振り返ってみてほしい。${ type syntaxを含むアプリケーション入力が突然停止したなど、外部システムへのJNDI接続が大量に発生している場合は、攻撃者がシステムに侵入している可能性が高い」と彼女は説明する。「攻撃が突然停止するのは、攻撃者が諦めたからではない。侵入に成功したからだ。」
2. IOCsが悪意のあるものであることを確認し、必要に応じてパッチを適用する。
3. アプリケーション層の保護で、パッチ適用とアップグレード中に悪意のあるアクティビティをブロックする。
   「ここでContrastのADRが重要な役割を果たす」とNaomiは述べている。「脆弱なルートがあり、攻撃が侵入してきている場合は、そのソフトウェアを更新するか、攻撃をブロックする必要がある。アップグレードには6ヶ月以上かかる場合があるので、それが完了するまでは、ContrastのADRが攻撃をブロックして保護する。」

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

ADRは、アプリケーション層内で直接、詳細なリアルタイムの可視性と保護を提供する。これまで、リアルタイムの異常、攻撃、脆弱性を検知するために、アプリケーションの動作を直接監視・分析する検知・対応ソリューションは他に存在しなかった。

この技術により、組織はITインフラストラクチャの重要な部分すべてを攻撃者がどのように移動したかを追跡することができる。攻撃者は、組織の最も貴重なデータに接続されているアプリケーションとAPIを標的にすることを選択する。ADRを利用すれば、セキュリティ運用担当は、攻撃の起点となるアプリケーションやAPIから横方向への展開を追跡し、侵入が永続的になる前に阻止することができる。

「ADRは、アプリケーション層で必要とされているギャップを埋めるものだ」とDavidは述べている。「シフトレフトは失敗だった。企業はセキュリティ上の負債を抱え、安全でないコードを実行している。ADRは、これまでになかった本番環境でのアプリケーション保護に最適だ。」

ADR技術が組織をどのように保護できるかについて詳しくは、Contrast Security ADRのデモをリクエストして、その機能を実際に見てほしい。

Read more: 

• Contrast ブログ: CISOよ、目を覚ませ！ アプリケーションの盲点を照らすADRというフラッシュが必要だ
  
• Contrast ブログ: アプリケーション層にサイバーセキュリティの監視と対応を導入する
• Contrast ブログ: SOCアナリスト時代にADRを知っていればよかった！