Log4Shell の脆弱性は 2021 年の悩みの種

Steve Povolny および Douglas McKee 著· 2022 年 1 月 19 日

概要

12 月 9 日 – ある脆弱性 (CVE-2021-44228) が、Apache Log4j のロギング ライブラリに関する Github 上の POC とともに Twitter で公開されました。このバグは、Alibaba Cloud セキュリティ チームによって 11 月 24 日に初めて公表されました。

この脆弱性は、Apple iCloud、Steam、Samsung Cloud ストレージなどインターネット上の大手企業の製品や、その他の製品・サービスを含めて、アプリケーションに Log4j ライブラリを統合している製品に甚大な影響を及ぼす可能性があります。Java はほぼすべての業界のアプリケーションで多用されているため、このような事態もまだ始まりにすぎませんが、企業が積極的な防御策として採用できる予防策や戦略があり、こうした最新の一般的な脅威からの復元力を高め、保護することができます。

問題の概要

この脆弱性は、Java Naming and Directory Interface (JNDI) 機能が変数を解決する方法に起因するものです。JNDI 参照がログに書き込まれると、JNDI はその変数を解決するためのすべての要件を取得します。このプロセスを完了するために、JNDI は必要なリモート クラスをダウンロードして実行します。これはサーバー側とクライアント側どちらのアプリケーションにも当てはまります。この脆弱性の主な要件は、攻撃者の制御下にある任意の入力フィールドとこの入力がログに渡されることだからです。

この攻撃のオーケストレーションとして、攻撃者は何種類かの JNDI ルックアップを利用できます。現在、PoC とアクティブなエクスプロイトの両方で確認されている最も一般的な参照方法は、LDAP を利用することですが、RMI や DNS など他のルックアップも攻撃手段としては有効です。単純な LDAP/RMI の攻撃方法は、古い JDK バージョンにしか通用しないことに注意してください。この制限を回避してコード実行を達成する方法を示した報告もありますが、その場合の攻撃は複雑になります。

Java オブジェクトのデシリアライズ脆弱性は、特に新しい脆弱性や攻撃ということではありません。marshalsec などの過去の攻撃研究をこの脆弱性に適用すると、コード実行を単純化できます。

進化の過程と、攻撃の内容

• 12 月 14 日、Log4j バージョン 1.2 は JMSAppender コンポーネントを通じて同様の攻撃を受ける可能性があることが確認され、CVE-2021-4104 が発行されました。ただし、これはバージョン 2.0-alpha1 から 2.16.0 までのように簡単に悪用できるものではありません。悪用するためには、JMSAppender が有効になっていて、JMSAppender が JNDI リクエストを実行できるように TopicBindingName または ToicConnectionFactoryBindingName 構成が設定されている必要があります。これはデフォルトの設定ではありません。

これが確認されたことを受けて、Apache は Log4j の新バージョンとして、バージョン 2.16.0 をリリースしました。このアップデートによって JDNI はデフォルトで無効になり、ユーザーが明示的に JNDI 機能をオンにすることが必要になりました。メッセージ ルックアップのサポートは完全に削除しました。

• ところが 12 月 18 日には、Log4j のバージョン 2.0-alpha1 から 2.16.0 までに影響する新たなサービス拒否 (DoS) の脆弱性、CVE-2021-45105 が発見されます。Log4j の脆弱性を緩和するために、Apache はバージョン 2.16.0 で JNDI ルックアップを完全に無効にしましたが、デフォルト以外の設定では自己参照ルックアップがまだできる状態でした。入れ子になった変数が StrSubstitutor クラスによって置換されると、再帰的に substitute() クラスが呼び出されます。この入れ子になった変数が、置換される変数を再帰的に参照すると、無限の再帰となり、サーバーで DoS 状態が発生します。最新の調査によって、以前の脆弱性のようにコード実行には至らないとされています。

それを受け、Apache は最新の DoS 脆弱性に対応するために、Log4j の新バージョンとして バージョン 2.17.0 をリリースしました。ユーザー入力を含む可能性のある文字列の分析を管理するために、StrSubstitutor から 2 つのクラスが新しく作成されました。その新しいクラスでは、再帰的な評価は起こりません。この脆弱性を悪用すると DoS 状態が発生しますが、以前に報告された、リモートコードが実行されるという Log4j の脆弱性よりも重要度は低いと考えられます。

脆弱性のエクスプロイトに成功するには、標準的でない条件 をいくつか満たす必要があるという点が重要です。Log4j を取りまく状況は今も変化し続けているため、可能な限りバージョン 2.17.1 にアップグレードしてください。また、新しい年を迎えるにあたり、全体的なセキュリティ戦略と実践を見直す時間をとることもお勧めします。

明るい見通し

この脆弱性を緩和するさまざまな方法については、多くの情報があります。人間と機械が常に一緒に学習し、適応していくという可能性が開かれています。脅威がますますダイナミックになるにつれて、ビジネス経営りを確実に最適化し保護するためには、戦略とプロセスも同じように変化しなければなりません。Log4j は、脅威を避けられない弊害として考えるのではなく、成長、学習、適応の機会として捉えたうえで、復元力を高め、今後のビジネス上の優位を築くための実践的な機会になるのだと、企業は捉え直すべきでしょう。

当社は、Log4j のように急速に進化する脅威に対応するには、セキュリティを生きたものにすること重要であるという認識に立って、広く知られるようになったこの脆弱性を慎重に追跡しています。当初の目的は、公開されている PoC を使って悪用されやすいかどうかを判断することでした。これは実際に再現して確認できました。これは、公開されている Docker コンテナー と、LDAP および RMI の両方を活用するクライアント/サーバー アーキテクチャ、さらにはmarshalsec を使用して、Log4j バージョン 2.14.1 のエクスプロイトを利用して実現しました。

今後は、DNS などの追加サービスを利用するバリエーションもテストする予定です。また、NSP (Network Security Platform) をご利用のお客様に向けて、ネットワーク署名 KB95088 をリリースしました。この署名は、LDAP 上で CVE-2021-44228 を悪用しようとする試みを検出します。他のプロトコルやサービスを含むように拡張される場合があり、対象範囲を補うために追加の署名がリリースされる可能性もあります。

他のリソースをお探しですか

この脆弱性の全容は、こちらのセキュリティ情報 で確認できます。また、PoC やツールのリストは以下で確認できます。

• https://github.com/pedrohavay/exploit-CVE-2021-44228
• https://github.com/christophetd/log4shell-vulnerable-app
• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
• https://rules.emergingthreatspro.com/open/
• https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
• https://github.com/corretto/hotpatch-for-apache-log4j2
• https://github.com/nccgroup/log4j-jndi-be-gone