Log4jの脆弱性を振り返る #aqua #セキュリティ #log4j
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2022年1月11日に公開された「 The Nightmare Before Christmas: Looking Back at Log4j Vulnerabilities 」の日本語翻訳です。
Log4jの脆弱性を振り返る
先月、非常に人気の高いロギングフレームワーク Log4j にゼロデイ脆弱性が発生し、ただでさえ忙しい年末のラッシュの中、セキュリティコミュニティを騒がせました。ほぼ毎日発見される複数の脆弱性を修正することはおろか、Log4j のニュースやアップデートに追いつくだけでも容易なことではありませんでした。組織は、最初のゼロデイ脆弱性に対するパッチを適用するために懸命に働きましたが、追加の脆弱性が出現すると、このプロセスを繰り返すことを余儀なくされました。
このブログでは、これまでの経過をまとめ、Log4j の脆弱性が将来に及ぼす影響を検証し、企業がシステムをより良く保護するための方法を概説します。
Log4jとは
Log4j は、Apache Foundation によって開発されたオープンソースの Java ロギングライブラリです。数百万の企業アプリケーション、クラウドサービス、Web アプリケーションで広く利用されている便利なソフトウェアパッケージです。多くのサービスが依存関係にあり、Apache Struts、Solr、Druid、Flink、Swift など、様々な Apache フレームワークに含まれています。
Log4jの脆弱性の概要
12月9日、Log4j に攻撃者がリモートでコードを実行できる重大なゼロデイ脆弱性 CVE-2021-44228 が発見されました。このパッチの発表とリリース後、数週間の間に、深刻度の異なる複数の新しい脆弱性が発見されました。そのたびに新たな修正プログラムがリリースされ、企業のシステム更新への取り組みがさらに強化されました。攻撃者とセキュリティ研究者の両方が Log4j に注目し続けているため、この脆弱性と修正のサイクルは今後も続くと予想されます。
Log4jの脆弱性による影響
最近のアプリケーションで Log4j が広く使われていることを考えると、世界中の組織に与える影響は甚大であり、真の復旧には何年もかかると思われます。Log4j 元の問題は、全世界で1億以上のインスタンスに存在すると推定され、Apple、Twitter、Steam、Tesla など、多くの人気サービスやプロバイダーが影響を受けています。
この脆弱性は、何百万ものアプリケーションに影響を与えるだけでなく、その悪用も簡単です。攻撃者は、Log4j によって記録される悪意のあるコード文字列を送信するだけでよいのです。これにより、攻撃者は、脆弱なサーバを完全に制御し、リモートコード実行(RCE)攻撃を実行することができます。
Log4jの攻撃について
公開後、Log4j の脆弱性が大量に悪用されていることが報告されています。この脆弱性は RCE を可能にし、容易に悪用される可能性があり、GitHub やその他の公開ソースで大量の武器化されたエクスプロイトが容易に入手できます。
Log4j の脆弱性は、攻撃者が一般的なオープンソースパッケージの脆弱性を悪用し、そのような脆弱性がもたらす大規模な影響を示す良い例です。組織がシステムのパッチを急ぐ一方で、攻撃者はこの脆弱性を利用し、危険にさらされているシステムをインターネット上で積極的にスキャンし、攻撃を仕掛けているのです。
Aqua のセキュリティ研究チームである Team Nautilus は、Log4j の脆弱性を悪用した何十もの実際の攻撃を分析し、攻撃者が使用する悪意のあるテクニックのいくつかを明らかにしました。その中には、大規模なボットネットである Muhstik や Mirai などの既知のマルウェア、ファイルレス実行、リモートリソースからダウンロードしたファイルをメモリから直接実行する、リバースシェル実行などが含まれています。
どのような対応策があるのか
できるだけ早く最新版の Log4j-2.17.1 へアップグレードすることを強くお勧めします。最初のステップは、あなたの環境で動作している Log4j を使用するすべてのアプリケーションを特定することです。Aqua のオープンソーススキャンツール Trivy は、脆弱性のあるソフトウェアライブラリを検出し、すべての Log4j の脆弱性についてアラートできます。
大局的に見ると、1つの製品に存在する複数の脆弱性が短期間に悪用されるという傾向が強まっているため、組織がその対処方法を考える必要があることは明らかです。即座に対応した後、この種のリスクを戦略的に管理する方法を検討することが、非常に重要です。
こうした対策は、将来、同様のインシデントが発生した場合のリスクと影響を軽減するのに役立ちます。
- ソフトウェアサプライチェーンの安全性を確保する-ソフトウェアサプライチェーンセキュリティの一環として、ソフトウェア部品表(SBOM)を使用することで、組織は脆弱なソフトウェアを特定し、特定のソフトウェアパッケージの使用状況を可視化できます。
- 多層防御のセキュリティ戦略を策定する- Log4j の脆弱性は、多層防御戦略の重要性を示しています。多層防御戦略とは、組織の環境全体にわたってセキュリティ対策を重ね、1つの層の障害が完全な侵害へつながらないようにするものです。
- Drift Prevention(コンテナにインスタンス化された後のイメージの変更を決定論的に禁止し、ランタイム中にドロップされたファイルの実行を防止するソリューション)を使用する-ワークロードの実行中に悪意のある動作を明らかにできます。
- Aqua の Cloud Native Detection and Response(CNDR)などの検出およびレスポンスソリューションを展開する-未知の脆弱性が悪用された際のイベントを特定し警告することで、ゼロデイ攻撃の検知と本番での発生防止に貢献します。
クラウドネイティブ環境におけるLog4jの追跡
環境中のコンテナイメージに含まれる Log4j の脆弱性を全て特定するだけでも大きな課題です。多くの Java アプリケーションがロギングに Log4j を使用しているため、組織は無意識のうちに Log4j を使用している可能性があり、重要でない、あるいは予期しないアプリケーションからサイバーインシデントが発生する可能性もあります。
さらに問題を複雑にしているのは、脆弱性のあるシステムが非常に多様であることです。Log4j は、しばしば他のソフトウェアの一部として使用されたり、ブラックボックスアプライアンスにバンドルされているため、組織がすべての脆弱なシステムの情報を把握あるいは保持している可能性は低いです。
Log4j の脆弱性を評価、特定、修正するためのより良い方法をお探しの場合、特に実運用中のコンテナについて、Aqua は Log4j 評価パッケージを作成し、クラウドネイティブ環境とコンテナイメージの Log4j 脆弱性を迅速かつ効果的に評価します。
