Log4Shellウェビナー：知っておくべきこと

テクノロジー業界でどのような役割を担っていても、多くのJavaアプリケーションに影響を及ぼす、広く知られたLog4Shellの脆弱性について、すでに耳にしたり、実際に対処したりしたことがあるでしょう。この重大なゼロデイ脆弱性に関する最新情報を広く共有するため、先日ウェビナーを開催し、皆さまに最新情報をお届けしました。

「Log4Shell：知っておくべきこと」ウェビナーでは、SnykのSteve Kinman（フィールドCISO）、Simon Maple（フィールドCTO）、Kirill Efimov（セキュリティリサーチチームリード）が、Log4Shellの脆弱性とその緩和方法について解説しました。ここでは、ウェビナーでの議論の概要をご紹介します。

Log4jとは？

Log4jは、Javaアプリケーションでログ記録に広く利用されている、人気のオープンソースJavaライブラリです。このログ記録フレームワークは、Java Development Kit（JDK）が提供するJNDIサービスを使ってアプリケーションから追加情報を取得します。ログデータにメタデータを加えることで、開発者にとってログがより有用になります。Apache Struts 2、Apache Solr、Apache Druidなど、多くの一般的なJavaアプリケーションフレームワークで、Log4jがデフォルトで使用されています。

ログ記録は非常に重要です。Javaアプリケーションは常に、特に例外やエラーについて記録を残します。そうすることで開発者は、何が起きているのかを把握できます。

Log4Shellの脆弱性

Log4Shellは、Log4j2ライブラリに存在する、重大で悪用が容易な脆弱性の名称です。この脆弱性（CVE-2021-44228）のCVSSスコアは10で、これは最高評価です。

Log4jで開示されたこのゼロデイ脆弱性は、広く存在し、重大で、容易に悪用できます。攻撃経路は5～6年前から存在していました。悪用が非常に容易なため、膨大な数の攻撃が発生しており、状況は常に変化しています。

Log4Shellの攻撃の仕組み

JNDI（Java Naming and Directory Interface）はLDAPに似たディレクトリサービスで、一意の識別子を使ってコードやJavaオブジェクトを取得できます。Javaアプリケーションが、データソースやその他の情報を取得するためにJNDIサービスへリクエストを送るのは一般的です。

Log4jのログ記録フレームワークは、JNDIを使って変数などの情報を取得し、ログに記録するデータを充実させます。問題は、ログの記録時にLog4jが実行時に危険な文字列を解決しようとする可能性があることです。これには、許可されていないJNDIサービスへのURLも含まれます。

つまり、攻撃者はログ記録サービスを悪用し、Javaアプリケーションから自身のJNDIサービスへリクエストを送らせることで、Log4Shellの脆弱性を利用できます。さらに、そのサービスから悪意のあるオブジェクトやコードを応答させることも可能です。このリモートコード実行（RCE）攻撃は、広範囲に影響を及ぼすおそれがあります。

Log4Shellの主なリスク

Log4Shellの直接的なリスクは、リモートコード実行攻撃です。悪意のあるコードを注入することで、攻撃者はマルウェアやランサムウェアを展開したり、サーバーやアプリケーションを乗っ取ったり、データを窃取したりできます。また、データの完全性やアプリケーションの可用性を損なったり、他のセキュリティサービスを無効化したりするおそれもあります。

攻撃を受ける直接的なリスクに加え、脆弱なJavaアプリケーションにはほかにも懸念があります。Log4Shellの脆弱性によって、規制への準拠やクラウドセキュリティ制御、サードパーティのSaaSアプリケーションのセキュリティに問題が生じたり、コンプライアンスポリシーに違反したりする可能性もあります。

最大のリスクは、取締役会やCEOから「当社は影響を受けていますか？」と尋ねられることです。そのとき明確に答えられなければ、それ自体がリスクになります。

Log4Shellの脆弱性を特定する

Java開発チームがLog4Shellを緩和するには、依存関係グラフのどこでLog4jが使われている可能性があるかを特定する必要があります。これは簡単ではありません。Snykのお客様の60.8%がLog4jを推移的依存関係として使用していることがわかっているからです。つまり、使用している別のオープンソースライブラリにログ記録フレームワークが含まれているケースです。

この脆弱性がセキュリティチームにとって特に恐ろしい理由の一つは、Log4jを使っているかどうかさえわからないことです。ソフトウェアが何を使って構築されているのか把握できていなければ、影響を受けているかどうかも本当の意味ではわからないでしょう。

Snykを使えば、Log4Shellのような脆弱性が推移的依存関係に含まれている場合でも、アプリケーションをスキャンできます。これにより、Log4Shellのようなセキュリティリスクがソフトウェアサプライチェーンに入り込むのを防げます。また、管理対象外のJARやシェーディングされたJARから脆弱性を検出するためのsnyk log4shellコマンドも作成しました。

Log4Shellの攻撃を緩和する

使用しているLog4jのバージョンを特定したら、最低でもバージョン2.17.1を使用していることを確認してください。ゼロデイ脆弱性の発見直後に推奨されていた対策は、Log4Shellの脆弱性を修正するためにバージョン2.15.0へ移行することでした。しかし、このバージョンにも別の問題があります。

編集者注：ウェビナーの収録時点では、2.16へのアップグレードが推奨されていました。その後、推奨バージョンは2.17.1に更新されました。この脆弱性については日々新たな情報が明らかになっているため、最新情報はLog4Shell脆弱性に関するリソースページで定期的にご確認ください。

すぐにライブラリをアップグレードできない場合は、Log4Shellの悪用を防ぐための緩和策を講じましょう。詳しい修正方法については、状況の変化に合わせて随時更新しているLog4Shell修正ガイドをご覧ください。

この脆弱性は今後何年にもわたって残り続けるでしょう。また、ゼロデイであることは業界にとって懸念事項です。誰かが再び利用したり、把握していない依存関係に含まれていたりすることで、何度も問題として浮上するでしょう。