AWSのLog4Shellホットパッチにコンテナエスケープと特権昇格の脆弱性

This post is also available in: English (英語)

概要

Log4Shellに続いて、AWSが、脆弱なJavaアプリケーションとJavaコンテナを監視してオンザフライでパッチを適用するホットパッチソリューションを複数リリースしました。各ソリューションは異なる環境に適合するもので、スタンドアロンサーバー、Kubernetesクラスタ、Elastic Container Service (ECS)クラスタ、Fargateをカバーしています。ホットパッチはAWS環境専用ではなく、どのようなクラウド・オンプレミス環境にでもインストールできます。

Unit 42のリサーチャーはこれらのパッチソリューションにおける深刻なセキュリティ問題を特定し、AWSと提携してその修正に取り組みました。サーバーやクラスタにこのパッチサービスをインストールした場合、その環境内のすべてのコンテナがこれを悪用して基盤ホストを乗っ取れるようになります。たとえば、Kubernetesクラスタにホットパッチをインストールした場合、ホットパッチを無効にするか修正済みバージョンにアップグレードするまでは、クラスタ内のすべてのコンテナがエスケープ可能になります。コンテナ以外に、非特権プロセスもこのパッチを悪用して特権を昇格させ、rootとしてコードを実行させることができます。

これらのコンテナは、Javaアプリケーションの実行の有無や、AWSがコンテナ用にハードニングしたLinuxディストリビューションであるBottlerocketを基盤ホストが実行しているかどうかに関係なく、エスケープが可能です。ユーザーネームスペースや非root ユーザーで実行されているコンテナも影響を受けます。これらの脆弱性には、追跡用にCVE-2021-3100、CVE-2021-3101、CVE-2022-0070、CVE-2022-0071が割り当てられています。

AWSは以下の各ホットパッチソリューションの修正版を4月19日にリリースしました。

1. ホットパッチサービスをバンドルした log4j-cve-2021-44228-hotpatchパッケージのバージョン1.1-14
2. 更新されたパッケージをインストールするkubernetes-log4j-cve-2021-44228-node-agent Daemonsetのバージョン1.1-14
3. Open Container Initiative (OCI) フックをベースとするBottlerocketホスト用のホットパッチソリューションHotdogのバージョン1.02

Unit 42は、これらのホットパッチをインストールしたユーザーに修正済みバージョンへのアップグレードを推奨します。なお、2021年12月17日以降、Amazon LinuxのJDKパッケージ(Javaインストレーション)では、log4j-cve-2021-44228-hotpatchパッケージが自動的にインストールされるようになっています。ご自身のアプリケーションにLog4Shellへのパッチが適用済みであることが確認されている場合は、以下の緩和策のセクションの説明に従ってホットパッチサービスを無効にすることができます。

Prisma Cloudはホットパッチパッケージを検出し、脆弱性のあるバージョンを実行しているホストに対してアラートを発報します。

本稿で扱うCVE	CVE-2021-3100, CVE-2021-3101, CVE-2022-0070, CVE-2022-0071
Unit 42の関連トピック	Container escape, privilege escalation, cloud, Apache log4j

目次

AWSのLog4Shellホットパッチの概要
根本原因分析
コンテナエスケープのデモ
影響
回避・緩和策
コンテナと安全にやりとりするには
結論
追加リソース
開示のタイムライン

AWSのLog4Shellホットパッチの概要

Log4Shellは、それが最近発見された最悪の脆弱性の1つであることを証明するものでした。この問題に対処するユーザーを大規模に支援するため、AWSは複数のホットパッチソリューションをオープンソース化し、それぞれが異なる環境をカバーするようにしました。ホットパッチというのは脆弱性のある実行中のアプリケーションに修正プログラムを注入するプロセスのことで、そのアプリケーションの新たな修正バージョンがデプロイされるまでの短期的ソリューションとして機能することを意図しています。

AWSは、脆弱なJavaアプリケーションが動作しているプロセスやコンテナを検出してそれらにオンザフライでパッチを適用するホットパッチソリューションを3つ発表しました。

1. RPMパッケージにバンドルされているホットパッチサービス。2021年12月17日以降、Amazon LinuxのJDK(Java)パッケージと一緒に自動インストールされるようになりました。Fargateのユーザーは、自分のコンテナが稼働しているホストにこのサービスをインストールするように依頼することもできました。
2. Kubernetesクラスタ用のホットパッチDaemonset。これは前述のホットパッチサービスを全ノードにインストールします。
3. OCIフックのセットとしてバンドルされたホットパッチソリューションHotdog。Hotdogは、主にBottlerocketホストを対象としています。

これらのソリューションは、KubernetesクラスタからECSクラスタ、Fargateコンテナ、スタンドアロンサーバーまで、ほとんどのコンピュート環境をカバーしていますし、AWS環境に限らず他のクラウド環境やオンプレミスにも導入できます。

Unit 42のリサーチャーは、これらのパッチがコンテナエスケープや権限昇格のために悪用される可能性があることを発見しました。いずれかのパッチがホストまたはクラスタにインストールされると、新しいコンテナがそのパッチを悪用し、基盤ホストを危険にさらす可能性があります。ホットパッチサービスまたはホットパッチDaemonsetのいずれかをインストールしたホストでは、既存のコンテナもエスケープ可能になります。コンテナ以外に、非特権プロセスもこのパッチサービスを悪用して特権を昇格させ、rootとしてコードを実行させることができます。AWSは現在はこれらの脆弱性を緩和して各ソリューションに対応した修正プログラムを公開しています。

根本原因分析

AWSのホットパッチソリューションは、Javaプロセスを継続的に検索し、Log4Shellに対してオンザフライでパッチを適用します。コンテナの内外を問わず、「java」という名前のバイナリを実行しているプロセスは、ホットパッチの適用候補とみなされます。

コンテナ内のJavaプロセスにパッチを適用するために、ホットパッチソリューションは特定のコンテナバイナリを呼び出します。これらのソリューションは、たとえばコンテナの「java」バイナリを2回実行し、1回目でJavaのバージョンを取得して2回目でホットパッチを注入します。問題は、コンテナバイナリが適切にコンテナ化されずに呼び出されていたことです。つまり、新しいプロセスは通常コンテナプロセスに適用される制約を受けずに実行されるのです。

たとえば「java」バイナリは、nsenterコマンドによりコンテナネームスペース内で呼び出されていました(ユーザーネームスペースを除く)。しかも、すべてのLinuxのケイパビリティ付きで、かつseccompやcgroupsのような通常のコンテナ制限用の隔離技術なしで生成されていました。さらに、コンテナのユーザーが何であろうとrootユーザーとして実行されました。

このため、悪意のあるコンテナに「java」という名前の悪意のあるバイナリを含ませておけば、インストールされたホットパッチソリューションに、そのバイナリを昇格した特権で起動させることが可能でした。そうなれば、悪意のある「java」プロセスは昇格した特権を悪用してコンテナをエスケープして基盤ホストを乗っ取れます。修正されたホットパッチソリューションは、コンテナバイナリを実行前に適切にコンテナ化しています。

コンテナ以外に、ホットパッチサービスはホストプロセスに対しても同様にパッチを適用しています。悪意のある非特権プロセスは、「java」という名前で悪意のあるバイナリを作成して実行することで、ホットパッチソリューションを騙してこのバイナリを昇格した特権で起動させることが可能でしたが、修正されたホットパッチサービスでは、パッチ適用対象のJavaプロセスと同じ特権で「java」バイナリが生成されるようになりました。

コンテナエスケープのデモ

本脆弱性のエクスプロイト可用性検証のため、私たちはPoC(概念実証)用のコンテナイメージを作成しました。ホットパッチソリューションの脆弱性のあるバージョンを実行しているクラスタやVMにデプロイすると、このコンテナは当該脆弱性を悪用してコンテナをエスケープし、基盤ホスト上でrootとしてコードを実行できるようになりました。その後、攻撃者の管理下にあるサーバーにリバースシェルを送信します。

以下のデモビデオでは、あるユーザーがEKSクラスタにホットパッチDaemonsetをインストールする様子を示しています。このデモでは、その後でホットパッチをエクスプロイトする悪意のあるコンテナイメージをユーザーがうっかり実行した場合、どのようなことが起こるかを示し、サプライチェーン攻撃をシミュレートしています。

ビデオ1 CVE-2021-3100のエクスプロイトデモ

このデモでは、サプライチェーン攻撃を例にとりましたが、(ネットワークペイロードなどによって)すでに侵害されている既存のコンテナも、この問題を悪用してコンテナをエスケープし、基盤ホストを乗っ取ることが可能です。悪意のある第三者による悪用を防ぐため、現時点ではこのエクスプロイトの実装詳細は公開しないことを決定しました。

影響

Log4Shellをとりまく緊急性に鑑み、ユーザーはホットパッチを大規模にデプロイし、意図せずコンテナ環境を危険にさらしている可能性があります。ホットパッチ削除への強い動機がないことから、JavaアプリケーションにLog4Shellのパッチを適用した後もユーザーが多層防御のためにホットパッチを実行したままにしている可能性があります。

コンテナは、同一マシンで動作するアプリケーション間のセキュリティ境界としてよく使用されますが、コンテナエスケープにより、単一のアプリケーションの先へと攻撃キャンペーンを拡張し、近隣サービスを侵害することが可能になります。Kubernetesクラスタでは、残念ながら1つのコンテナのエスケープでクラスタ全体が乗っ取られてしまうことがあります。

この問題はコンテナ構成に関係なく悪用されうるため、コンテナをユーザーネームスペースや非rootユーザーで実行するなどの高度な隔離技術を有効にしている環境であっても影響を受ける可能性があります。

コンテナ以外に、非特権プロセスもこの脆弱性を悪用して特権を昇格させ、基盤サーバーを完全に制御下に置くことが可能でした。

回避・緩和策

AWSは、各ホットパッチソリューションに対応した修正プログラムをリリースしました。ホストが修正バージョンを実行するとコンテナエスケープや特権昇格はできなくなります。

1. Kubernetesクラスタでは、AWSの提供する最新のDaemonsetをデプロイすることで修正済みホットパッチ版をインストールできます。ホットパッチDaemonsetを削除しただけでは、ホットパッチサービスはノードから削除されないことに注意してください。2022-04-25 更新: 現在Debianベースホスト(DebianおよびUbuntu)用のDaemonset修正済みバージョンはありません。こちらのGithubスレッドから詳細を確認してください。2022-05-05 更新: Debianベースホスト用の修正版Daemonsetが公開されました。Debian log4j-cve-2021-44228-hotpatchパッケージ用の修正バージョンは1.1.17です。
2. スタンドアロンホストの場合は、yum update log4j-cve-2021-44228-hotpatch を実行するとアップグレードできます。
3. Hotdogを利用しているユーザーは最新版へのアップグレードが必要です。

また、ご自身の環境でLog4Shellへのパッチが適用済みであることが確認されている場合は、 sudo touch /etc/log4j-cve-2021-44228-hotpatch.kill を実行すると、ホスト上のホットパッチサービスを無効化できます。Hotdogを無効にするには、 apiclient set oci-hooks.log4j-hotpatch-enabled=false を実行します。

Prisma Cloudをご利用のお客様は[Vulnerabilities(脆弱性)]タブ以下で影響を受けるホストを確認できます。Prisma Cloudはホットパッチパッケージを検出して脆弱性のあるバージョンを実行しているVMのユーザーにアラートを発報します。脆弱性を検索するには、それらと関連するAmazon Linux Security Advisories (ALAS)のID(ALAS-2021-1554、ALAS-2021-1732、 ALAS-2022-1580、ALAS-2022-1773)を使います。

パロアルトネットワークスのPrisma Cloud、Cortex XDR、次世代ファイアウォール (NGFW)の各シリーズは攻撃者による後続アクティビティを検出し、今回のデモで利用したリバースシェルのようなコマンド&コントロール(C2)通信を妨害できます。

コンテナと安全にやりとりするには

ホストプロセスが実行中のコンテナと直接対話することにより発生するコンテナエスケープ脆弱性の長いリストに、CVE-2021-3100、CVE-2021-3101、CVE-2022-0070、CVE-2022-0071が加わりました。コンテナに悪意がある場合、ファイルコピーや新たなコンテナ化プロセスの生成といった単純なタスクが、驚くべき結果をもたらすことがあります。

コンテナ周りのソフトウェアを作る場合は、コンテナのプロセスやファイルシステムに関わるオペレーションはruncのような確立されたコンテナランタイムに委ねるようにしましょう。コンテナランタイムにもそれ相応の脆弱性はありますが、コンテナと安全にやりとりするためのプログラムとしてはこれが最も吟味されて成熟したものです。

結論

Log4Shellをとりまく緊急性に鑑み、ユーザーはホットパッチを大規模にデプロイし、意図せずコンテナ環境を危険にさらしている可能性があります。ユーザーの皆様には、できるだけ早く、修正済みホットパッチバージョンにアップグレードすることをお勧めします。とくにマルチテナントのコンテナ環境や、信頼されていないイメージを実行しているクラスタは危険にさらされています。

Log4Shellに対するパッチ作業を継続中の場合、まずその作業を優先してください。今回提示された問題はコンテナ環境に対する深刻な攻撃につながる可能性がありますが、Log4Shellは史上最悪の脆弱性の1つとしてしかるべき位置づけを得て現在も活発に悪用されています。

弊社は、この脆弱性の効率的な修正におけるAWSの協力と連携に感謝します。Log4Shellの悪用がピークに達したとき、AWSのホットパッチがコミュニティへの無数の攻撃の阻止に役立ちました。そしてこれらの脆弱性が修正されたことで、ホットパッチでLog4Shellに対応しつつ、コンテナ環境の安全性を確保することが可能になりました。

追加リソース

• Unit 42によるLog4Shellの分析
• AWS advice on mitigating Log4Shell in container enviroments (コンテナ環境におけるLog4Shell緩和に関するAWSの推奨事項)
• Prisma CloudでLog4Shellの脆弱性に対応する方法

開示のタイムライン

• 12月14日: AWSがコンテナをサポートするホットパッチパッケージをリリース
• 12月20日: Unit 42のリサーチャーがこの問題を特定
• 12月21日: AWSへアドバイザリ送信
• 12月22日: AWSがこの問題を認識
• 12月23日: AWSが影響を受けるコンポーネントの修正とアドバイザリをリリース
• 12月27日: Unit 42がAWSの初期修正のバイパスを報告
• 2月9日: Unit 42のリサーチャーがAWSのセキュリティチームと修正について議論
• 4月1日: AWSがUnit 42にレビュー用修正バージョンを共有
• 4月4日: Unit 42が残留している問題若干数について指摘
• 4月19日: AWSが最終修正およびアドバイザリを公開、Unit 42が本脆弱性を一般に開示

2022-04-23 14:30 JST 英語版更新日 2022-04-20 16:15 PDT の内容を反映
2022-04-26 09:00 JST 英語版更新日 2022-04-25 11:00 PDT の追記内容を反映
2022-05-06 09:00 JST 英語版更新日 2022-05-05 11:10 PDT の追記内容を反映