オープンソースのロギングライブラリとしてさまざまなJavaアプリケーションに使われている「Apache Log4j」に、任意のリモートコードが実行できてしまう脆弱性が発見されました（CVE – CVE-2021-44228）。
これが悪用されると、第三者が勝手にサーバを操作して悪意のあるソフトウェアを組み込んだり、悪意のある攻撃を行う際の踏み台にされるなどのさまざまな攻撃が行われます。
すでに脆弱性の存在は広く知れ渡っているため、脆弱性のあるLog4jを使っているシステムはいつでも攻撃を受ける可能性があるのです。
この脆弱性は広範囲な影響が予想されており、多くの専門家が非常に深刻な状況として捉えています。
できるだけ速やかに、JavaアプリケーションにおけるLog4jの利用の確認と対策が必要です。
Javaアプリケーションに明示的にLog4jを組み込んでいない場合も、例えばStrutsやRedisなどを始めとするさまざまなフレームワークやコンポーネントがLog4jを採用しているため、慎重な確認が求められます。
また、この脆弱性を突いたさまざまな攻撃が実行されている可能性があります。自社でJavaアプリケーションを運用していなくとも、自社のネットワークやサーバに対して外部から攻撃が行われていないかどうか、しばらくはいつもより細かく見ていた方がいいかもしれません。
バージョンアップなどの対策方法
この脆弱性について、日本語での信頼性の高い情報源の1つがJPCERT/CCの下記のページでしょう。
これによると、脆弱性のあるLog4jのバージョンは、Apache Log4j 2.15.0より前の2系のバージョン。Apache Log4j 1系のバージョンについてはこの脆弱性の影響を受けないと説明されています。
開発元であるApache Foundationの公式ページに掲載された本件の脆弱性情報のページ「Log4j – Apache Log4j Security Vulnerabilities」では、Log4j 2.15.0で脆弱性が修正されたことが発表されています。
もっとも適切な対応として、速やかにこの最新バージョンへのバージョンアップを行うことが挙げられます。
バージョンアップがすぐに行えない場合、以下の方法が対応策として示されています。
Log4jバージョン2.10およびそれ以降
- Log4jを実行するJava仮想マシンを起動時に「log4j2.formatMsgNoLookups」というJVMフラグオプションを指定する
- 環境変数「LOG4J_FORMAT_MSG_NO_LOOKUPS」を「true」に設定する
Log4jバージョン2.10より前
- JndiLookupクラスをクラスパスから削除する
ファイアウォールを用いた対策
すぐにバージョンアップすることが難しい場合、暫定的な対策の選択肢として、ファイアウォールを用いてこの攻撃に使われる通信のパターンを遮断する方法があります。
AWSはこの脆弱性についてまとめたページ「Apache Log4j2 Security Bulletin (CVE-2021-44228)」で、AWS WAFに対応するルールを追加したことを明らかにしています。
DevelopersIOでこのWAFの動作が検証されています。
参考：Log4jの脆弱性対策としてAWS WAFのマネージドルールに「Log4JRCE」が追加されました | DevelopersIO
Google CloudでもWAFに対応ルールが追加されたことが発表されました。
Google Cloudのコミュニティブログに解説記事が書かれています。
このほか多くのファイアウォールで対応が行われているはずです。それぞれの提供ベンダなどにご確認ください。
ファイアウォールによる対策で時間を作りつつ、最終的にはソフトウェアのバージョンアップによる対応を行うのが望ましいでしょう。