vc_log4j_mitigator.py での CVE-2021-44228 & CVE-2021-45046 への対処

Dec 26, 2021 vCenter Server vSphere Security Vulnerability
Share on:

Table of contents

概要

Log4j 2.x の脆弱性 (CVE-2021-44228 & CVE-2021-45046) が話題ですが、12/20 に vCenter Server に関する KB87081 と KB87096 が更新され、vc_log4j_mitigator.py の実行のみで対処が可能になっています。

本記事では vc_log4j_mitigator.py を使用して vCenter Server に CVE-2021-44228 & CVE-2021-45046 への対処を実施していきます。

本記事を読む前の注意点

本脆弱性に関する VMware Security Advisories や各製品の KB は頻繁に更新されており、公開当初から相当な更新や追記が行われています。本記事に記載されている情報は 12/26 時点の情報となり、記事中で対処を行っている環境は vCenter Server Appliance 7.0 Update 3a のため、記事の閲覧時点で異なる部分が発生している可能性もあります。

本記事に限らず、脆弱性に関する最新の情報は必ず VMware Security Advisories や各製品の KB といった公式の一次情報を確認するようお願いいたします。

背景

先日から Log4j 2.x の脆弱性である CVE-2021-44228 および CVE-2021-45046 が話題になっています。VMware 製品も脆弱性の影響を受けるソフトウェアは多く、VMware Security Advisories や Knowledge Base でそれぞれ影響を受ける／受けない製品の情報が公開されています。

vCenter Server も Java で実行されている複数のサービスで Log4j 2.x を使用しロギングを行っているため、脆弱性の影響を受けることが確認されています。VCSA、Windows 版の情報はそれぞれ以下の KB で公開されています。

脆弱性の大元の情報自体が頻繁に更新されていたため、上述の VMware KB も公開された当初から現在まで頻繁に更新や追記が行われています。12/15 以前の古いワークアラウンドだけを実行している場合、現在では脆弱性の対処が不足していることになるため、本記事では改めて 12/26 現時点での情報をまとめます。

３通りの対処方法と推奨

12/26 現時点では以下の３通りの対処方法がありますが、１つ目の vc_log4j_mitigator.py の実行が推奨されている方法です。

  1. vc_log4j_mitigator.py の実行 (推奨)
  2. vmsa-2021-0028-kb87081.py および remove_log4j_class.py の実行 (VCSA のみ)
  3. 手動のワークアラウンドの実施および remove_log4j_class.py の実行

対処が必要な vCenter Server のサービスは複数あるため、手動でのワークアラウンドは作業の誤りなどを招く可能性もあります。現在は VCSA と Windows 版ともに vc_log4j_mitigator.py を使用することで実際の対処から対処状況の確認まで完結できますので、今回はこちらの Python スクリプトを使用して対処を行っていきます。

なお、公開から早い段階で KB を確認して手動のワークアラウンドまたは vmsa-2021-0028-kb87081.py の対処のみを行っており remove_log4j_class.py が未実施、つまり上述の 2. や 3. が途中のシステムは対処が不完全のため注意してください。特に、remove_log4j_class.py が KB に追加された 12/15 14:15 (PST) 以前に対処を行っただけの環境は要確認です。

もし対処が十分に行われているか分からない場合、vc_log4j_mitigator.py に –dryrun オプションを付与して実行することで対処状況の確認を行ってください。詳細は後述します。

実施前の確認事項

vCenter Server に対処を行う前に以下の点を確認してください。

  • サービスの再起動に伴うダウンタイムの発生
  • vCenter HA の構成解除
  • vCenter Server と PSC での実行

サービスの再起動に伴うダウンタイムの発生

対処の実施では vCenter Server のサービスの再起動を伴います。サービスの再起動中は vCenter Server が使用できないため注意が必要です。

vCenter HA の構成解除

対処には vCenter Server のサービスの設定ファイルの変更を伴うため、vCenter HA が構成されている場合には事前に vCenter HA の構成を削除しておく必要があります。対処の完了後に改めて vCenter HA を構成できます。

vCenter Server と PSC での実行

vSphere 6.7 以前の環境で、もし外部 PSC を使用した vCenter Server の構成の場合、vCenter Server と PSC の各インスタンスで対処の実行が必要なため注意してください。

なお、vCenter Server が組み込み PSC と外部 PSC のどちらを使用しているかは KB83193 の手順で確認することも可能です。

VCSA での対処の概要

VCSA での対処の大まかな流れは以下のようになります。

  • VCSA のバックアップまたはスナップショットの取得
  • VCSA への vc_log4j_mitigator.py のアップロード
  • vc_log4j_mitigator.py による対処状況の確認
  • vc_log4j_mitigator.py による対処の実行
  • vc_log4j_mitigator.py による対処完了の確認

以降、それぞれの手順の詳細について記載します。

VCSA のバックアップまたはスナップショットの取得

vCenter Server のサービスの設定ファイルや log4j の JAR ファイルに対する変更を伴うため、万が一に備えて事前に VCSA のバックアップやスナップショットを取得して変更前の状態に戻せるようにしておきます。

なお、仮想マシンのスナップショットは長期間の保持が非推奨です。脆弱性への対処および正常な稼働確認の完了後、作成したスナップショットの削除を忘れないようにしましょう。

VCSA への vc_log4j_mitigator.py のアップロード

vc_log4j_mitigator.py が使用できなくては何も始まりませんので、まずはこのスクリプトを SCP クライアントで VCSA にアップロードします。

まずは VCSA に SSH で接続するために、VAMI にログインして SSH を有効にします。

次に、VCSA に SSH で接続し、KB2107727 の手順で root のデフォルトシェルを bash に切り替えます。既定はアプライアンスシェル (/bin/appliancesh) のため SCP でのファイル転送が行えません。

1Command> shell
2Shell access is granted to root
3# chsh -s /bin/bash root

あとは OpenSSH の scp コマンドや WinSCP などの SCP クライアントで vc_log4j_mitigator.py を VCSA にアップロードします。vc_log4j_mitigator.py は KB87081 / KB87096 の Attachments からダウンロードしてください。

なお、TeraTerm の SSH SCP 機能のように、単一の TCP コネクション上で複数の SSH セッションを使用しようとすると VCSA では拒否されますので注意してください。アップロード元端末が Windows 10 以降であれば OpenSSH がバンドルされているので追加の SCP クライアントをインストールする必要もなくなっているかと思います。

最終的に対処が完了したら、root のデフォルトシェルをアプライアンスシェルに戻し、SSH も VAMI から無効に戻しておきます。デフォルトシェルをアプライアンスシェルへ戻すには以下のコマンドを実行します。

1# chsh -s /bin/appliancesh root

vc_log4j_mitigator.py による対処状況の確認

vc_log4j_mitigator.py に –dryrun (-r) オプションを付与して実行すると、未対処の JAR ファイルや設定ファイルが存在するかをチェックできます。

 1# python vc_log4j_mitigator.py --dryrun
 22021-12-25T17:43:09 INFO main: Script version: 1.6.0
 32021-12-25T17:43:09 INFO main: vCenter type: Version: 7.0.3.00200; Build: 18901211; Deployment type: embedded; Gateway: False; VCHA: False; Windows: False;
 42021-12-25T17:43:09 INFO main: Running in dryrun mode.
 52021-12-25T17:43:09 INFO process_jar: Found a VULNERABLE FILE: /opt/vmware/lib64/log4j-core-2.13.0.jar
 6  ...
 72021-12-25T17:43:24 INFO print_summary:
 8=====     Summary     =====
 9List of vulnerable java archive files:
10
11/opt/vmware/lib64/log4j-core-2.13.0.jar
12  ...
13
14List of vulnerable configuration files:
15
16/usr/lib/vmware-vmon/java-wrapper-vmon
17  ...
18
19Total found: 19
20Log file: /var/log/vmsa-2021-0028_2021_12_25_17_43_09.log
21===========================
222021-12-25T17:43:24 INFO main: Done.

上述の実行例のように、未対処のファイルが羅列され Total found が 0 以外の値であれば対処が必要です。

vc_log4j_mitigator.py による対処の実行

vc_log4j_mitigator.py をオプション無しで実行することで脆弱性への対処が行われます。4行目のように英語で「処理の完了にサービスの停止と起動が必要です。続けますか？」と聞かれるので、プロンプトに y を入力して Enter キーで続けます[^1]。

 1# python vc_log4j_mitigator.py
 22021-12-25T18:01:30 INFO main: Script version: 1.6.0
 32021-12-25T18:01:30 INFO main: vCenter type: Version: 7.0.3.00200; Build: 18901211; Deployment type: embedded; Gateway: False; VCHA: False; Windows: False;
 4A service stop and start is required to complete this operation.  Continue?[y]y
 52021-12-25T18:03:20 INFO stop: stopping services
 62021-12-25T18:04:18 INFO process_jar: Found a VULNERABLE FILE: /opt/vmware/lib64/log4j-core-2.13.0.jar
 7  ...
 82021-12-25T18:04:31 INFO print_summary:
 9=====     Summary     =====
10Backup Directory: /tmp/tmphe8ww6_w
11List of processed java archive files:
12
13/opt/vmware/lib64/log4j-core-2.13.0.jar
14  ...
15List of processed configuration files:
16
17/usr/lib/vmware-vmon/java-wrapper-vmon
18  ...
19
20Total fixed: 16
21
22    NOTE: Running this script again with the --dryrun
23    flag should now yield 0 vulnerable files.
24
25Log file: /var/log/vmsa-2021-0028_2021_12_25_18_01_30.log
26===========================
272021-12-25T18:04:31 INFO start: starting services
282021-12-25T18:09:17 INFO main: Done.

上述したように vc_log4j_mitigator.py による対処の実施時にはサービスの再起動が発生します。完了まで vCenter Server が使用できないため注意してください。

なお、vc_log4j_mitigator.py の実行時に –accept-services-restart (-a) オプションを付与すると、自動でサービスの再起動を承認したことになりプロンプトでの確認を行いません。

vc_log4j_mitigator.py による対処完了の確認

vc_log4j_mitigator.py の実行が完了したら、改めて –dryrun オプションを付与して vc_log4j_mitigator.py を実行して対処完了を確認します。「No vulnerable files found!」と表示されれば必要なファイルへの対処が完了しています。

 1# python vc_log4j_mitigator.py --dryrun
 22021-12-25T18:17:36 INFO main: Script version: 1.6.0
 32021-12-25T18:17:36 INFO main: vCenter type: Version: 7.0.3.00200; Build: 18901211; Deployment type: embedded; Gateway: False; VCHA: False; Windows: False;
 42021-12-25T18:17:36 INFO main: Running in dryrun mode.
 52021-12-25T18:17:50 INFO print_summary:
 6=====     Summary     =====
 7
 8No vulnerable files found!
 9
10Total found: 0
11Log file: /var/log/vmsa-2021-0028_2021_12_25_18_17_36.log
12===========================
132021-12-25T18:17:50 INFO main: Done.

対処後の注意点

以下の2点の作業を実施した場合、脆弱性が未対処の状態に戻ってしまうため対処の再実施が必要となります。

  • vCenter Server のファイルベースバックアップからのリストア
  • 脆弱性が未修正の vCenter Server リリースへのアップデート

vCenter Server のファイルベースバックアップは構成情報やデータベースをバックアップします。JAR ファイルなどへの変更はバックアップされないため、ファイルベースバックアップからのリストア時に対処の再実施が必要になる点には注意が必要です。

おわりに

今回の記事では vc_log4j_mitigator.py を使用して vCenter Server に CVE-2021-44228 & CVE-2021-45046 への対処を実施しました。CVE-2021-44228 は CVSS Score 10.0、CVE-2021-45046 は CVSS Score 9.0 と非常に高いスコアを叩き出していますので、悪意のあるユーザーによる攻撃を防ぐために可能な限り早急な対処を推奨します。