Log4jの脆弱性とソフトウェアサプライチェーンセキュリティへの影響
2021年12月13日
0 分で読めます編集者注（2021年12月28日午後7時35分 GMT）： Log4jチームは新たなセキュリティアップデートをリリースしました。このアップデートにより、2.17.0にCVE-2021-44832として特定されたリモートコード実行の脆弱性があることが判明しました。現時点での最新バージョンである2.17.1へのアップグレードを推奨します。詳細は こちらをご覧ください。
編集者注（2021年12月18日午後6時55分 GMT）： Log4jをめぐる状況は急速に変化しており、新たな情報が入り次第、ブログを更新しています。 2.17.1 以降へのアップグレードを推奨します。このバージョンには、 2.15.0 で修正された2つのリモートコード実行の脆弱性（CVE-2021-44228、 2.16.0 で修正された脆弱性（CVE-2021-45046）と、2.17.1で修正された最新のDoS脆弱性（CVE-2021-45105）に対するセキュリティ修正が含まれています。詳細は こちらをご覧ください。
Log4Shellとして知られ、CVE-2021-44228として特定された脆弱性については、すでにご存じのことと思います。おそらく現在、修正対応を進めているところでしょう。この脆弱性は、セキュリティ研究者によって2021年12月10日（金）に、ApacheのLog4jロギングフレームワークに関する問題として公表されました。
この記事では、Log4jに関する重要な事実と、自分自身や自社を守るために取れる対策をご紹介します。
Log4jは緊急の対応が必要な重大な脆弱性
Log4jの脆弱性がいかに重大か、強調してもしきれません。CVSSスコアは10（最高値）で、脆弱な環境であれば攻撃者がリモートからコードを実行できる重大なセキュリティ脆弱性です。これは非常に深刻な問題であり、早急な修正が必要です。
現在お使いのLog4jのバージョンに応じて、直ちに取るべき対応を以下でご確認ください。
Log4j v1を使用しています。どうすればよいですか？
ここでのリスクは、2.xに影響する脆弱性と比べると大幅に低いものの、非常に限定的な条件下では、Log4j v1でもLog4j 2に影響したものと同様のルックアップが可能です。これは、LDAPやJNDI経由で解決されるその他のエンドポイントに対する保護がありません。こうした攻撃経路（およびその他の可能性がある攻撃経路）は、リモートコード実行（RCE）攻撃につながることが知られています。JMSAppenderが有効になっているLog4j v1を使用している場合、脆弱な可能性があります。JMSAppenderはデフォルトで無効になっているため、アプリケーションで使われているLog4j v1のほとんどの環境では、有効になっていないと考えられます。
これは重大な最新情報です。2021年12月13日午後5時頃（UTC）に公開されたばかりで、Snykでは脆弱性ID SNYK-JAVA-LOG4J-2316893として追跡しています。
そのため、可能であれば、最新の脆弱性修正が含まれるLog4j v2の最新バージョンへのアップグレードを推奨します。Apacheの公式ドキュメント「Log4j v1からの移行」をご確認ください。アップグレードできない場合は、JMSAppenderを無効にするか、ユーザー入力がその設定に到達しないようにしてください。
Log4j v2を使用しています。どうすればよいですか？
Log4j 2.xを使用している場合は、脆弱性を修正したLog4j v2の最新リリース（現在は2.16.0）にアップグレードしてください。
Log4j v1またはv2を使用していますが、すぐにアップグレードできません。すぐにできる回避策はありますか？
すぐにアップグレードできない場合は、システムプロパティとJavaパラメーターを設定して脆弱性を修正する方法を説明したLog4jの記事をご覧ください。
Log4jは広く使われており、影響は甚大
ロギングは一般的な手法
アプリケーションを構築する際、開発者はデバッグ、分析、監査に必要な情報を得るため、ほとんどの場合ログを記録します。日々の開発に役立つだけでなく、多くのセキュリティチームも監査証跡を残すためにロギングを求めています。監査証跡があれば、疑わしいアクティビティの追跡や相関分析が可能になります。
ロギングは開発に不可欠なプラクティス
ロギングが広く使われていることに加え、ユーザー入力の記録を通じてLog4jの脆弱性が悪用される可能性があるため、攻撃の深刻度は大幅に高まり、攻撃対象となる経路も広がります。たとえば、ソーシャルメディア上では、Webフォームに入力するメールアドレスやユーザー名としてLog4jのエクスプロイトペイロードを使い始めたユーザーがいることが公に確認されています。
Log4jの脆弱性がもたらす影響の全容が判明するには、まだ時間がかかります。しかし脆弱性の公表後すでに、日和見的な攻撃や、より巧妙なボットネットによる実環境での悪用が数百件試みられたとの報告が寄せられています。
Log4jのオープンソースライブラリは広く使われている
この脆弱性が注目を集めていることからも想像できるように、Log4jはベンダー、オープンソースプロジェクト、フレームワーク、大手財団のプロジェクトなどで幅広く使われています。
Log4jを使用する数百万ものJavaアプリケーションに加え、Apache Software Foundation自身のプロジェクトでも、Apache Solr、Apache Struts2、Apache Kafka、Apache Druid、Apache Flink、Apache Swiftなど、多くのプロジェクトがLog4jを使用しています。
Redis、Elasticsearch、Spring Framework、Nettyなど、ほかにも多くの人気プロジェクトで広く使われています。
一般に公開されたオープンソースプロジェクトである、米国家安全保障局（NSA）のリバースエンジニアリングツールGhidraでも、このLog4jのセキュリティ問題に対する脆弱性が見つかっています。
ベンダーにもこの脆弱性による大きな影響が及んでいます。たとえば、AWSのAWS CloudHSM、Amazon OpenSearch、その他のサービス製品も影響を受ける可能性があります。また、Red Hat JBoss Fuse 7、Red Hat CodeReady Studio 12、Red Hat OpenShift LoggingなどのRed Hat製品にも影響が及んでいます。ご想像のとおり、VMware、Ciscoをはじめ、多くのベンダーが大きな影響を受けています。
Snykのユーザーベースでも、大きな影響が確認されています。Snykのお客様の約3分の1がLog4jの脆弱性の影響を受けており、Snykがインポートまたは監視するプロジェクト全体で、数万件の脆弱性が検出されました。
Log4jのJavaライブラリをめぐるサードパーティのオープンソース危機は、組織全体でソフトウェア部品表（SBOM）を把握し、開発チームとセキュリティチームが迅速に対応できるソフトウェア構成分析ツールを導入する必要性を、あらためて浮き彫りにしています。
Log4jはサプライチェーンセキュリティに大きな影響を及ぼし、修正も困難
Snykがインポート、監視、スキャンしているプロジェクトのデータを活用することで、プロジェクト全体におけるLog4jライブラリの使用状況を深く把握できました。
これまでに、Snykが監視しているLog4jライブラリを使用するJavaプロジェクトの60%で、間接依存関係としてLog4jが使われていることがわかりました。間接依存関係とは、プロジェクトが間接的に使用する依存関係のことです（つまり、プロジェクトの依存関係の一つがLog4jを使っているため、自身ではLog4jを使っていなくても脆弱性の影響を受ける可能性があります）。そのため、脆弱なバージョンのLog4jを使っているかどうかを単純に検索するだけでは、プロジェクト内のライブラリをすべて見つけられるとは限りません。深くネストした依存関係グラフをたどり、バージョンを脆弱性データベースと照合してサプライチェーンセキュリティのリスクを特定するには、Snykのようなソフトウェア構成分析（SCA）ツールが必要です。
実際、Snykの「2020年オープンソースセキュリティの現状レポート」では、Java、Ruby、JavaScriptの各エコシステムで、脆弱性の大半が間接依存関係に起因することがわかりました（その後、これを確認しています）。
開発者として、log4jのようなプロジェクト内の脆弱性を特定するために、Snykなどのセキュリティツールを使うべき理由は数多くあります。脆弱な依存関係を使っているかどうかを把握するだけでは不十分です。依存関係がさらに依存しているものにも脆弱性がないか、再帰的に確認する必要があります。
つまり、今回のLog4jの脆弱性の修正は容易ではありません。問題を解決するには、多くのオープンソースライブラリをアップグレードする必要があり、それらに依存するプロジェクトの脆弱性を解消するまでには時間がかかります。
Log4jの脆弱性は、世界規模で差し迫った脅威となっています。新型コロナウイルス感染症のパンデミックにより、世界中の保健機関や医療研究企業が協力して対応にあたったのと同様に、今回もLog4jの脆弱性がもたらすリスク全体に対処し、コミュニティ全体に向けた包括的な解決策を提供するため、連携が進められており、さらなる協力が強く求められています。
すでに山積みのセキュリティ課題の中で、Log4jの修正を優先することが重要
多くの組織にとって、Log4jの脆弱性は、すでに山積みのセキュリティ課題に新たに加わった、緊急に対処すべき問題です。
プログラミング言語のエコシステム全体に広がる脆弱性、設定ミス、オペレーティングシステムのオープンソースコンポーネント、その他のアプリケーションセキュリティ上の懸念が増える中、セキュリティチームは何から着手すべきでしょうか？すでに人手不足の状況で、最も重要かつ緊急に対処すべき脆弱性は何でしょうか？
優先順位付けは、セキュリティチームが効果的に業務を進めるうえで重要なだけでなく、ビジネス全体のリスクを低減するうえでも大きな役割を果たします。効果的に対応するには、セキュリティチームが個々のプロジェクトだけでなく、組織全体を俯瞰して脆弱性のリスクを把握できる必要があります。
開発チームとセキュリティチームが迅速に対応し、組織全体の視点からセキュリティリスクを評価できるよう、Snykでは優先度スコアという仕組みを導入しました。
従来のセキュリティ対策では、文脈情報がほとんど考慮されないCVSSの脆弱性スコアに依存していました。一方、Snykの優先度スコアでは、エクスプロイトの成熟度、ソーシャルメディアの動向、割り当てられたCVEの深刻度スコア、修正プログラムの有無、脆弱性が最近公表されたものかどうかなど、脆弱性に関するコンテキスト情報を考慮します。
優先度スコアは0（最低）から1000（最高）までの範囲で、企業が対処すべき最も緊急性の高い脆弱性を示します。Log4jの脆弱性は、優先度スコアによってチームが適切に修正の優先順位を決められることを示す好例です。以下はSnykダッシュボードの画像です。組織が複数のエコシステムやプログラミング言語にまたがる数百のプロジェクトで、数千件の脆弱性に対処する必要がある中、特定のLog4j CVEに最高値の1000が付けられたケースを示しています。
Snykの創業者兼社長であるGuy Podjarnyはこの考えをさらに発展させ、重要なことと緊急なことの違い、そしてそれがセキュリティの優先順位付けにどう当てはまるかを説明しました。さらにこの考えをクラウドネイティブなアプリケーション開発にも拡張し、チームがKubernetesデプロイメントにおけるコンテキストに基づく優先順位付けを通じて、より多くの知見を得られるようにしました。
Log4jのような重大な問題への迅速な対応は、ビジネスの要です
Log4jの脆弱性により、インシデント対応チームは根本原因を特定し、デプロイ済みのJavaアプリケーションの一覧を調査して修正する対応に追われています。
Log4jのような重大な脆弱性に対してインシデント対応チームが迅速に対応する必要があったことは間違いありません。しかし、その負担は、アプリケーションのセキュリティに責任を負う開発者やアプリケーションセキュリティチームにも及びます。
Snykの根幹には、開発者を第一に考え、開発者にとって使いやすいセキュリティがあります。開発者とセキュリティチームが、セキュリティ脆弱性をできる限り迅速かつ簡単に発見し、修正できるようにすることは、私たちの最優先目標であるだけでなく、私たちの使命そのものです。
Log4jの脆弱性への対処でセキュリティ対応が混乱する中、脆弱性の修正にSnykを活用して成果を上げている方々を目にし、うれしく、また身の引き締まる思いでした。
開発者が脆弱性を事前に自動修正できることだけが重要なのではありません。長らく手つかずだった古いレガシープロジェクトも含め、すべてのソースコードリポジトリに潜むセキュリティ問題を把握できることも重要です。
Log4Shellを修正するために、次にすべきこと
この長いトンネルの先には光があります。そこにたどり着くには、いくつかのステップを踏むだけです。
Snykは、各アプリケーションのリスクへの露出度の把握から、SDLCの早い段階での継続的なテスト、特定された脆弱性を迅速に修正する自動修正プルリクエストの作成まで、さまざまな形で支援します。
プロジェクト全体でLog4j関連の脆弱性を迅速に修正するための実践的なアドバイスとして、SnykでLog4Shellをすばやく見つけて修正する方法をぜひご覧ください。まだの場合は、Snykに無料で登録しましょう。
事態は今も進行中です。最新情報を常に把握しておくことをおすすめします。ニュースレターやこのブログで引き続き最新情報をお届けしますので、ぜひご注目ください。
最後は少し明るい話題で締めくくりましょう。この重大な脆弱性のおかげで、どこか見覚えのある笑いも生まれました。おなじみの「Little Bobby Tables」のXKCDコミックを思い出します（ソーシャルメディアで最初に共有された際に、新たなアレンジが加えられていました）。
