本記事は2022年1月4日に公開した英語ブログLog4Shell webinar: What you need to knowを日本語化した内容です。
多くのJavaアプリケーションに影響を与えるLog4Shellの脆弱性については、すでに耳にしたり、対処したりしたことがあるのではないでしょうか。この重要なゼロデイ脆弱性についての最新情報を提供するため、弊社では最近オンラインセミナーを開催しました。
「Log4Shellについて知っておくべきこと」と題したオンラインセミナーでは、弊社SnykのField CISOのSteve Kinman（スティーブ・キンマン）、 Field CTOのSimon Maple（サイモン・メイプル）、Security Research Team をリードする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を含む危険な文字列を実行時に解決しようとする可能性があることです。
つまり、Log4Shellの脆弱性により、悪意のある行為者は、ロギングサービスを悪用して、Javaアプリケーションから独自のJNDIサービスにリクエストを行い、そのサービスが悪意のあるオブジェクトやコードで応答することができる可能性があるということです。このリモートコード実行（RCE）攻撃は、広範囲に及ぶ結果をもたらす可能性があります。
Log4Shellの主要なリスク
Log4Shellに関して言えば、直接的なリスクはリモートコード実行攻撃です。悪意のあるコードを注入することで、脅威者はマルウェアやランサムウェアを展開し、サーバやアプリケーションを乗っ取り、データを流出させ、データの整合性やアプリケーションの可用性に影響を与え、他のセキュリティサービスを無効化することができます。
脆弱なJavaアプリケーションには、悪用される直接的なリスク以外にも、懸念すべき点があります。Log4Shellの脆弱性は、法令遵守の違反、クラウドセキュリティコントロールの失敗、サードパーティSaaSアプリケーションのセキュリティ問題、コンプライアンスポリシーの違反、などにつながる可能性もあるのです。
御社の監督委員会やCEOから「我々はLog4Shell脆弱性の影響を受けているのか？」 と聞かれた時に、あなたが正しく回答できないとしたら、それが最大のリスクです。
Log4Shellの脆弱性を確認する
Java開発チームにとって、Log4Shell脆弱性に対応するためには、依存関係グラフの中でLog4jが使用されている可能性がある場所を特定する必要があります。この特定はたいていの場合、困難です。Snykの顧客の60.8%は、Log4jを推移的依存ライブラリとして使用していました。推移的依存とは、使っているオープンソースライブラリの中で間接的に、Log4jが使われていることを指します。
この脆弱性がセキュリティチームにとってさらに恐ろしいのは、Log4jが使われているかどうかさえ分からないことです。もし、あなたのソフトウェアが実際に何を使って構築されているのかわからない場合、影響を受けているかどうか本当にわからないかもしれません。
Snykを使用すると、Log4Shellのようなセキュリティ問題が推移的依存関係の中にある場合でも、アプリケーションの脆弱性をスキャンすることができます。これにより、Log4Shellのようなセキュリティリスクから、ソフトウェアのサプライチェーンを保護することができます。また、Snykは、アンマネージドJARおよびシェーディングされたJARの脆弱性を検出するsnyk log4shellコマンドを作成しました。
Log4Shellエクスプロイトの緩和策
使用しているLog4jのバージョンを確認したら、最低でもバージョン2.17.1であることを確認する必要があります。ゼロデイが発見された直後の最初のアドバイスは、Log4Shellの脆弱性を修正するためにバージョン2.15.0に移行することでしたが、このバージョンには他の問題もあります。
編集者注：ウェビナー収録時点では、2.16へのアップグレードが推奨されていました。その後、2.17.1 に更新されました。この脆弱性については、毎日多くのことが判明していますので、Log4Shellの脆弱性リソースページで、最新情報を定期的に確認することをお勧めします。
すぐにライブラリをアップグレードできない場合は、Log4Shellの悪用可能性を緩和することをお勧めします。完全な修正ガイドについては、Log4Shellの修正に関するチートシートをご覧ください。
この脆弱性は何年も続くでしょうし、ゼロデイであることは業界にとって懸念材料です。人々がそれを再び利用したり、気づかれていない依存関係として存在することにより、この脆弱性はずっと頭をもたげ続けるでしょう。
参考情報
Snyk株式会社では下記の日本語情報も公開しています。
- Log4Shellの脆弱性が公開されました：Version 2.17.1にアップデートしてLog4j RCEを防ぐ
- Log4Shellデモ（実証〜検出〜修正）を公開しました
- 最新版Log4j 2.17.1ではCVE-2021-44832のリモートコード実行が修正されています
- 米国連邦取引委員会（FTC）からのLog4jの脆弱性に関する警告について
本記事にまとめたオンラインセミナーの全編は下記よりご覧いただけます。
また最新情報は下記の弊社公式SNSにてお届けしています。フォローをして脆弱性に関する最新情報をご確認ください。
セキュアコーディングのための情報を随時発信しております。ぜひご覧ください。