Microsoft、SiloscapeにつながるWindowsコンテナ問題を修正するセキュリティ更新プログラムを公開

By

Category: Cloud, Unit 42

Tags: , , , , ,

A conceptual image representing Siloscape, the Windows container escape that was recently prevented by a Microsoft patch.

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

概要

Microsoftは最近、Windowsコンテナエスケープを修正するセキュリティチェックに追加更新を行いました。この脆弱性は昨年弊社が発見した、これまで知られている中では初めてWindowsコンテナを標的とする脆弱性「Siloscape」を可能にしたものと同じエスケープです。

弊社はWindowsコンテナに関する数々の発見をこれまでSiloscapeに関するレポートとしてまとめてきました。まず私たちはアーキテクチャの概要を説明し、続いてそれらの知見の一部を使ってコンテナエスケープを図る方法を記事にしました。

この問題に対処するため、Microsoftはコンテナエスケープを可能にする主たる関数に着目することでエクスプロイトを防止しました。また、コンテナ内から関数が呼び出されているかどうかもチェックされるようになりました(その場合はブロックされます)。Microsoftが導入したこれらの新しい変更は、Siloscapeの攻撃手法を直接的に阻止するものです。

しかし、これらのセキュリティチェックは、特定の目的のためにWindows Serverコンテナを実行するリスクを完全に取り除くものではありません。以前の記事でもご紹介したように、私たちはWindowsコンテナをセキュリティ対策として使うことは推奨していませんし、このことはMicrosoftのガイダンスとも一致しています。

パロアルトネットワークスの Prisma Cloudは、Siloscape攻撃からお客様を保護します。またPrisma Cloud Computeでは、既知のCVEに対して脆弱な古いバージョンのホストをお持ちのお客様に警告を発します。

問題とセキュリティ更新プログラムの技術的概要

Windowsコンテナのエスケープテクニックについてのおさらい

以前の記事で詳しく説明しましたが、この脆弱性を悪用してホストのドライブにシンボリックリンクを作成し、コンテナをエスケープしようとする攻撃者は、文書化されていない関数NtSetInformationSymbolicLinkを正しいパラメータを指定して呼び出す必要があります。この呼び出しによって攻撃者が選んだシンボリックリンクがグローバルになり、コンテナのオブジェクトではなくホストのオブジェクトをポイントするようになります。コンテナ内のグローバルシンボリックリンクは、ホストのファイルシステム、レジストリ、または基本的にルートディレクトリオブジェクトの下にあるどんな名前のオブジェクトでもポイント可能です。

Microsoftがセキュリティ更新プログラムを適用したWindowsコンテナエスケープの実行フローを示します。図が示すとおりNtSetInformationSymbolicLinkの使用に依存している
図1 コンテナエスケープの実行フロー

NtSetInformationSymbolicLinkを正常に使用するためには、呼び出し側はSeTcbPrivilege特権を持っていなければなりません。通常のコンテナのユーザーはAdministratorではあるのですが、必要な特権を持っていません。

そこでSeTcbPrivilege特権を取得するのに、攻撃者は関連する特権を持つメインコンテナのプロセスCExecSvc.exeを使うことができます。攻撃者はCExecSvc.exeのコンテクストを使い、スレッド偽装や昔ながらのDLLインジェクションなどのさまざまな方法により、特権を得ることができます。

修正

図の左側は修正プログラム適用前のNtSetInformationSymbolicLinkの機能を示しています。図の右側は、保護用の修正が入った結果を示しています。PsIsCurrentThreadInServerSilo関数は、現在のスレッドがサーバーサイロ内のプロセスに関連しているかどうかをチェックします。
図2 セキュリティ更新プログラムの適用前(左)と適用後(右)のNtSetInformationSymbolicLink

セキュリティ更新プログラムはわかりやすく、素直な印象を受けました。コンテナ(サーバーサイロ)内のスレッドからのNtSetInformationSymbolicLink呼び出しは、STATUS_PRIVILEGE_NOT_HELDエラーコードでブロックされます。これには、PsIsCurrentThreadInServerSilo関数を使用します。この関数は、その名が示すように、現在のスレッドがサーバーサイロ内のプロセスに関連しているかどうかをチェックします。

Kubernetesクラスタが保護されているかどうかを確認するには

Windows Server 2019は、Kubernetesがサポートする唯一のWindows OSであり、このセキュリティ更新プログラムにも含まれています。一番最初の1809を含むWindows Server 2019のすべてのバージョンは、修正プログラムを受け、この問題から保護されています。
図3 修正プログラムを適用したWindows Server 2019マシン上でNtObjectManagerによりシンボリックリンクをグローバル化しようとして失敗したところ

Windows Server 2019は、Kubernetesがサポートする唯一のWindows OSであり、このセキュリティ更新プログラムにも含まれています。一番最初の1809を含むWindows Server 2019のすべてのバージョンは、修正プログラムを受け、この問題から保護されています。

クラウドプロバイダを利用してKubernetesクラスタをホストしている場合はノードの更新が保留になっていないことを確認してください。一方、自分でクラスタをホスティングしている場合は、ノードに最新のセキュリティ更新プログラムがインストールされていることを確認してください。

結論

今回の修正で既知のエクスプロイトはクローズされたのでまずはひと安心ですが、これらのセキュリティチェックは、特定の目的のためにWindows Serverコンテナを実行するリスクを完全に取り除くものではありません。前回の記事でも述べたようにユーザーは「Windowsコンテナをセキュリティ機能と考えて利用しないこと」を推奨するMicrosoftのガイダンスに従うべきです。Microsoftでは、コンテナ化にセキュリティ境界として依存する場合は厳密にHyper-Vコンテナを使うことを推奨しています。Windows Serverコンテナで実行されるプロセスはすべて、ホスト(この場合はKubernetesノード)のadminと同じ権限を持っているものと仮定する必要があります。Windows Serverコンテナでセキュリティを確保する必要のあるアプリケーションを実行している場合は、これらのアプリケーションをHyper-Vコンテナに移行することをお勧めします。

とはいえ、コンテナの安全性は、独立したカーネルを持つ本物の仮想マシンに比べて常に低いものですが、今回の修正は、WindowsコンテナをLinuxコンテナと同等に安全にするための正しい方向性を示しています。

パロアルトネットワークスの Prisma Cloudは、Siloscape攻撃からお客様を保護します。またPrisma Cloud Computeでは、既知のCVEに対して脆弱な古いバージョンのホストをお持ちのお客様に警告を発します。

Prisma Cloudのランタイム保護機能はマシンの振る舞いを学習し、プロセスのためのルールセットを作成します。予期せぬプロセスの実行を試みることに対するこの保護は、Microsoftが最近導入したセキュリティ更新プログラムとともに、Windowsコンテナのエスケープを防ぐことができます。
図4 Prisma Cloudで予期せぬプロセスに対するアクションを選択しているところ

Prisma Cloudのランタイム保護機能はマシンの振る舞いを学習し、プロセスのためのルールセットを作成します。学習が完了すると、ユーザーが新たに実行される予期せぬプロセスに対するアクションを選択できるようになります。ユーザーは警告、防止、または実行の完全なブロックからアクションを選択できます。

このスクリーンショットは、Prisma CloudがSiloscapeをブロックしている例です。
図5 Prisma CloudでブロックされたSiloscape